OSRLogo
OSRLogoOSRLogoOSRLogo x Subscribe to The NT Insider
OSRLogo
x

Everything Windows Driver Development

x
x
x
GoToHomePage xLoginx
 
 

    Mon, 22 Oct 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

Don't __try to Catch The DbgBreakPoint(...) Exception

[Status Update: As of 22 March 2005, this bug was fixed in Windows "Longhorn" AKA Windows Vista.  Thanks to the ms dev who took this bug and fixed it!]

Community members Ralph Shnelvar and Jamey Kriby, aided by a group of similarly expert driver devs from the community, each spent the better part of a week banging their collective heads against the wall to characterize a strange problem.  And it's darn lucky for us they did.

What's the problem?  Well, did you ever see or try to use the following code sequence?

__try {

DbgBreakPoint();

}

__except(EXCEPTION_EXECUTE_HANDLER) {

// do something here

}

The desired outcome of this sequence is that the DbgBreakPoint() will issue a breakpoint into the debugger if (a) the system on which this code is running was started with debugging enabled, and (b) the debugger is actually attached to the system at the time the breakpoint is requested.  On the other hand, if the system was started without debugging and/or the debugger is not attached, the system should just continue running (and the code in the exception handler block executed) because, according to the DDK Documentation:

If a debugger is not connected to the system, the exception can be handled in the standard way.

OK, it's kinda sloppy code.  But, I admit, I've used it from time to time to attempt to save myself from the embarrassment of accidentally leaving a breakpoint in some live code shipped to a customer.

So, what did Ralph and Jamey and their crew discover about this construct?  They discovered that if the debugger isn't attached, it doesn't work the way it says it should in the DDK docs, for one thing.  What's worse (you're not going to believe this) is that when you catch the exception raised by DbgBreakPoint, interrupts are disabled on the processor.  Like, real, honest to goodness hardware interrupts are disabled.  That's not as bad as it probably sounds, because interrupts eventually get re-eanbled again as a side effect of other things happening in the system.  Well, that is, interrupts will get re-enabled if the system doesn't crash first!  You can read more about their exploits and this problem in The NT Insider.

We just thought you should know.  Until this is fixed do NOT attempt to catch DbgBreakPoint(...) exceptions -- Do not put DbgBreakPoint(...) within the __try part of a __try/__except block.

HJR

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

"This issue is still present!"
In Windows Server 2003 SP2, and the latest DDK documentation...

Rating:
25-Apr-08, fsjfhjdsfhjdshf jdskfhkdsjhflkdhf


"Don't use Kd* Variables"
Please don't use the Kd* variables. They really shouldn't even be exported, their use is unsupported, and they're subject to change.

Instead, you can use the variables KD_DEBUGGER_ENABLED and KD_DEBUGGER_NOT_PRESENT. These are the "polite" forms of the Kd* variables that are actually documented and supported by MS.

24-Mar-05, Peter Viscarola


"__try { DbgBreakPoint(); } catch..."
Here is a small paste from ntddk.h which might give you a clue of another way that won't conflict with interupts.

extern PBOOLEAN KdDebuggerNotPresent; extern PBOOLEAN KdDebuggerEnabled;

Rating:
23-Mar-05, Anders Fogh


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