Not all Watson dumps are created equal (Watson part II)

shende — Wed, 12 Oct 2005 18:32:00 GMT

The second installment of Watson will focus on the type of dump created during error reporting. Watson will chose one of the following depending on system settings and resources available – the significant difference between them is size required to process and store the dump.

Many Watson settings are stored in the registry, but the dump size is reserved during OEMInit:

extern DWORD dwNKDrWatsonSize;

void OEMInit (void)

{

dwNKDrWatsonSize = 0x20000

}

Generally, the more memory allocated here the more complete your Watson information will be – but you will be taking memory away from other applications so you need to be sensitive to the tradeoff. It is also worth mentioning that the larger number chosen here could prevent your device from storing a larger number of Watson dumps – sometimes less is more in this case.

Type of Dump File	Size	Description
Context dumps	4 KB - 64 KB.	Information about the crashing system Exception that initiated the crash Context record of the faulting thread Module list, limited to the faulting threads of the owner process Thread list, limited to the faulting threads of the owner process Callstack of the faulting thread 64 bytes of memory above and below the instruction pointer of the faulting thread Stack memory dump of the faulting thread, truncated to fit a 64 KB limit
System dumps	64 KB - several MB	All information in a Context dump Callstacks and context records for all threads Complete module, process, and thread lists for the entire device 2048 bytes of memory above and below the instruction pointer of the faulting thread. Global variables for the process that was current at the time of the crash
Complete dumps	All physical memory plus at least 64 KB	All information in a context dump A complete dump of all used memory

Again, the PB help under Error Reporting is excellent and should be your official guide in understanding Watson and how it can help you debug stability issues.

Getting help from the Doctor (Dr Watson that is!)

shende — Fri, 07 Oct 2005 20:25:00 GMT

You cannot ship a device connected to the debugger so eventually you will have to cut the cord and run your device standalone. Windows mobile ships a pocket version of Dr Watson that can help evaluate application exceptions that occur while in this unconnected state. Dr Watson already deals with the heavy lifting of logging the exception and providing a debuggable kernel dump – all you need to do is to get these dump files into your release directory for debugging. The default values I like to change are:

HKEY_Local_Machine\System\ErrorReporting\DumpSettings\DumpDirectory = \<storage card name>\DumpFiles

HKEY_Local_Machine\System\ErrorReporting\UploadSettings\DontUpload = 1

Changing these settings will write .kdmp files to your storage card and Watson won’t attempt to upload the files to the Watson server. Additionally, the Watson UI will not be displayed – so don’t be surprised if you no longer see the dialog prompting you to report the errors found. By logging to an external storage card, you can simply remove the card after any Hopper run and view the exceptions that occurred on that device – you will need to look carefully since the DumpDirectory is hidden.

There are additional settings you can play with (like MaxDiskUsage and MaxLogFiles), but in general the Watson documentation is excellent (search for “Error Reporting”) and won’t need repeating here.

Once the kdmp file is in your release directory, it is possible to connect the debugger directly using the PMD (Post Mortem Debugger) available on JetStream for your Windows Mobile partners. The dump provides a snapshot view of the exception including the call stack, disassembly and the register values – basically enough information to solve most program exceptions that may occur on your device.

HoppeRx - the cure for your ailing device : kdmp

Not all Watson dumps are created equal (Watson part II)

Getting help from the Doctor (Dr Watson that is!)