While exercising my new driver, I got a BSOD which said “unexpected kernel mode trap.”
I didn’t get a crash dump, and I’ve since set my system options to create one, so if this happens again, I should be able to analyze the dump file. Since it’s most likely in my kernel mode driver, I assume that a kernel dump will be sufficient (anyone disagree?).
However, even if I find where my driver code was causing the crash, I’d like to do better than that.
Question:
Can someone tell me if there’s a way to intercept any bugchecks, etc., so that I can gracefully exit the driver routine that is running? Something like registering a bugcheck hook function, or a __try / __except construct or C++ try block?
On Jan 2, 2018, at 9:52 PM, xxxxx@rolle.name wrote:
>
> Question:
>
> Can someone tell me if there’s a way to intercept any bugchecks, etc., so that I can gracefully exit the driver routine that is running? Something like registering a bugcheck hook function, or a try / except construct or C++ try block?
No. A bug check only happens when the operating system detects an inconsistency, and inconsistencies in the kernel are not recoverable. Many times, the inconsistency can only be detected long after the triggering driver has done its damage.
If you want more real-time control, hook up a kernel debugger. You can trap the BSOD and explore the system state immediately.
—
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
What you asked about KeBugCheckEx interception, that is definitely possible. It was abused for an early-days PatchGuard exploit to continue patching the Windows Kernel on 64-bit systems, and the method worked because when KeBugCheckEx would be called, it’d not proceed due to the hook and thus the system would not crash.
However, this was patched by Microsoft and it was never stable or safe. The Windows Kernel enforces a BSOD crash for a reason… When you mess up in kernel-mode, the memory becomes broken. When you mess-up in user-mode, the process has its own virtual memory, and thus the process can just crash and be started up again. Of course, in kernel-mode this isn’t the case because you have system-wide memory access, and also to memory you cannot access from user-mode… Belongs to the Windows Kernel.
Don’t try and block BSODs. Instead, try to develop good, safe and stable code which is likely not to cause a bug-check.
Use !analyze -v to find out more details on the BSOD crash with the dump file, and do some kernel debugging with your driver component to try and discover what the issue might be (also using the dump file as a resource).
Test, test, test, test and test. Never stop testing. Do not release a kernel-mode component in any software until you’ve extensively tested it so much that your hands are black and blue. Penetration test it as much as possible. Literally intentionally try to break it as much as possible, then make it stable by fixing the way you broke it. And do this so much that it becomes really stable and secure.