Post Mortem Debug under Windows Mobile with WinDbg

Under Windows Mobile, DrWatson is watching you (... in fact your applications) and identify while they crashe. This is only visible when exceptions occurs, showing memory error reports. At this time a memory dump of the stack and process context is done and stored in a KDMP file located by default in \Windows\System\DumpFiles. This type of files can be then loaded inside the WinDbg application used for desktop application debugging.

Required Tools :
Before starting any debugging you need to get the following tools :
- WinDbg from Microsoft available here (Install Debugging Tools for Windows 32-bit Version).
- Remote Registry Editor provided with Visual Studio 2005.

Sample Application :

An easy way to get memory exceptions, is by accessing unreferenced pointer, we do illustrate the next step of this article with the very simple application code below.

// MemException application
//

#include "stdafx.h"
#include <windows.h>
#include <commctrl.h>

void PrintHello ()
{
OutputDebugString(L"Hello World");
}

void GenerateNullPointerException ()
{
BYTE *pByte = NULL;
*pByte = 0xFF;
}

int _tmain(int argc, _TCHAR* argv[])
{
PrintHello ();
GenerateNullPointerException();

return 0;
}

First Step : Locate the kdump files

By default the kdump files are located in \Windows\System\DumpFiles folders and are deleted after the error reporting dialog box is closed. So to get those files, you have to copy them while the dialog box is displayed, but unfortunately those files are in readonly mode.
Using the registry you can change the file location folder for the kdump files.

[HKEY_LOCAL_MACHINE\System\ErrorReporting\DumpSettings]
"DumpDirectory"="\Temp\DumFiles" (string entry)
"DumpEnabled"=dword:1 (dword entry)

Second step : Copy the kdump files

While dump files are move to \Temp\Dumpfiles, as shown in the example above, files are not accessed as read only and can then by copy to your desktop hard drive, through active sync.
Note : Don't close the warning message box, before doing the copy as DrWatson is removing the files right after.

Third Step : Open the kdump files

The kdump files are generated by Dr Watson, and can be interpreted by WinDbg, usually used for Windows Desktop debugging.
Launch the WinDbg application and get to File -> Open Crash Dump menu.
Select the kdmp file retrieve from your device.

Then in the command line area of Windbg, launch the command :
!analyze -v

If you look carefully to the output, you will see that the symbols are not loaded, as we did not configure the path to the pdb files (debug information files) of our binary ("Symbols can not be loaded because symbol path is not initialized."). So we have to provide the path to the PDB files, by going to File -> Symbol File Path menu and by adding the path to our pdb files. The PDB files are always located in the build folder, where the .exe or .dll file is generated. DO NOT FORGET to check the reload option located on the bottom left of the Symbol Search Path window. And then validate.

At this time, WinDbg is able to locate the line of code in the application where the exception occurs. When you just have the pdb file but not the source files, WinDbg will not shows up any source code, but will give you the exact location in the source code.

FOLLOWUP_IP:
MemException!GenerateNullPointerException+14 [d:\nbesson\projects\vs2005\memexception\memexception\memexception.cpp @ 16]
00011028 0030c2e5 strb r3, [r2]

Known Issues with symbols
Sometimes, WinDbg is unable to find the debug files to locate the source code during the analyze of the dump file. In this case you have to make sure that files hasn't been renamed during copy on the device.
Use the following command to get the link to the source code :
- .sympath : to check the symboles folder, if missing folder go to "File->Symbol File Path" or hit Ctrl+S, add the folder and do not forget to reload
- .reload : to reload symbols
- !sym noisy : to enable verbosity on symbol files access
and finaly if after all those steps the symbol files is not loaded, use the .reload /f <binary file name> to force the symbols loading for this specific binary.

Now enjoy debugging !

-Nicolas