Debugging Crashing Surface Applications

If you have prepared to collect debug dumps in Surface mode, complete the following procedure to debug crashing applications.

Collecting Debug Dumps from a Crashing Managed Application

To collect debug dump information from a crashing managed application

  1. Add your debugger to the list of processes that are exempt from UI suppression.

  2. In Windows mode, click Start, type regedit, and press Enter.

  3. Depending on whether you want to debug a 64-bit application or a 32-bit application, do one of the following:

    • For 32-bit applications, in the left pane, expand HKEY_LOCAL_MACHINE, expand SOFTWARE, expand Wow6432Node, expand Microsoft, and then click .NETFramework.

    • For 64-bit applications, in the left pane, expand HKEY_LOCAL_MACHINE, expand SOFTWARE, expand Microsoft, and then click .NETFramework.

  4. In the right pane, set the value of the DbgJITDebugLaunchSetting entry to 2.

  5. In the right pane, set the value of the DbgManagedDebugger entry to the full path of a debugger executable file, and include any appropriate commands.

    Surface Shell uses the process ID of the crashed or unresponsive process for the first instance of "%d" in the DbgManagedDebugger value. If you do not include the %d parameter in the DbgManagedDebugger value, Surface Shell will not start the debugger.

    The following code example shows how to set a device made for Surface to use the Microsoft NT Symbolic Debugger (NTSD). (For more information about NTSD, see the CDB and NTSD topic on the MSDN website.)

    cmd.exe /c start "Collecting information..." /min /b "C:\Debuggers\ntsd.exe" –p %d –c ".dump /ma /u C:\dumps\dump.dmp;q"

    This example includes the following parts:

    • cmd.exe opens a new instance of the Microsoft Windows command interpreter.

    • /c runs the command and then closes the Command Prompt window.

    • start "Collecting information..." opens another window to run the debugger in, with "Collecting information..." as the window title.

      It is unlikely, but users might see the minimized window title in the Windows taskbar, so "Collecting information..." is less intimidating than the WinDbg path and does not imply that users must do something.

    • /min starts the "Collecting information..." window in the minimized state.

    • /b starts the debugger without opening an intermediate Command Prompt window.

    • "C:\Debuggers\ntsd.exe" specifies the full path of the debugger.

    • –p %d tells Surface Shell that you want to debug crashing or unresponsive processes and that Surface Shell should substitute %d for the process ID of the application that is crashing or is not responding. (You do not have to determine or supply the process ID. Surface Shell supplies it for you.)

    • -c " command " specifies the initial debugger command to run when it starts. You must enclose this command in quotation marks. You can separate multiple commands by using semicolons (;).

      1. .dump creates a crash dump file.

      2. /ma creates a minidump (with all possible options, including memory, handles, and unloaded modules).

      3. /u appends the date, time, and process ID to the dump file name (so that dump file names are unique).

      4. c:\dumps\dump.dmp specifies the location and name of the dump file.

      5. ;q exits the debugger after the dump file has been generated.

  6. In addition to configuring the managed JIT debugger, you should also configure the native JIT debugger. For example, you could set the following registry entries to use windbg.exe as your native JIT debugger:

    • [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug]

      "Debugger"="\"C:\\Program Files\\Debugging Tools For Windows (x64)\\windbg.exe\" -p %ld"


    • [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug]

      "Debugger"="\"C:\\Program Files (x86)\\Debugging Tools For Windows (x86)\\windbg.exe\" -p %ld"


    The examples in steps 5 and 6 use two different debuggers: ntsd.exe and windbg.exe, but you may want to use the same debugger for both managed and native JIT debugging.

  7. After the debugger creates and writes to the .dmp file, analyze the results. For example, you can run the windbg.exe –z drive:\path\filenametimestamp.dmp command.

    -z drive :\ path \ filenametimestamp .dmp specifies the full path of the crash dump file that you named in step 5, plus the time stamp that is associated with the dump file that you want to analyze.

    If the path or file name contains spaces, enclose the full path by using quotation marks.

    You can open multiple dump files at the same time by including multiple -z options, each followed by a different dump file path and name.

    The time stamp is the time when the dump file was written. (This time stamp is generated automatically when you specify /u in the DbgManagedDebugger Windbg.exe registry entry.)

    For more information about other NTSD commands and meta-commands, download the Debugging Tools for Windows package.

Did you find this information useful? Please send us your suggestions and comments.

© 2011 Microsoft Corporation. All rights reserved.