Folks,
I am seeing a problem in the field, when our installer fails to delete .sys file for a legacy (NT style) driver. The error is ACCESS_DENIED.
The installer runs elevated and normally has no problem successfully deleting this file.
The repro rate is very low ? on the order of a few machines out of millions of actual successful installations.
Can anyone think of a probable cause for this behavior? SCM is holding onto .sys file for some reason? Dreadful ERROR_SERVICE_MARKED_FOR_DELETE?
Anything?
I need to come up with the strategy of addressing this, which most likely includes an extra logging for the installer team to put in place. We have a way of pulling logs out of users? system in case of a failure.
Please let me know if anyone has an idea.
Thanks!
– Max.
Hello.
It looks like the driver is running, so someone holds the handle without
SHARE_DELETE flag preventing file from delete.
Long time ago it was possible to remove the sys while the driver is loaded,
but since Windows 7 (if I recall correctly) it is not possible.
Has the driver module been unloaded?
Thanks
2017-05-02 14:28 GMT-04:00 Max Paklin :
> Folks,
>
>
>
> I am seeing a problem in the field, when our installer fails to delete
> .sys file for a legacy (NT style) driver. The error is ACCESS_DENIED.
>
> The installer runs elevated and normally has no problem successfully
> deleting this file.
>
> The repro rate is very low – on the order of a few machines out of
> millions of actual successful installations.
>
>
>
> Can anyone think of a probable cause for this behavior? SCM is holding
> onto .sys file for some reason? Dreadful ERROR_SERVICE_MARKED_FOR_DELETE?
>
> Anything?
>
>
>
> I need to come up with the strategy of addressing this, which most likely
> includes an extra logging for the installer team to put in place. We have a
> way of pulling logs out of users’ system in case of a failure.
>
>
>
> Please let me know if anyone has an idea.
>
> Thanks!
>
> – Max.
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> showlists.cfm?list=ntdev>
>
> 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://www.osronline.com/page.cfm?name=ListServer>
></http:></http:>
A B wrote:
It looks like the driver is running, so someone holds the handle
without SHARE_DELETE flag preventing file from delete.
Long time ago it was possible to remove the sys while the driver is
loaded, but since Windows 7 (if I recall correctly) it is not possible.
This unfortunate change did not actually go in until Windows 10.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Max Paklin wrote:
I am seeing a problem in the field, when our installer fails to delete
.sys file for a legacy (NT style) driver. The error is ACCESS_DENIED.
The installer runs elevated and normally has no problem successfully
deleting this file.
The repro rate is very low – on the order of a few machines out of
millions of actual successful installations.
Can anyone think of a probable cause for this behavior? SCM is holding
onto .sys file for some reason?
Are you stopping the service, and verifying that it was successfully
stopped? When it fails, does it fail consistently on that machine?
Have you been able to get your hands on one such machine? As a
potential workaround, even if the driver is in use, you should be able
to rename the file to xxxxx.old, then copy in the new service, but if
the service hasn’t stopped, you’d need a reboot to get the new one in.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thanks folks!
Tim, that?s what I suspect as well.
The installer does attempt to stop and delete the service, but I am not sure what the result of this operation is.
My guess is that someone holds an open handle on the service (users have control/services panel open?), which precludes service from successful uninstallation and sets it to delete-pending state.
Sounds like this would hold a reference on the file and prevent successful file deletion.
Renaming/moving it won?t help much, as after the file is ?deleted?, the installer attempts to start the service with the new/updated driver binary. This will fail, as the service with the same name is already present on the system (even if it?s marked for deletion).
That?s fine, we will just force the reboot. This does not happen to often to be an issue worth fixing.
I now have enough to go on. Thanks again for your help!
– Max.
From: Tim Robertsmailto:xxxxx
Sent: Tuesday, May 2, 2017 11:54 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: Re: [ntdev] ACCESS_DENIED trying to delete driver .sys file
Max Paklin wrote:
>
>
> I am seeing a problem in the field, when our installer fails to delete
> .sys file for a legacy (NT style) driver. The error is ACCESS_DENIED.
>
> The installer runs elevated and normally has no problem successfully
> deleting this file.
>
> The repro rate is very low ? on the order of a few machines out of
> millions of actual successful installations.
>
>
>
> Can anyone think of a probable cause for this behavior? SCM is holding
> onto .sys file for some reason?
>
Are you stopping the service, and verifying that it was successfully
stopped? When it fails, does it fail consistently on that machine?
Have you been able to get your hands on one such machine? As a
potential workaround, even if the driver is in use, you should be able
to rename the file to xxxxx.old, then copy in the new service, but if
the service hasn’t stopped, you’d need a reboot to get the new one in.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
—
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:></mailto:xxxxx></mailto:xxxxx>
For what it is worth I’ve found on Windows 10 (possibly 8 as well) the OS maps the memory view of the driver to the file on disk. This is the reason the file is not modifiable.
What I’ve had to do is rename the file on disk to something else then write the new driver file in its place. That said we use a driver that isn’t able to be unloaded, so it is possible unloading the driver file releases the file. But, it is also possible that the mapping remains open for some time even after the driver has been unloading.
In any case I recommend trying to rename the file on disk to something else then write the new driver file in it’s place.
Hope this helps!
xxxxx@live.com wrote:
For what it is worth I’ve found on Windows 10 (possibly 8 as well) the OS maps the memory view of the driver to the file on disk. This is the reason the file is not modifiable.
Yes, that is the reason, but it’s only Windows 10. Not Windows 8. Not
Windows 8.1. No need to guess.
What I’ve had to do is rename the file on disk to something else then write the new driver file in its place. That said we use a driver that isn’t able to be unloaded, so it is possible unloading the driver file releases the file. But, it is also possible that the mapping remains open for some time even after the driver has been unloading.
Again, no need to guess. Once the driver unloads, the lock is released
and the file can be deleted or overwritten.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.