Option to send the callstack or other minidump data from the client

[GoogleCodeExporter]

> What steps will reproduce the problem?
1. send the crash to an old windows server or to a Linux server
2. cannot get the call stack

> What is the expected output? What do you see instead?

There should be an option to extract the call stack from the minidump on the 
client side. Extracting the data on the server is not always possible for 
various reasons.

If providing this option is not possible, the API (CrashRpt.h) should at least 
provide access to the data that has been attached in the report as a way to 
enable processing the minidump file from another process.

> What version of CrashRpt are you using?

1.3.1

> What is your version of Visual Studio?

2010-2012

> What is your version of Windows operating system?

7/XP/2008

Original issue reported on code.google.com by tnagy1...@gmail.com on 5 Oct 2012 at 1:04

[GoogleCodeExporter]

CrashRpt already provides API for extracting data from crash reports. See this 
for more information:
http://crashrpt.sourceforge.net/docs/html/using_crashrptprobe_api.html

Original comment by zexspect...@gmail.com on 5 Oct 2012 at 3:58

• Changed state: WontFix

[GoogleCodeExporter]

I understand that there is an API for extracting data from the crash report. 
But how to call that API before the report (the .zip file) is created? How to 
access the temporary minidump file? How to access that .zip file before it is 
actually sent without rewriting the crashsender program?

It seems that the data attached to the report (addData, addFile, ...) is going 
to a black hole. I can imagine that breaking down crashrptprobe to enable 
reading the mindump file can be annoying and that it does not match your vision 
of the software.

Yet, the system would be much more flexible on the client side if the crashing 
process could *know* the temporary directory of the current crash. It could 
then access at least the crashdump.dmp file without having to fork crashrpt.

Original comment by tnagy1...@gmail.com on 6 Oct 2012 at 11:16

[GoogleCodeExporter]

Original comment by zexspect...@gmail.com on 7 Oct 2012 at 3:13

• Changed state: Reviewed

[GoogleCodeExporter]

I added a new-style crash callback function that can be useful to resolve your 
issue.

Details of the change: added PFNCRASHCALLBACK() callback function prototype, 
CR_CRASH_CALLBACK_INFO structure and crAddCrashCallback() function. You can now 
get the temporary directory name where crash files are stored from the 
CR_CRASH_CALLBACK_INFO structure. 

Original comment by zexspect...@gmail.com on 16 Oct 2012 at 6:27

• Changed state: Accepted

[GoogleCodeExporter]

This issue was closed by revision r1430.

Original comment by zexspect...@gmail.com on 16 Oct 2012 at 6:28

• Changed state: Fixed