We have a few driver packages that we pre-install in the driver store on Windows with SetupCopyOEMInf, following Microsoft's suggested procedures. This process has worked properly for years; no problems on XP, Vista, 7, and even 8.
While evaulating Windows 8.1 RTM, we found that our drivers were no longer pre-installing.
Checking the setupapi.dev.log, I found:
!!! sto: Failed to query boot critical status of device class. Error = 0x00000002
and later:
!!! idb: Failed to query inbox status of device class {ff646f80-8def-11d2-9449-00105a075f6b}. Error = 0x00000002
!!! idb: Failed to publish 'C:\Windows\System32\DriverStore\FileRepository\[ourinfname].inf_x86_3361fc76cd85b678\[ourinfname].inf'. Error = 0x00000002
I've poured through documentation, trying to find out what we're doing incorrectly.
Preinstalling from the commandline with pnputil.exe -a or using InstallScript's DIFxDriverPackagePreinstall() produce the same results.
The drivers work on Windows 8.1 if we DON'T try and put them in the driver store. The preinstallation also works if we upgrade a Windows 8 machine that already had our drivers on it to Windows 8.1. In either case, once it's working, it continues to work.
Why is this failing on Windows 8.1?
After two weeks of digging and debugging, it turns out the problem was with our Device Class GUID.
After stripping our INF down to the bare minimum and comparing with another INF that DID properly preinstall on Windows 8.1, I realized that the only difference between the two was the class GUID. I did a quick search for ff646f80-8def-11d2-9449-00105a075f6b and turned up over a thousand hits; not exactly what you want to see from a unique identifier.
I then looked back through 12 years of version control, and found that the person responsible for originally creating our device drivers didn't change the GUID in the wizard-generated INF from the Win2K DDK.
Creating a new unique class guid solved the problem, and our drivers preinstall properly on Windows 8.1.
I don't know if Microsoft is blocking preinstallation attempts with that GUID specifically, but the bottom line is: if an example says to change the GUID, CHANGE IT!
Here's the sample code for completeness. Don't do this:
;; ********* PLEASE READ ***********
;; The wizard cannot create exact INF files for all buses and device types.
;; You may have to make changes to this file in order to get your device to
;; install. In particular, hardware IDs and logical configurations require
;; intervention.
;;
;; The Win2K DDK documentation contains an excellent INF reference.
;--------- Version Section ---------------------------------------------------
[Version]
Signature="$Windows 95$"
Provider=%ProviderName%
; If device fits one of the standard classes, use the name and GUID here,
; otherwise create your own device class and GUID as this example shows.
Class=NewDeviceClass
ClassGUID={ff646f80-8def-11d2-9449-00105a075f6b}
My previous answer was actually a bit of a red herring. While one should definitely not use the GUID in the sample INF, the REAL problem ended up being with our installer. Turns out, our installation was trying to pre-create the registry key for the class:
HKLM\SYSTEM\CurrentControlSet\Control\Class\{FF646F80-8DEF-11D2-9449-00105A075F6B}
Removing this from our installer fixed the problem.
Microsoft must have changed how driver preinstallation works under the hood from previous versions of Windows.
