OS - WinXP SP2 64-bit I trying to install over sysprep.exe the ported NVMe driver that replaces the protected storport.sys file. I have the right options in the sysprep.inf file but they only work with drivers that do not modify system files: Code: [Unattended] OemSkipEula=Yes ConfirmHardware=No DriverSigningPolicy=Ignore NonDriverSigningPolicy=Ignore UpdateInstalledDrivers=Yes During the installation of the NVMe driver, a warning appears twice where I have to click the Continue Anyway button to continue: At setupapi.log I have such a message: Code: #-336 Copying file "c:\drivers\2_nvme\storport.sys" to "C:\WINDOWS\system32\DRIVERS\storport.sys" via temporary file "C:\WINDOWS\system32\DRIVERS\SET1C.tmp". #E245 The device installation digital signature failure policy has been elevated from Ignore to Warn due to a proposed replacement of a protected system file. #W366 An unsigned, incorrectly signed, or Authenticode(tm) signed file "c:\drivers\2_nvme\storport.sys" for driver "Standardowy kontroler NVM Express" will be installed (Policy=Warn, user said ok). Error 0x800b0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider. #E243 Exemption obtained for protected system file "C:\WINDOWS\system32\DRIVERS\storport.sys". How to make the system not display this warning?
One thing I always asked myself is how the bluetooth stack installers (like Widcomm, but likely also Toshiba) managed to overcome the problem. They managed to install unsigned drivers w/o any user intervention and w/o disabling permanently the SFC, driver signature enforcement or whatever. I never investigated the matter myself but is definitely something that deserved more attention.
I just found how to patch sfc_os.dll from WinXP 32-bit SP1 - change the values "8B C6" to read "90 90"
@Gelip SFC fo 5.2 x64 patch that I have is different and works too. Code: C1 44 01 00 75 -> C1 44 01 00 EB
Unfortunately it does not work. I remove the file by hand, e.g. storport.sys and after a while it appears again.
Not sure, it both keys must be there. Code: REM Disable SFC reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v "SFCDisable" /t REG_DWORD /d "4294967197" /f >nul reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v "SFCSetting" /t REG_DWORD /d "4294967197" /f >nul
Ok, I found a way that works 100% create D:\sourc folder then copy all content from WinXP SP2 64-bit ISO using Total Uninstall 2.35 make scan D:\sourc only in next step in Total Uninstall run nLite 1.4.9.3 and patch SFC Options > Next > Patches tab > SFC (Windows File Protection) > Disable next step Total Uninstall scan D:\sourc and detect changes nLite patch the SFC_OS.DL_ file: Spoiler Code: 140: CC 67 141: 6D B0 139C2: 41 90 139C3: 0F 90 139C4: 44 90 139C5: CF 90 6 difference(s) found. and set registry in HIVESFT.INF Code: HKLM,"SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon","SfcDisable",0x00010001,0xFFFFFF9D also HIVESFT32.INF for 32-bit subsystem but works without it Code: HKLM,"SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Winlogon","SfcDisable",0x00010001,0xFFFFFF9D it is enough to unpack the sfc_os.dll file from SFC_OS.DL_ using 7-Zip and replace it outside the operating system and edit in registry the SFCDisable ffffff9d value, e.g. in offline mode, loading hive the Software of target os after sysprep.exe add drivers SFCDisable value 0 can be restored to enable SFC - it works with a patched version
Yeah, I remember this, but I dont think it's the way used by widcomm. In their setup IIRC you see the usual popups about unsigned drivers, then those popups are closed automatically and the installation proceeds normally (even in x64)
I still quess they hack SFCFILES as it's not protected itself. So you can edit list with protected files and just remove it from there
Sure something like that. But that works for sure in 32bit, in x64 a unsigned driver is supposed to be not installable, so, no matter how you automate the button pushing, something more is needed. Maybe a combination of both the above techniques, maybe something else
Installing of "unsigned" driver on x64 (6.0+) involve generating signing certificate for testing (for example), and then installer can easily add it to registry and install that driver without any prompt.
Yes but once you have the self signed driver, you have to reboot to have the test-mode in place, which isn't what happens with bluetooth stacks
Whatever... it's an era I don't install the widcomm stack (and the toshiba one I use currently has properly signed drivers), so discussing further about the matter would be pointless until my laziness let me to retest them and investigate further.