Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.More Info on Driver Writing and Debugging
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
DRIVER_VERIFIER_DMA_VIOLATION (e6) follow-up
Gabe_Jones
Member Posts: 96
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.
Howdy, Stranger!
| Upcoming OSR Seminars | ||
|---|---|---|
| OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead! | ||
| Kernel Debugging | 16-20 October 2023 | Live, Online |
| Developing Minifilters | 13-17 November 2023 | Live, Online |
| Internals & Software Drivers | 4-8 Dec 2023 | Live, Online |
| Writing WDF Drivers | 10-14 July 2023 | Live, Online |
Comments
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.
Peter Viscarola
OSR
@OSRDrivers
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.
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...
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.
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!
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
, so the risk-reward ratio has them treading cautiously, as they no doubt should.
>
I'm glad to hear it!
Yes, that's exactly what they wrote.