However unlike neutered ASSERTs, if the debugger crashes or is restarted for any other reason, all the NT_ASSERT ignores will be forgotten. You have to setup the ignores again.
Another tidbit about NT_ASSERT – they do not seem to work in native applications4.
In summary, if I may borrow structurally from someone’s famous words, to ASSERT or NT_ASSERT – that is a question wrought with faustian bargain.
1I have issued the second gn while half-wondering why the first did not quite work. It does not help that h and n are pretty close in lower-case font glyphs and are right next to each other on a standard QWERTY keyboard. Even with gh on a system thread you can get a SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (0x7E) bugcheck with first parameter set to STATUS_ASSERTION_FAILURE (0xC0000420) and other parameters dutifully pointing to the line of code where NT_ASSERT was called.
2The color blue is easy on the eye. Counting purportedly has a calming effect.
3The “fighting” usually involves either of –
- noop (nop) the entire memory range of ASSERT code
- insert a relative jump (jmp) in the beginning of the ASSERT code
As you can imagine neither of these actions is for the ham-fingered or the pusillanimous.
4On another sidenote- you can hit NT_ASSERT in release builds of Windows. For example, Windows 7 RTM function KeAccumulateTicks has several embedded int 2cs that trigger on rare occasions. This is not very different from a driver issuing int 3 in release build when kd is attached just to ease debugging but I have never seen int 3 in free builds of Windows.
- 1 2