DRIVER_VERIFIER_DMA_VIOLATION (e6) follow-up

I posted some time back about a DRIVER_VERIFIER_DMA_VIOLATION (e6) I was seeing. I recently realized that even though the saga is (mostly) concluded, I’d never posted a follow-up here. Things that have happened in the intervening two years:

  • The documentation has been updated to reflect @“Scott_Noone_(OSR)”'s finding that the abovementioned bugcheck can occur without Driver Verifier
  • After much digging/debugging/reading specs, I found that the problem I saw was due to a deficiency in the way that Microsoft’s Kernel DMA Protection programmed the IOMMU when handling PCI or PCI-X devices behind a PCIe-to-PCI/PCI-X bridge.
  • I convinced Microsoft that this was a bug. They provided a private build of the OS that eliminated the problem in my tests.
  • They also published an article about the problem.
  • The fix has found its way into Windows 11 Insider Preview Dev Channel Builds. I’m still unsure whether it will be backported to Windows 10.

@gyroblau, did you ever get a resolution to your problem? If not, you may want to see if the Windows 11 Insider Preview Dev Channel build fixes it. It sounds like the same problem. Note that Microsoft’s fix only applies to PCI, not PCI-X, but it looks like any reference to PCI-X in your post was inadvertent.

THANK YOU Mr. @Gabe_Jones! and BRAVO for being dedicated enough to (a) follow-up on this bug, (b) get the docs fixed, (c) argue enough to get the code fixed properly, (d) Letting us here know what the issue is.

Isn’t it unfortunate, that MSFT doesn’t have any mechanism at all to collect and make-known outstanding issues like this? They have to resort to putting a note in the docs for the crash code. Well, at least they did that.

Bravo to the folks at MSFT who stepped-up and got this fixed, as well.

We had opened a case at Microsoft support in November 2021.
Mid December 21 we got the following answer:

“I have verified the info and this appears to be a known issues which is fixed in latest Windows 11 insider build.
We are in the process of backporting this bug to previous release of Windows but this is going to take some time because of holidays.”

We tested insider build number 22518 ourselves and the error did not occur with this build.

Sorry, don’t know more.

1 Like

We are in the process of backporting this bug to previous release of Windows

Is that really what they said? I’ve heard of backporting features and fixes to earlier versions, but it’s a new level of compat to backport the bugs, too… :wink:

@“Peter_Viscarola_(OSR)” said:
THANK YOU Mr. @Gabe_Jones! and BRAVO for being dedicated enough to (a) follow-up on this bug, (b) get the docs fixed, (c) argue enough to get the code fixed properly, (d) Letting us here know what the issue is.

No problem. I’m not sure that (b) was even me. I recall noticing that it got done; I don’t recall whether I had anything to do with it!

Bravo to the folks at MSFT who stepped-up and got this fixed, as well.

Even with Premier Support, it took quite a while to get to the right person. Once I got there, though, she immediately understood the problem and got a fix out quickly, and even was able to discuss some other tangentially related concerns I had. Getting the fix into a build that my customers can use has been another matter entirely: apparently the number of people that care about legacy PCI in a bus that would be marked as external (Thunderbolt/cabled PCIe chassis, e.g.) and that want Kernel DMA Protection enabled is very low :smiley:, so the risk-reward ratio has them treading cautiously, as they no doubt should.

@gyroblau said:

We tested insider build number 22518 ourselves and the error did not occur with this build.

I’m glad to hear it!

@Tim_Roberts said:

We are in the process of backporting this bug to previous release of Windows

Is that really what they said? I’ve heard of backporting features and fixes to earlier versions, but it’s a new level of compat to backport the bugs, too… :wink:

Yes, that’s exactly what they wrote.