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

[GoogleCodeExporter]

Allow the end-user to select via the crash dialog which level of mini dump
to generate. I suggest offering 3 different levels. 1) small mini dump
consisting of MiniDumpNormal, 2) medium size mini dump consisting of the
following options: MiniDumpWithPrivateReadWriteMemory,
MiniDumpWithDataSegs, MiniDumpWithHandleData, MiniDumpWithFullMemoryInfo,
MiniDumpWithThreadInfo, MiniDumpWithUnloadedModules 3) full size dump of
entire address space consisting of the following options:
MiniDumpWithFullMemory, MiniDumpWithFullMemoryInfo, MiniDumpWithHandleData,
MiniDumpWithThreadInfo, MiniDumpWithUnloadedModules

The UI should support selection between one of the 3 option types. In fact,
I would suggest only offering selection between option 2 and option 3.

Next, allow the programmer to specify a custom path/filename to dbghelp.dll
- This is necessary because some of the MINIDUMP_TYPE options are not
available in older versions of dbghelp.dll - I ship dbghelp.dll with my
app, but unless I can specify a path/filename to dbghelp.dll then there is
chance that an older version already installed on the end-user's PC will be
installed. So please allow for the programmer to specify a custom string to
indicate which file to load. NOTE: this means that CrashRpt cannot link to
dbghelp.lib - Instead LoadLibrary(...) and GetProcAddress(...) must be called. 

I have attached example code to illustrate what I mean. This code is meant
to serve as an nothing more than a working example and not meant to dictate
API structure, etc. - In the attached files note the use of
LoadLibrary(...), GetProcAddress(...), g_sDebugHelpDllFile, g_MiniDumpType,
etc.

Original issue reported on code.google.com by crcod...@gmail.com on 21 Nov 2009 at 6:48

Attachments:

• CrashHandler.cpp
• CrashHandler.h

[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 crcod...@gmail.com on 21 Nov 2009 at 8:13

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 crcod...@gmail.com on 21 Nov 2009 at 8:32

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 zexspect...@gmail.com on 24 Nov 2009 at 2:54

[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 crcod...@gmail.com on 25 Nov 2009 at 1:23

[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 zexspect...@gmail.com on 27 Nov 2009 at 4:37

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

[GoogleCodeExporter]

Original comment by zexspect...@gmail.com on 23 Dec 2009 at 7:10

• Changed state: Fixed