OSD Driver Binding Issues

Hey Guys,

Weird issues going on, I am going to try and encapsulate all the information here to see if anyone can help.

Model: Satellite C50-B
Drivers - All 100% confirmed and testing, all drivers manually bound. Drivers were imported and bound to a selected model.
ISSUE - 2 different drivers… realtek card reader drivers and bluetooth do not get installed via OSD

Device ID: 10EC.5229.1179.F91B - Card Reader

I’ve tried 3 different versions of the drivers in the driver binding grid. Each time I did the OSD, i would take that EXACT same driver… and manually update the drivers for the devices… and they work!

Investigated the logs…

[Root]
Drivers="10ec.8136.1179.f91b;8086.1e20.1179.f91b;168c.0036.1b9a.28a2;8086.1e22.1179.f91b;8086.1e26.1179.f91b;8086.0166.1179.f910;8086.1e2d.1179.f91b;8086.1e03.1179.f91b;8086.1e31.1179.f91b;8086.1e3a.1179.f91b;Explicit.0;Explicit.1;Explicit.2"
Date=“2015/05/05 15:17:43”

^^^ the results from the osresults.ini driver binding on the client…

Notice the device ID of the card reader is not present?!

Well… the card reader… and the bluetooth BOTH exist in the device manager, and the driver binding grid for this model on the server…

Yet… they are not being detected and downloaded? Why??

Anyone? :smile:

Hi Willack,
Very strange problem. Believe the root of the issue is in this statement: “Notice the device ID of the card reader is not present” in the osresults.ini. As the device is not listed there the system does not recognize the fact that a driver is needed.

To investigate this further we need to take a look at the file BOMxx.trc file located in the same directory where the osresults.ini is. In this file search for “Starting Drivers Computation…” Check in there what happens to your device, this
should provide and indication on what is going on.

Another effect of the problem is that the devices listed in Binding tabs (last picture) and those considered at runtime are different. The devices in the Bindings tab are in general more complete.

To bypass the problem, you can override the runtime driver selection logic by using the “Add Driver” button to add the driver for your device in there. This will push the driver despite the list of PCI devices.

Depending on the findings in BOMxx.trc a code change may be needed to handle the device from a PCI prospective.

Hope this helps. Please keep us posted.

've tried manually adding the drivers - it’s the same result. There is no BOMxx.trc in the same directory, only an rbagent.trc.

