Hi,
I am seeing different behavior for DriverPackageInstall() which we use to
copy driver files during updates.Sometimes it copies driver files without
error but sometimes it gives access denied and mark it in registry to copy
during next boot.
MoveFile: ‘C:\Windows\system32\DRIVERS\SETEB59.tmp’
flq: to:
‘C:\Windows\system32\DRIVERS\MySCSISys.sys’
!!! flq: MoveFile: FAILED!
!!! flq: Error 5: Access is denied.
flq: {SPFQNOTIFY_FILEOPDELAYED}
cpy: DrpSetRegFileProt
‘C:\Windows\system32\DRIVERS\MySCSISys.sys’ Status=0 Class=OEM Legacy
flq: {SPFILENOTIFY_FILEOPDELAYED}
flq: {SPFILENOTIFY_FILEOPDELAYED -
exit(0x00000000)}
flq: {SPFQNOTIFY_FILEOPDELAYED - returned
0x00000006}
flq: Caller applied security to file
‘C:\Windows\system32\DRIVERS\MySCSISys.sys’.
! flq: Targetfile
‘C:\Windows\system32\DRIVERS\EmcpMpx.sys’ marked to be moved from
‘C:\Windows\system32\DRIVERS\SETEB59.tmp’ on next reboot.
I understand that driver files are loaded by OS but in that case it should
fail always or is that OS unloads the driver file once driver code is
resident in memory?
Thanks for help
Ash
Prior to Windows 10 (with, I think, one exception back in Windows NT V3.5 IIRC), Windows has always backed drivers with the paging file. This meant that the executable (.sys) file could be overwritten with a new file (for example).
Starting in Windows 10 this is no longer the case. When you try to overwrite the existing driver file, you get an error. You have to rename the existing file driver binary, and THEN copy the new version of the driver file.
I *thought* the driver install process was going to take care of this automatically, but if you’re seeing a difference depending on the OS version, this might explain it.
Peter
OSR
@OSRDrivers
Pre-Win10 the .sys files are NOT held open while loaded. You can replace and reload.
In Win10, the loaded .sys file is held open, just like user-mode binaries. Don’t know whether this is true for boot-start drivers (loaded by the bootloader and not by MmLoadSystemImage).
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
“Ashish Goyal” wrote in message news:xxxxx@ntfsd…
Hi,
I am seeing different behavior for DriverPackageInstall() which we use to copy driver files during updates.Sometimes it copies driver files without error but sometimes it gives access denied and mark it in registry to copy during next boot.
MoveFile: ‘C:\Windows\system32\DRIVERS\SETEB59.tmp’
flq: to: ‘C:\Windows\system32\DRIVERS\MySCSISys.sys’
!!! flq: MoveFile: FAILED!
!!! flq: Error 5: Access is denied.
flq: {SPFQNOTIFY_FILEOPDELAYED}
cpy: DrpSetRegFileProt ‘C:\Windows\system32\DRIVERS\MySCSISys.sys’ Status=0 Class=OEM Legacy
flq: {SPFILENOTIFY_FILEOPDELAYED}
flq: {SPFILENOTIFY_FILEOPDELAYED - exit(0x00000000)}
flq: {SPFQNOTIFY_FILEOPDELAYED - returned 0x00000006}
flq: Caller applied security to file ‘C:\Windows\system32\DRIVERS\MySCSISys.sys’.
! flq: Targetfile ‘C:\Windows\system32\DRIVERS\EmcpMpx.sys’ marked to be moved from ‘C:\Windows\system32\DRIVERS\SETEB59.tmp’ on next reboot.
I understand that driver files are loaded by OS but in that case it should fail always or is that OS unloads the driver file once driver code is resident in memory?
Thanks for help
Ash
> Starting in Windows 10 this is no longer the case.
Do you know is it also true for boot-start drivers?
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
Yes. This is exactly what I am looking for, In case system boots from SAN
devices, then how SCSI adapter driver will updated? This is because
Registry entry which specifies drivers to be renamed on next boot resides
on BOOT disk and disk is not seen until SCSI Adapter driver is loaded. This
is what I guess is causing the issue?
Is there any other way to update bus driver…
Thanks
Ash
On Wed, Sep 23, 2015 at 12:29 AM, Maxim S. Shatskih
wrote:
> > Starting in Windows 10 this is no longer the case.
>
> Do you know is it also true for boot-start drivers?
>
> –
> Maxim S. Shatskih
> Microsoft MVP on File System And Storage
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> In Win10, the loaded .sys file is held open, just like user-mode binaries.
Don’t know whether this is true for boot-start drivers (loaded by the bootloader
and not by MmLoadSystemImage).
I tried to rewrite NDIS.sys (after resetting security descriptor) and it worked. And Windows did not boot, as expected. Are you sure this is the case?
Additional: Sorry for the previous comment.
It looks like NDIS.sys behaves somehow differently and can be rewritten while loaded. Other drivers (including boot disk miniport drivers, like LSI_SAS.sys) are kept open and you get sharing violation error when you try to open them for write access.
Tested in clean installation of Windows 10 in VMWARE.