missing oem##.inf blocks driver unistall

Kurt_Jensen · August 26, 2016, 9:42am

We are using a third party USB product which includes their own driver installation. We are in the process of releasing a new version of our product which includes upgrading their driver installation from 1.30 to 4.0.0. During testing we have encountered cases where 1) the driver does not load when the device is attached and 2) the driver cannot be uninstalled.

Found this in setupapi.app.log after trying to uninstall using dpinst.

>> [SetupUninstallOEMInf - oem255.inf]
>> Section start 2016/08/25 14:30:36.325
cmd: dpinst /u C:\Windows\System32\DriverStore\FileRepository\performaxusb.inf_amd64_neutral_9090e985495619ff\performaxusb.inf
<<< Section end 2016/08/25 14:30:36.327
<<< [Exit status: FAILURE(0x00000002)]

The symptom appears is that oem255.inf goes missing from C:\Windows\Inf. We do not know how oem255.inf was removed. Driver installation and uninstallation is normally done via provided tools. The only time I and dpinst get involved is when the device shows up as Unknown in Device Manager. Then I find that the driver does not load and cannot be removed. If we create a file named oem255.inf in C:\Windows\Inf\ then the driver can be uninstalled.

So far we have not been able to recreate the problem. The symptom is easily recreated by installing the driver, attaching a device, removing the appropriate oem##.inf, then trying to reload or uninstall the driver.

Any idea how oem255.inf might have disappeared? I suspect it happens during installation of the new driver. Perhaps when transitioning from the old driver to the new driver. Upgrade succeeds most of the time. The disappearing oem##.inf has occurred several times in the past few months.
Why would the driver fail to uninstall?
Some database, not the registry, connects oem255.inf to the device. Any idea where this information is stored?

Doron_Holan · August 26, 2016, 10:42am

Does your third party driver package have a coinstaller or msi? If yes, we have seen third setup code manually delete the oemxxx files behind setupapi?s back. Why not just install the latest driver package and then tell pnp to evaluate it against the device? If the new package out ranks the old one, it will be installed without having to install the old ond

Sent from my Windows 10 phone

From: xxxxx@ophir-spiricon.com mailto:xxxxx
Sent: Friday, August 26, 2016 6:42 AM
To: Windows System Software Devs Interest Listmailto:xxxxx
Subject: [ntdev] missing oem##.inf blocks driver unistall

We are using a third party USB product which includes their own driver installation. We are in the process of releasing a new version of our product which includes upgrading their driver installation from 1.30 to 4.0.0. During testing we have encountered cases where 1) the driver does not load when the device is attached and 2) the driver cannot be uninstalled.

Found this in setupapi.app.log after trying to uninstall using dpinst.

>>> [SetupUninstallOEMInf - oem255.inf]
>>> Section start 2016/08/25 14:30:36.325
cmd: dpinst /u C:\Windows\System32\DriverStore\FileRepository\performaxusb.inf_amd64_neutral_9090e985495619ff\performaxusb.inf
<<< Section end 2016/08/25 14:30:36.327
<<< [Exit status: FAILURE(0x00000002)]

The symptom appears is that oem255.inf goes missing from C:\Windows\Inf. We do not know how oem255.inf was removed. Driver installation and uninstallation is normally done via provided tools. The only time I and dpinst get involved is when the device shows up as Unknown in Device Manager. Then I find that the driver does not load and cannot be removed. If we create a file named oem255.inf in C:\Windows\Inf\ then the driver can be uninstalled.

So far we have not been able to recreate the problem. The symptom is easily recreated by installing the driver, attaching a device, removing the appropriate oem##.inf, then trying to reload or uninstall the driver.

1) Any idea how oem255.inf might have disappeared? I suspect it happens during installation of the new driver. Perhaps when transitioning from the old driver to the new driver. Upgrade succeeds most of the time. The disappearing oem##.inf has occurred several times in the past few months.
2) Why would the driver fail to uninstall?
3) Some database, not the registry, connects oem255.inf to the device. Any idea where this information is stored?

—
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>

Kurt_Jensen · August 26, 2016, 11:00am

> Does your third party driver package have a coinstaller or msi?
Just WdfCoInstaller01009 as you can see below.

Why not just install the latest driver package and then tell pnp to evaluate it against the device?
When this problem occurs we see both old and new in FileRepository. Another installation has no effect. When this problem occurs the device shows up as Unknown in Device Manager and the driver will not load for the device.

In setupapi.app.log we then see