[2015/05/05 15:17:42] A Model [Satellite C50-B PSCLGC-017074] found in binding grid [local://root/C$/Deploy/$OEM$/BigFixOSD/RBAgent/osgrid.ini].
[2015/05/05 15:17:42] A Device [8086.1e12.1179.f91b] Class [06] ClassName [BRDG] Rev [196]
[2015/05/05 15:17:42] A Device [8086.1e59.1179.f91b] Class [06] ClassName [BRDG] Rev [4]
[2015/05/05 15:17:42] A Device [10ec.5229.1179.f91b] Class [ff] ClassName [] Rev [1]
[2015/05/05 15:17:42] A Device [8086.1e16.1179.f91b] Class [06] ClassName [BRDG] Rev [196]
[2015/05/05 15:17:42] A Device [10ec.8136.1179.f91b] Class [02] ClassName [NET] Rev [7]
[2015/05/05 15:17:42] A Device [8086.1e20.1179.f91b] Class [04] ClassName [MEDIA] Rev [4]
[2015/05/05 15:17:42] A Device [168c.0036.1b9a.28a2] Class [02] ClassName [NET] Rev [1]
[2015/05/05 15:17:42] A Device [8086.1e22.1179.f91b] Class [0c] ClassName [SER] Rev [4]
[2015/05/05 15:17:42] A Device [8086.0154.1179.f910] Class [06] ClassName [BRDG] Rev [9]
[2015/05/05 15:17:42] A Device [8086.1e26.1179.f91b] Class [0c] ClassName [SER] Rev [4]
[2015/05/05 15:17:42] A Device [8086.0166.1179.f910] Class [03] ClassName [DISP] Rev [9]
[2015/05/05 15:17:42] A Device [8086.1e2d.1179.f91b] Class [0c] ClassName [SER] Rev [4]
[2015/05/05 15:17:42] A Device [8086.1e03.1179.f91b] Class [01] ClassName [DISK] Rev [4]
[2015/05/05 15:17:42] A Device [8086.1e31.1179.f91b] Class [0c] ClassName [SER] Rev [4]
[2015/05/05 15:17:42] A Device [8086.1e10.1179.f91b] Class [06] ClassName [BRDG] Rev [196]
[2015/05/05 15:17:42] A Device [8086.1e3a.1179.f91b] Class [07] ClassName [COMM] Rev [4]

The one in bold is the one thats not getting installed… weird…

I just do not get why this driver won’t bind… and what I can do… everything is properly there… the driver works when done manually… not getting detected on OSD.

Appreciate the help

Hi Willack, The device is reporting a class of “FF” that is an “Unassigned class”. We filter out those device out as it is unexpected that a device is reporting in this way. Perhaps a bios/uefi update of the machine could get rid of the strange class.
We could provide a patch that lets the FF class device filter in if you so desire. This may require a few days. To do that you need a pmr open to engage the support team. Let us know the PMR number so i can look after it.
If there is no BOMxx.trc i assume you are running a reimage scenario. (bomxx.trc files are used in bare metal, and located on the osd server directory under global\hostactivities\tasknnnnnn.).
Manually adding the driver should definitely work. First step is to look at the .trc file to see if the driver is processed as expected. It will be processed as an [Explicit.x] driver knowing the sha1 of the driver you intend to install.
Hope this helps.

1 Like

Well! I was not aware that FF class devices were filtered! That will go a long way to troubleshoot driver bindings for my clients. This makes a lot more sense now, as to why it was not working. I’ve done almost 2000 re-image/bare metal now… you’re also correct that with manually adding the device driver … it did work.

This is great information.

Yes I was switching between re-image and bare metal … the laptop is at a clients site - so re-image is obviously easier for me to test driver bindings.

I appreciate the information here… perhaps you can keep educating me a bit more…

The last driver with an issue is the ACPI bluetooth driver.

Device ID:
ACPI\TOS6205
*TOS6205

I added the non-pci driver for the device, and its manually bound.

I do not see the device listed in the osgrid.ini, or the rbagent.trc anywhere… so where can I track down the logs for ACPI device failures for drivers? I just need to get this driver working, and I will have gained a lot.

No need for a custom patch - the work I do is on a large scale across many customers… now that I know conclusively that class type FF are filtered, I can work with that without an issue.

While were on the discussion of drivers… it would be nice to see the option to sync driver binding grids between images. Imaging a customer with 10-20 different WIMs… and having to sync the exact same drivers accross each driver binding grid for every WIM. I realize, that you can copy settings from when you use a new WIM… but you can’t do it more than once… and that copies bare metal profiles, ect… I am talkign about 1 driver binding grid for multiple images… that would be awesome… :smile:

Keep the information coming!

Thanks,

Hi Willack. Glad you are making progress.
For manually bound drivers you do not see the Device ID listed in traces. You are just saying to the OSD product to add this additional driver to the system and windows will consume it at install time.
So to trace what happens to your manually bound driver we need to start with the SHA1 value of the driver that you have bound. In my sample i have manually bound a driver with B2F3D9…
The file to look at from the OSD prospective is the osresult.ini (or the xxxx.trc) but searching for the SHA1. Here is a sample of osresult.ini from a BM deployment.

If you are looking at the osresults.ini for a reimage the last Unpack=yes line may be missing. But in both cases this entry will state that the file was found and provided in input to windows.

Assuming this is the case, then we need to double check what windows thinks of this driver.

There are 2 sources of information that may help. In both of this files search for your device id “TOS6…”.

  1. In the file C:\Windows\Temp\DeploymentLogs\ZTIDrivers.log (Note after the stage 2 of a reimage computer this file should be copied under c:\program files\BigFix Enterprise\Bes Client__BesData__Global\Logs\DeploymentLogs)

  2. In the file C:\Windows\Panter\setupact.log

Hopefully at least in one of the two files you will find some useful information.

Bringing the “option to sync driver binding grids between images” forward to the development team for them to register it and keep it in store for subsequent releases.

Hope this helps… Please keep us posted on your findings.