by Last Update: 16 May 2024 (11:30 US Eastern Time — see bottom of the blog post for summary of updates)
We significantly updated this blog on 13 May 2024, to reflect the fact that the problem appears to be a bug that is only present when Verifier is enabled via the GUI. The problem does not occur when Verifier is enabled via the command line.
TL;DR Starting sometime in Windows 11, a bug was introduced in Windows Driver Verifier’s GUI interface caused Verifier to no longer bug check or breakpoint when it encounters most issues. Instead, it (silently) writes an entry to the system event log. The problem does not occur when Verifier is enabled via the command line. If you, like us here at OSR, have been enabling Verifier using the GUI and testing on Windows 11 expecting it to actively tell you if you’ve made serious mistakes… you’re now in the position of not knowing if the drivers that you’ve tested and shipped are as solid as you thought they were. Work around: Test your drivers with Driver Verifier enabled on Windows 10 (or earlier) or enable Driver Verifier (on any build of Windows, including Windows 11) using the command line.
Let’s start with a little quiz, shall we? Here’s a simple entry point in an example WDF driver:
Let’s say you send 3 read requests to this driver, and the driver’s NothingEvtRead Event Processing Callback is invoked each time. Now, let’s further stipulate that the driver never frees the pool it allocated by calling ExAllocatePool2 in this callback. In short, you have a very obvious, and serious, pool leak.
NOW (finally) the question: If you were testing this driver with Windows Driver Verifier enabled, and you had the debugger hooked up, and you unloaded this driver… what would you expect to happen?
You’d expect the system to bug check, right? With Driver Verifier telling you the driver was leaking pool, right? Like this:
Right? And you track it down using !verifier 3, and get this (in meaningful part):
Right? And you’d immediately say to yourself: I have a pool leak! And it’s in Nothing_KMDF’s EvtIoRead Event Processing Callback, where it allocates 4K . And you’d go fix it, post haste. Congratulations, you just avoided shipping a driver with a pool leak. Bravo! And thank you, Driver Verifier.
Well, if you were testing your driver on any version Windows prior to Windows 11, that’s what would happen.
Now, the problem: If you were doing this test on Windows 11… and if you enabled Driver Verifier via the GUI... the system wouldn’t crash. In fact, you’d get no notice in the debugger whatsoever about your pool leak. So, you’d remain blissfully ignorant of this issue unless you somehow managed to look in the system Event Log (who does that?), where you’d see this little beauty:
And if you dug into it further, by looking at the details tab, you’d see:
Hmmm… RuleID 0x62. Of course, no idea what that IS. How awesome is that? Assuming you could somehow figure out that RuleID 0x62 is “pool leak” you’d be able to get exactly no information at all on what how much pool was leaked or where the leak occurred. That’s definitely not “bringing me closer to what I love.”
We would be righteously indignant at this change if it only affected pool leaks. But, guess what? It affects the majority of Driver Verifier bug check codes. In fact, based on our early testing and observation here at OSR, it seems to affect the following bug check codes:
| Bugcheck Code | Argument1 Range |
| 0xC4 | 0x00 – 0x1FFF |
| 0xC4 | 0x20000 – 0x43FFF |
| 0xC4 | 0x71000 – 0x82FFF |
| 0xC4 | 0x91000 – 0x94FFF |
| 0xC2 | 0x00 – 0xFFFFF |
| 0xC9 | 0x00 – 0xFFF |
| 0x19 | 0x2000 – 0x2FFF |
It is important to note that if you enabled Driver Verifier via the command line (regardless of the version of Windows on which you’re testing) you will indeed get the expected crash behavior. So, if you’ve seen different behaviors in your lab (where you might have enabled Verifier via the GUI) and in your CI/CD pipeline tests (where you’d be enabling Verifier via the command line) this bug would account for that behavior.
We have been in touch with our friends at Microsoft, and they (after some investigation) have confirmed that this is indeed a bug, and that it only applies if the GUI interface to Verifier was used. The Microsoft devs have also said that the bug has been fixed, and indeed in our testing the proper behavior has returned in the Canary build we tested “26080.1.amd64fre.ge_release.240308-1400.” There’s no word on when we might see this fix in a mainstream release or whether this fix will be backported to older Win 11 systems. And while we can’t say for sure which specific builds were affected, we can say that our random checking shows this bug has been around Windows 11 “for quite some time” (on the order of years).
Once you know about the problem the work around is fairly simple:
Test your drivers on Windows 11 ONLY with Driver Verifier enabled via the command line, or on Windows 10 or earlier. Under no circumstances should you enable Driver Verifier via the GUI on Windows 11 and expect it to usefully alert you to any deficiencies it may find.
Summary of Updates:
16 May 2024, 11:30: We have permission to state that Microsoft has accepts that this is a bug and that it will be fixed.
13 May 2024, 17:30: We can confirm that the problem only occurs if you’ve enabled Windows Driver Verifier using the verifier.exe GUI. If you enabled Driver Verifier via the command line, the problem does not occur!
09 May 2024, 16:30: By our testing, this behavior no longer appears in Windows 11 Build 26080.1.amd64fre.ge_release.240308-1400 (which is the latest Canary build available when this was written). So, in that build at least, we’ve observed that pool leaks with Driver Verifier enabled do indeed bug check when the driver is unloaded.
OSR Open Systems Resources, Inc.