Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

Monthly Seminars at OSR Headquarters

East Coast USA
Windows Internals and SW Drivers, Dulles (Sterling) VA, 9 April 2018

Writing WDF Drivers I: Core Concepts, Manchester, NH, 7 May 2018

Kernel Debugging & Crash Analysis for Windows, Manchester, NH, 21 May 2018


Go Back   OSR Online Lists > ntdev
Welcome, Guest
You must login to post to this list
  Message 1 of 3  
03 Jan 18 00:53
Michael Rolle
xxxxxx@rolle.name
Join Date: 27 Dec 2017
Posts To This List: 59
Protecting my driver from BSOD?

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?
  Message 2 of 3  
03 Jan 18 02:10
Tim Roberts
xxxxxx@probo.com
Join Date: 28 Jan 2005
Posts To This List: 11891
Protecting my driver from BSOD?

On Jan 2, 2018, at 9:52 PM, xxxxx@rolle.name <xxxxx@lists.osr.com> 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.
  Message 3 of 3  
03 Jan 18 12:14
Iolanda Milani
xxxxxx@gmail.com
Join Date: 31 Dec 2017
Posts To This List: 17
Protecting my driver from BSOD?

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.
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 13:09.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license