OSRLogo
OSRLogoOSRLogoOSRLogo x OSR Custom Development Services
OSRLogo
x

Everything Windows Driver Development

x
x
x
GoToHomePage xLoginx
 
 

    Tue, 11 Dec 2018     118021 members

   Login
   Join


 
 
Contents
  Online Dump Analyzer
OSR Dev Blog
The NT Insider
Downloads
ListServer / Forum
  Express Links
  · The NT Insider Digital Edition - May-June 2016 Now Available!
  · Windows 8.1 Update: VS Express Now Supported
  · HCK Client install on Windows N versions
  · There's a WDFSTRING?
  · When CAN You Call WdfIoQueueP...ously

Undesired Debugger Behavior

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).

Related Articles
Debugging A Sound Driver

User Comments
Rate this article and give us feedback. Do you find anything missing? Share your opinion with the community!
Post Your Comment

Post Your Comments.
Print this article.
Email this article.
bottom nav links