@Ben:
So you have no more reported driver verifier errors?
OK guys, it’s as bad as I thought.
Suppose you have a driver loaded, and Windows is backing up its pageable code sections from the file.
You disable the PNP device, but have an application keeping a handle open to the control device object (non-PNP).
Kernel initiates the driver unload, but it’s pending because there is a live driver object.
NEVERTHELESS, the handle to the driver file is closed (even though the section is still referenced by the DRIVER_OBJECT, and FILE_OBJECT is still referenced by the section object).
The driver file CAN NOW BE DELETED. If you delete a section’s backing file, all page faults will bring zeros in.
You enable the PNP device again. It succeeds, because the driver is still loaded. But any attempt to execute from a non-present code page will cause a bugcheck.
Nice, isn’t it? All because Microsoft wanted to save a couple megabytes of page file (which costs, like 0.01 cent or less?).
The lack of the backing file – how do you know that is what is happening for this OP’s case?
@Tom McDermott:
Because the OP’s crash happens when the driver image gets replaced (deleted or copied over).
If the file is truncated and rewritten, the page-in brings a page from the offset of the original file, but with new contents of the file, which contains bogus instructions.
The main issue here is that the driver loader closes the handle to the image file before the driver is (allowed to be) unloaded from memory. This allows the file to be overwritten, and then page-in brings the new file contents.
The driver’s pageable sections are supported by a pagefile. The system doesn’t keep opened file objects for drivers so it is unable to pagein from the *.sys files.
Thanks, very interesting analysis. It’ll be interesting to hear what Microsoft have to say when they get back to us with some kind of solution. I wonder what is different in Redstone 1…
Yes, we’re currently running with no driver verifier errors…
> Suppose you have a driver loaded, and Windows is backing up its pageable code
sections from the file.
… apart from the fact that it does not - instead, it relies upon the pagefile for this purpose.
Driver in-memory images are not related to disk files, because, unlike “regular” images, there is no need for accessing the file after a driver gets loaded - its code and data are either going to be in RAM all the time (i.e. its non-pageable code and data), or backed up by a pagefile (i.e. its pageable sections).This is why you can delete .sys file of a loaded driver without a problem. A “regular” executable image is a different beast - although its data section and friends (like .bss) are backed up by the pagefile, its code section is backed up by its on-disk file, rather than a pagefile. This is why you cannot either delete or modify a file that backs up a running process.
As you can see, your suggestion is unfounded…
Anton Bassov
Drivers are no longer backed by the page file. just like user mode binaries, they are now backed by the file on disk.
Get Outlook for Androidhttps:
On Thu, Aug 11, 2016 at 5:49 AM -0700, “xxxxx@hotmail.com” > wrote:
> Suppose you have a driver loaded, and Windows is backing up its pageable code
>sections from the file.
… apart from the fact that it does not - instead, it relies upon the pagefile for this purpose.
Driver in-memory images are not related to disk files, because, unlike “regular” images, there is no need for accessing the file after a driver gets loaded - its code and data are either going to be in RAM all the time (i.e. its non-pageable code and data), or backed up by a pagefile (i.e. its pageable sections).This is why you can delete .sys file of a loaded driver without a problem. A “regular” executable image is a different beast - although its data section and friends (like .bss) are backed up by the pagefile, its code section is backed up by its on-disk file, rather than a pagefile. This is why you cannot either delete or modify a file that backs up a running process.
As you can see, your suggestion is unfounded…
Anton Bassov
—
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></https:>
>sections).This is why you can delete .sys file of a loaded driver without a problem.
True only pre-Win10
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
So, the reboot will fix it?
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> The main issue here is that the driver loader closes the handle to the image file before the driver is (allowed to be) unloaded from memory. This allows the file to be overwritten, and then page-in brings the new file contents.
>
> So, the reboot will fix it?
@Maxim
Yes… although the customer who’s been hitting this was a big bank… I decided against telling them that if they uninstalled the older version of our product, rebooted, and installed the new one they’d be fine… Not so easy to do for 30,000 PCs 
Fortunately they only have a small group running with Device Guard so far so they can just have it turned off until MS come up with a fix.
@Ben:
I suggest you file a bug with Microsoft.
The driver image handle should not be closed before the driver object is closed. Ideally, DRIVER_OBJECT should keep a duplicate of a handle, and only its object close handler should close the handle.
As you can see, your suggestion is unfounded…
I wish I were as blissfully ignorant of the new Windows’ misfeatures as you are.
> I wish I were as blissfully ignorant of the new Windows’ misfeatures as you are
Well, for the last 10 years my only concern about the Windows features has been all about the ease of defenestration of a particular Windows version (in a sense of throwing Windows out of the computer, of course - in a sense of throwing a computer out of the window the complexity of the task is the same for all Windows versions, although the probability of having to resort to “type 2 defenestration” is, indeed, much higher with more recent ones)…
Anton Bassov
> I suggest you file a bug with Microsoft.
@Alex - Yes, myself and Tom have both raised issues (see a few posts up). Microsoft are trying to work out a solution at present. Apparently the issue doesn’t occur in Redstone 1…
@Ben:
My thinking was that the manifestation we see (GsDriverEntry - stopping at entry point of driver due to page not having execute privilege) is what happens when HVCI rejects the driver. Which is plausible, because we know we are not fully compliant yet. (Although why wouldn’t it also be rejected in Redstone?)
Then what doesn’t make sense is if your driver passes driver verifier and is presumably fully compliant, then why are you seeing this issue?
My thinking was that the manifestation we see (GsDriverEntry - stopping at entry
point of driver due to page not having execute privilege) is what happens when
HVCI rejects the driver
Well, our issue only occurs when one driver is unloaded and then a new larger/smaller/later version of the same driver is then loaded. You can load/unload the first driver as many times as you like without problems. So it would seem strange if the driver was blocked for breaking the rules only in these peculiar conditions.
@Ben:
What build is Redstone 1?
Also, this issue doesn’t simply affect your case. It affects other driver update cases when the driver has non-PNP device objects holding its unload.
The workaround for the issue is (a good advice overall): DO NOT USE PAGEABLE CODE OR PAGEABLE DATA SECTION.
Peter
OSR
@PSRDrivers