In a recent debug class, someone brought in a debug log in which the system (a Windows .NET Server RC1 system) had appeared to hang.  However, after looking at the log they had collected, we were able to identify that a background service had hit a breakpoint and that had in turn, triggered a call to the attached kernel debugger!

This behavior is documented in the debugger documentation, and is part of the “just-in-time” debugging model for user applications.  The documentation says:

“If no user-mode debugger is attached, and Windows has an open kernel-debugging connection, and the error is a breakpoint interrupt, Windows will attempt to contact the kernel debugger. If Windows does attempt to contact a kernel debugger but there is no debugger running at the other end of the connection, Windows will freeze until kernel debugger is activated.”

Since this might not be the behavior desired by someone debugging their own driver, you can now use the KDbgCtrl utility (part of the debugging tools package) to control this behavior.  Alternatively, you can either use the “gh” command to ignore the breakpoint, or to pass the breakpoint to the normal debugging mechanism (e.g., Dr. Watson).