add support for custom mini dump types and support for loading of a specific dbghelp DLL

[rdmenezes]

add support for custom mini dump types and support for loading of a specific dbghelp DLL

[GoogleCodeExporter]

I've updated CrashRpt to include proper support for specifying the mini dump 
type as
well as the custom path / filename of the dbghelp.dll the programmer desires to 
load.
I've attached the code I have changed.

Also, I've found this website that proved quite useful.
http://www.debuginfo.com/articles/effminidumps2.html

I do see one potential problem however. It would be incredibly useful to allow 
the
end-user to select the mini dump type (small, medium, full) - However, it seems 
that
the crash dialog is not displayed until after the dump is generated. Is this a
difficult change to make?

Original comment by [email protected] on 21 Nov 2009 at 8:13

• Added labels: ****
• Removed labels: ****

Attachments:

• CrashHandler.cpp
• CrashHandler.h
• CrashRpt.cpp
• CrashRpt.h

[GoogleCodeExporter]

updated crashrpt.cpp and crashrpt.h to include support in the crInstallA 
function for
the new debug help DLL custom name and mini dump type UINT.

Original comment by [email protected] on 21 Nov 2009 at 8:32

• Added labels: ****
• Removed labels: ****

Attachments:

• CrashRpt.h
• CrashRpt.cpp

[GoogleCodeExporter]

Hmm.. have you ever really use those full minidumps? I think there is no need in
dumping all process memory (or even data segments). I have been using CrashRpt 
for a
long time and I never felt need of large dumps. 

If your argument is that you use a server app, there is still no need in large 
dumps.
I'm familiar with server apps and I know none of them using complex crash report
sending functionality. Server crash is an extraordinary event, even on Windows
platform. Server apps typically maintain large log files and developers 
determine the
reason of crash analysing such files. Even if you do not have access to your
customers' servers, server crash would force them to contact you as soon as 
possible
even without any crash reporting functionality. :) 

Original comment by [email protected] on 24 Nov 2009 at 2:54

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Yes, I have used full minidumps. They are very useful. At times I have a need 
to dump
all the memory. 

I understand that the servers which you are familiar with may not use any sort 
of
automatic error reporting, but you must admit that you are not familiar with all
servers in existence. Some servers do use crash reporting. There are all manner 
of
different types of servers; a server crashing in not such an uncommon thing. Log
files can be useful at times, crash reports can be more useful...depends on the 
crash. 

I need support for custom mini dump types. If you are unable or unwilling to 
add this
just let me know. I can add this feature myself. What I very much want to avoid 
is
having my own personal copy of the CrashRpt code base. I prefer to pay you for 
all
necessary changes and maintain one common code base.

Original comment by [email protected] on 25 Nov 2009 at 1:23

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

My comments on the minidump level:

"Allow the end-user to select via the crash dialog which level of mini dump
to generate." - the programmer must decide this, not end-user. No need to add 
this
option to user interface, no need to complicate life of end-users. We just need 
to
introduce an additional flag in CR_INSTALL_INFO::dwFlags structure member. 

I suppose we cannot deliver huge minidumps using current delivery transports 
(e-mail
and base64-http), since they have report size limitations. The only possible 
way I
see is using libcurl for this purpose (multi-part http request).

Another way for you that doesn't require any modifications is using normal 
minidumps.
I believe these ones provide the same debugging capabilities as huge dumps. 
Just try
and you will see.

My comments on dbghelp.dll path:

I agree LoadLibrary() and GetProcAddress() should be used here.
But I also think we won't do any changes in API here. CrashRpt should decide 
itself
what DLL to load. If it finds the DLL in the same directory, it should load this
dbghelp.dll. Otherwise, it should load any available dbghelp.dll.

Original comment by [email protected] on 27 Nov 2009 at 4:37

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Original comment by [email protected] on 23 Dec 2009 at 7:10

• Changed state: Fixed
• Added labels: ****
• Removed labels: ****