HoppeRx - the cure for your ailing device

A community site dedicated to the support of device problems found by Hopper

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

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

Rate This
  • Comments 4

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.

Comments
  • Could you give some addtional advise on how to find a good number for dwNKDrWatsonSize?

    Is selecting 128kB a good value? Suppose I double that to 256 kB, what would it give me? Any risk 128kB could be a to small number?
  • Sven – as with all tradeoffs made with precious resources (in this case memory), I believe this number is best found with trial and error. 128 is a good number to begin with and can be adjusted accordingly if you are not getting what you need in the debugger.

    If you set this number too large you can starve your system of this memory and possibly introduce bugs later if you decide to lower it when you ship your devices. By using a larger number however, you get the added benefit of more debugging information that could possibly make or break a particular investigation.

    In contrast, setting the number too low can have the effect of not giving you what you need during debugging. Watson needs some room to work and log precious snapshot information that is often crucial to your debugging efforts.

    Also remember that this number can be changed at any time – make the change and simply rebuild your platform and flash to your device. This allows you to begin your development with a larger number that can be fine-tuned later when your platform stabilizes.
  • I want to run an application on Windows Mobile 6.0 and want to know extract the call stack when there is any exception or a crash. Please tell me how it can be achieved.

  • Below is the second half of a well executed document from guestRx: Bulent Elmaci. Bulent has worked with

Page 1 of 1 (4 items)
Leave a Comment
  • Please add 5 and 7 and type the answer here:
  • Post