Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All

Crashing and Rebooting the Target Computer

When you perform kernel debugging, you can cause the target computer to stop responding (that is, crash or bug check) by issuing the .crash (Force System Crash) command. This command immediately causes the target computer to stop responding. The debugger writes a kernel-mode dump file if you have enabled crash dumps. (For more information about these files, see Creating a Kernel-Mode Dump File.)

To restart the target computer, use the .reboot (Reboot Target Computer) command.

If you want the target computer to create a crash dump file and then restart, you should issue the .crash command, followed by the .reboot command. If you want only to restart, the .crash command is not required.

In the early stages of the boot process, the connection between the host computer and the target computer is lost. No information about the target computer is available to the debugger.

After the connection is broken, the debugger closes all symbol files and unloads all debugger extensions. At this point, all breakpoints are lost if you are running KD or CDB. In WinDbg, you can save the current workspace. This action saves all breakpoints.

If you want to end the debugging session at this point, use the CTRL+B command (in KD) or click Exit on the File menu (in WinDbg).

If you do not exit the debugger, the connection is reestablished after enough of the boot process has completed. Symbols and extensions are reloaded at this point. If you are running WinDbg, the kernel-mode workspace is reloaded.

You can tell the debugger to automatically break into the target computer during the restart process at two possible times:

  • When the first kernel module is loaded into memory

  • When the kernel initializes

To set an automatic breakpoint when the first kernel module loads, use the -d command-line option.

You can also change the break state after the debugger is running:

  • Control the initial module load and kernel initialization breakpoints like all exceptions and events. You can break into the debugger when these events occur, or ignore them. You can also have a specified command automatically execute when these breakpoints are hit. For more information, see Controlling Exceptions and Events.

  • Use the CTRL+K shortcut keys in KD, the CTRL+ALT+K shortcut keys in WinDbg, and the Debug | Kernel Connection | Cycle Initial Break command in WinDbg to change the break state. Every time that you use these commands, the debugger switches between three states: no automatic break, break upon kernel initialization, and break on first kernel module load. This method cannot activate both automatic breakpoints at the same time.



Send comments about this topic to Microsoft

© 2015 Microsoft