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