I thought I read sometime back on a MSDN article that in Windows 10, the in-place replacement of a driver so that it takes effect on next boot (for eg, for updating a volume class filter driver) will stop working as the driver files will be locked. However, when I recently tried to get back that source of info, I could not find any. But then, while searching for something else, I stumbled upon this OSR thread : https://www.osronline.com/ShowThread.cfm?link=275528
Mr. Tim Roberts says the following :
If this is just for debugging or internal use, up through Windows 8.1,
you can just copy the new driver file into place. The old driver will
be used until you reboot. That is no longer possible in Windows 10, a
change whose justification eludes me.
Can you please point me to the MSDN link where this information is available ?
I thought I read sometime back on a MSDN article that in Windows 10, the in-place replacement of a driver so that it takes effect on next boot (for eg, for updating a volume class filter driver) will stop working as the driver files will be locked. However, when I recently tried to get back that source of info, I could not find any. But then, while searching for something else, I stumbled upon this OSR thread : https://www.osronline.com/ShowThread.cfm?link=275528
Mr. Tim Roberts says the following :
If this is just for debugging or internal use, up through Windows 8.1,
you can just copy the new driver file into place. The old driver will
be used until you reboot. That is no longer possible in Windows 10, a
change whose justification eludes me.
Can you please point me to the MSDN link where this information is available ?
I’m not sure why this would be included in an MSDN page. This is an
implementation detail. Prior to Windows 10, drivers were copied to the
page file for execution, so the original file was not needed. In
Windows 10, the in-memory image is backed by the original driver file,
so it remains locked.
You can, however, rename the old file and copy the new one to the
original name.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
If the driver is not for boot device, you can simply disable all instances to cause the driver unload, copy over the sys file, and reenable the device.
If the driver is for a boot device, you can use .kdfiles for debugging.
> I’m not sure why this would be included in an MSDN page. This is
an implementation detail.
Ok, my bad.
In Windows 10, the in-memory image is backed by the original driver
file, so it remains locked.
On a Windows Server 2016 (10.0.14393) setup, with my driver loaded (volume class upper filter), I am able to delete the .sys file. On the same machine, I am not able to do so for in-box e1i63x64.sys (Intel Gigabit Adapter NDIS 6.x driver) for which it gives error (“The action can’t be completed because the file is open in another program. Close the file and try again.”). I am able to cut-paste the file Intel sys file elsewhere. Any reason for this difference in behavior ?