Catching STATUS_ASSERTION_FAILURE with SEH on Insider builds?

We've got a kernel-mode test suite (so this is all about code used internally and never shipped to customers) which contains some tests of the form "if MyInternalRoutine is called with <these invalid parameters>, then an assertion, i.e. via the NT_ASSERT macro, is raised". This is achieved by wrapping the call in a SEH frame, in the end it looks like this:

NTSTATUS caught = STATUS_SUCCESS;
__try {
    MyInternalRoutine(NULL); // NULL here is an invalid parameter
}
__except (EXCEPTION_EXECUTE_HANDLER) {
    caught = GetExceptionCode();
}
if (caught == STATUS_ASSERTION_FAILURE) {
    // Record test success
} else {
    // Record test failure
}

Naturally, building this in DEBUG configuration is required (due to use of NT_ASSERT). This approach works on the generally available versions of Windows client, like 19045, 22631 or 26100 etc. that we've tested.

Last week I was probably the first person to run these against an Insider Preview build of Windows. With the latest canary ring build (27871 at the time) installed, to my surprise got a green screen of death, KMODE_EXCEPTION_NOT_HANDLED, coming from the assert test, from inside MyInternalRoutine.

I've tried replacing the NT_ASSERT with a "write to NULL" primitive - that causes a STATUS_ACCESS_VIOLATION exception which the test setup SEH frame catches successfully. So it looks like the build I have does not let you catch asserts.

Before I start digging I wonder if anyone's encountered this before. My two hypotheses at the moment are:

  1. This is an Insider build special behaviour
  2. This is a change in the next version of Windows and is not specific to Insider builds
1 Like

That would be bad...Do you have anything strange or non-standard about your build environment?

There's plenty things non-standard about the build... However I can reproduce by just making a brand new empty WDM driver project with the most basic code in it, that's outside of our build system.

Was having some trouble stepping through the kernel code that handles this, for example I could single step an entire memcpy that's deep in the assertion logic in NT, but not step over/step out - attempting that would just terminate the KD connection and hang the VM for some reason.

Will continue - maybe by scripting to prevent my "t" key from wearing out.