>> [DIF_SELECTBESTCOMPATDRV - USB\VID_1589&PID_A101\2ED00]
>> Section start 2016/08/26 08:57:31.004
cmd: C:\Windows\system32\svchost.exe -k netsvcs
dvi: Looking for class installer for ‘Arcus-USB’…
dvi: No class installer for ‘Arcus-USB’
dvi: Looking for co-installer modules for ‘Arcus-USB’.
dvi: No CoInstallers found
dvi: Default installer: Enter 08:57:31.016
dvi: {Select Best Driver}
! dvi: Selecting driver failed(0xe0000228)
dvi: {Select Best Driver - exit(0xe0000228)}
! dvi: Default installer: failed!
! dvi: Error 0xe0000228: There are no compatible drivers for this device.
<<< Section end 2016/08/26 08:57:31.030
<<< [Exit status: FAILURE(0xe0000228)]

Here is the inf:

; Silabs USBXpress Driver
; Copyright (c) 2013, Silicon Laboratories

[Version]
Signature = “$Windows NT$”
Class=USB
ClassGUID={36fc9e60-c465-11cf-8056-444553540000}
Provider = %ProviderName%
DriverVer=04/08/2013,4.0.0.0
CatalogFile=siusbxp.cat

; ========== Manufacturer/Models sections ===========

[Manufacturer]
%ProviderName% = USBXpress_WinUSB,NTx86,NTamd64,NTia64

[USBXpress_WinUSB.NTx86]
%USB\VID_1589&PID_A101.DeviceDesc% =USB_Install, USB\VID_1589&PID_A101

[USBXpress_WinUSB.NTamd64]
%USB\VID_1589&PID_A101.DeviceDesc% =USB_Install, USB\VID_1589&PID_A101

[USBXpress_WinUSB.NTia64]
%USB\VID_1589&PID_A101.DeviceDesc% =USB_Install, USB\VID_1589&PID_A101

; =================== Installation ===================

[USB_Install]
Include=winusb.inf
Needs=WINUSB.NT

[USB_Install.Services]
Include=winusb.inf
AddService=WinUSB,0x00000002,WinUSB_ServiceInstall

[WinUSB_ServiceInstall]
DisplayName = %WinUSB_SvcDesc%
ServiceType = 1
StartType = 3
ErrorControl = 1
ServiceBinary = %12%\winusb.sys

[USB_Install.Wdf]
KmdfService=WINUSB, WinUsb_Install

[WinUSB_Install]
KmdfLibraryVersion=1.9

[USB_Install.HW]
AddReg=Dev_AddReg

[Dev_AddReg]
HKR,DeviceInterfaceGUIDs,0x10000,“{3C5E1462-5695-4e18-876B-F3F3D08AAF18}”

[USB_Install.CoInstallers]
AddReg=CoInstallers_AddReg
CopyFiles=CoInstallers_CopyFiles

[CoInstallers_AddReg]
HKR,CoInstallers32,0x00010000,“WdfCoInstaller01009.dll,WdfCoInstaller”,“WinUSBCoInstaller2.dll”

[CoInstallers_CopyFiles]
WinUSBCoInstaller2.dll
WdfCoInstaller01009.dll

[DestinationDirs]
CoInstallers_CopyFiles=11

; ================= Source Media Section =====================

[SourceDisksNames]
1 = %DISK_NAME%,\x86
2 = %DISK_NAME%,\amd64
3 = %DISK_NAME%,\ia64

[SourceDisksFiles.x86]
WinUSBCoInstaller2.dll=1
WdfCoInstaller01009.dll=1

[SourceDisksFiles.amd64]
WinUSBCoInstaller2.dll=2
WdfCoInstaller01009.dll=2

[SourceDisksFiles.ia64]
WinUSBCoInstaller2.dll=3
WdfCoInstaller01009.dll=3
; =================== Strings ===================

[Strings]
ProviderName=“Arcus Technology”
USB\VID_1589&PID_A101.DeviceDesc=“Performax USB”
WinUSB_SvcDesc=“Performax USB WinUSB Service”
DISK_NAME=“Arcus Technology Performax USB Driver Installation Disk”

Peter_Viscarola_OSR · August 26, 2016, 3:00pm

Isn’t there a very major set of changes in the new versions of the USBXpress stuff? Like, they went form their own proprietary USB thing interface to doing something based on WinUSB?? Something like that?

Is the problem perhaps inherent in part of this upgrade process?

Do you do a remove and then an install of the SiLabs product? Or are you trying to do an upgrade? A remove/install would probably be better…

Peter
OSR
@OSRDrivers

OSR_Community_User · August 27, 2016, 12:53am

I suggest you look at the devcon tool source code. There is a command that enumerates driver packages (dp_enum) and another that deletes driver packages (dp_delete). When a package is enumerated, the oem##.inf is displayed along with the name of the company. To delete a package you just have to provide the oem##.inf previously listed.

The find command is also interesting.