Diagnosis of Driver Setup Issues in Windows Embedded Standard 7 – Part 3

  • Article
Introduction

This is the third and final blog in a series of articles which discusses the troubleshooting and diagnosis of driver installation issues in Windows Embedded Standard 7. Previously we presented the format of the SetupAPI.dev.log file and an example driver installation scenario. Now we will begin by enumerating some common driver installation issues you may encounter in Windows Embedded Standard 7.

Common driver installation issues

Most driver installation issues fall into the below categories.

  1. No compatible driver available
  2. Missing device class installer
  3. Missing dependencies
  4. Undiscoverable devices
No compatible driver available

This can arise either because there is:

  1. An in-box driver is available for a device but it wasn’t discovered.
  2. No in-box driver is available for a device.
  3. No driver update for device is available via Windows Update (WU).

Let’s start by looking at the first issue, which could be caused by a device not being connected to the target machine during setup. Below is an example from the SetupAPI.dev.log where we encounter this issue.

>>> [Setup Root Device Servicing]
>>> Section start 2010/02/23 12:29:53.078
set: This is an INSTALL.
set: Iterating through 1 <rootDevice> elements.
set: Processing device ROOT\COMPOSITEBUS\0000
set: Entering install for device ROOT\COMPOSITEBUS\0000
set: Could not open the device information element for device ROOT\COMPOSITEBUS\0000. Trying to create one. GLE = 0x00000000
set: Processing 1 <properties> elements.
set: Processing 1 <property> elements.
dvi: {DIF_REGISTERDEVICE} 12:29:53.078
dvi: No class installer for 'System devices'
dvi: Using exported function 'CriticalDeviceCoInstaller' in module 'C:\Windows\system32\SysClass.Dll'.
dvi: CoInstaller 1 == SysClass.Dll,CriticalDeviceCoInstaller
dvi: CoInstaller 1: Enter 12:29:53.078
dvi: CoInstaller 1: Exit
dvi: Default installer: Enter 12:29:53.078
dvi: Registered: ROOT\COMPOSITEBUS\0000
dvi: Default installer: Exit
dvi: {DIF_REGISTERDEVICE - exit(0x00000000)} 12:29:53.078
ndv: {DiInstallDevice(ROOT\COMPOSITEBUS\0000)}
dvi: Set selected driver complete.
dvi: Set selected driver complete.
dvi: {Build Driver List} 12:29:53.078
dvi: Searching for hardware ID(s):
dvi: root\compositebus
cpy: Policy is set to make all digital signatures equal.
dvi: Enumerating INFs from path list 'C:\Windows\inf'
inf: Searched 0 potential matches in published INF directory
inf: Searched 32 INFs in directory: 'C:\Windows\inf'
dvi: {Build Driver List - exit(0x00000000)} 12:29:53.156
dvi: {DIF_SELECTBESTCOMPATDRV} 12:29:53.156
dvi: No class installer for 'System devices'
dvi: CoInstaller 1: Enter 12:29:53.156
dvi: CoInstaller 1: Exit
dvi: Default installer: Enter 12:29:53.156
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.

In looking through the log we notice that there were no compatible drivers for this device. However, we want to verify if we have an in-box driver for this device before searching for one externally. The device ID is specified in the log, observe the below entry from the above text log section.

set: Processing device ROOT\COMPOSITEBUS\0000

Using the ICE search functionality, we can search by device ID for a package. We need to click the “Distribution share”, “Search driver hardware ids” and “Search file names in packages” checkboxes then enter “root\compositebus” in the “Find what” textbox (Note: we can enter a partial string).

clip_image002

We have found an in-box driver package for this device “Composite Bus Enumerator Driver” which can be added to our image to fix this problem.

Below is a snippet from a SetupAPI.dev.log which illustrates the second and third issues. In this case, we have verified that there isn’t an in-box driver for this PCI device and there aren’t any driver updates available via WU. Our only recourse is to search for a driver externally from the manufacturer.

>>> [Setup online Device Install (Hardware initiated) - pci\ven_110a&dev_4036&subsys_00010001&rev_09\4&4b78d08&0&50f0]
>>> Section start 2010/03/04 14:36:42.013
ump: Creating Install Process: DrvInst.exe 14:36:42.028
ndv: Retrieving device info...
ndv: Setting device parameters...
ndv: Searching Driver Store and Device Path...
dvi: {Build Driver List} 14:36:42.044
dvi: Searching for hardware ID(s):
dvi: pci\ven_110a&dev_4036&subsys_00010001&rev_09
dvi: pci\ven_110a&dev_4036&subsys_00010001
dvi: pci\ven_110a&dev_4036&cc_020000
dvi: pci\ven_110a&dev_4036&cc_0200
dvi: Searching for compatible ID(s):
dvi: pci\ven_110a&dev_4036&rev_09
dvi: pci\ven_110a&dev_4036
dvi: pci\ven_110a&cc_020000
dvi: pci\ven_110a&cc_0200
dvi: pci\ven_110a
dvi: pci\cc_020000
dvi: pci\cc_0200
cpy: Policy is set to make all digital signatures equal.
dvi: Enumerating INFs from path list 'C:\Windows\inf'
inf: Searched 0 potential matches in published INF directory
inf: Searched 35 INFs in directory: 'C:\Windows\inf'
dvi: {Build Driver List - exit(0x00000000)} 14:36:42.293
ndv: Selecting best match from Driver Store (including Device Path)...
dvi: {DIF_SELECTBESTCOMPATDRV} 14:36:42.293
dvi: No class installer for 'Ethernet Controller'
dvi: No CoInstallers found
dvi: Default installer: Enter 14:36:42.293
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.

Once we have the driver and have verified that it’s functional, we can add this driver to our image as an out-of-box driver. Below are several examples of how to implement this in Standard 7. The first two examples assume that the driver is distributed with raw driver payload (e.g. .INF, .SYS files etc.). The third example is where the driver is installed via a setup application (e.g. .EXE, .MSI etc.).

1. If using the Image Based Wizard (IBW) tool for installation, you can choose to add additional drivers by selecting the “Browse” button on the “Confirm drivers to install” screen. After pressing the “Browse” button, you can select the directories where the payload for each driver resides. You can have multiple drivers in a single directory.

clip_image004

2. If building an Answer File (AF) using the Image configuration Editor (ICE), you can add the folder containing the driver payload to the “Out-Of-Box Drivers” folder in the Distribution Share (DS). Then in ICE right click on the driver path choosing “Insert Driver Path Pass 2 offlineServicing” to add this setting to the AF. Note: choose “Insert Driver Path Pass 1 windowsPE” for boot critical drivers. As in IBW, you can have multiple drivers in one directory.

clip_image006

3. If the out-of-box driver in installed via a setup application (e.g. .EXE, .MSI etc.), you can run the setup application after booting into the image then run the Sysprep tool.

Missing device class installer

In this scenario the driver is present for the device; however upon installation a required device class installer is missing therefore the driver installation fails. For specific device setup classes, there is a required device class installer which is responsible for setup operations specific to this device setup class. Below is an example.

>>> Section start 2010/01/28 16:05:57.100
ump: Creating Install Process: DrvInst.exe 16:05:57.100
ndv: Retrieving device info...
ndv: Setting device parameters...
ndv: Searching just Driver Store...
dvi: {Build Driver List} 16:05:57.115
dvi: Searching for hardware ID(s):
dvi: scfilter\cid_417374726964
cpy: Policy is set to make all digital signatures equal.
dvi: Enumerating INFs from path list 'C:\Windows\INF'
inf: Searched 0 potential matches in published INF directory
inf: Searched 31 INFs in directory: 'C:\Windows\INF'
dvi: {Build Driver List - exit(0x00000000)} 16:05:57.193
ndv: Selecting best match from just Driver Store...
dvi: {DIF_SELECTBESTCOMPATDRV} 16:05:57.193
dvi: No class installer for 'Smart Card'

Device class installers are located in Windows components within non-driver Standard 7 packages. A Windows component is the smallest unit of installation for a Windows feature. Below is a list of all of the device class installer components for Standard 7 and what package they are contained in. Note: most are in the “Windows Embedded Edition” foundation package, so they are installed by default. However some of these components are contained in separate packages. In this case the class installer we are missing is in the “Microsoft.Windows.Hardware.Devices.ClassInstaller.SMARTCARDFILTER-DriverClass” component which is in the “Credentials and Certificate Management” package. Therefore we need to add this package to our image to fix the issue.

Driver3_1

Driver3_2
Missing dependencies

Device driver installation can fail because there are missing dependencies, which can be for any of the following:

  • Device driver dependencies
  • Device class installer dependencies
  • Device co-installer dependences

A device co-installer is a .DLL that assists in device installation. Device co-installers are called by setup as “helpers” for device class installers.

In the below snippet from the SetupAPI.dev.log we notice that we failed to load the device class installer “WindowsSideShowClassInstaller” (in AuxiliaryDisplayClassInstaller.dll).

set: Calling DIF_FIRSTTIMESETUP for class {997b5d8d-c442-4f2e-baf3-9c8e671e9e21} (Windows SideShow)
dvi: {DIF_FIRSTTIMESETUP} 15:02:08.171
dvi: Using exported function 'WindowsSideShowClassInstaller' in module 'C:\Windows\system32\AuxiliaryDisplayClassInstaller.dll'.
dvi: Class installer == AuxiliaryDisplayClassInstaller.dll,WindowsSideShowClassInstaller
!!! dvi: Loading module 'C:\Windows\system32\wpd_ci.dll' failed.
!!! dvi: Error 126: The specified module could not be found.
!!! dvi: Error 126 loading CoInstaller(wpd_ci.dll,CoDeviceInstall)
!!! dvi: Error 126: The specified module could not be found.

However we have confirmed that we have this .DLL in our image. We can verify this by searching for this .DLL using the ICE search functionality.

clip_image008

The .DLL “AuxiliaryDisplayClassInstaller.dll” for this device class installer is present in the “Windows Embedded Edition” foundation package. The actual issue is that we are missing dependencies for this .DLL. If we use the ICE search option again searching for “sideshow” we come up with a list of results.

clip_image010

We notice that we don’t have the package “Mobility Center and SideShow” in our image. This package contains needed functionality for sideshow and it brings in a device driver for sideshow (Windows Sideshow Enhanced Driver), so we try adding this package to our image and discover that it fixes our issue.

Undiscoverable devices

There are cases where a device will not be discovered within setup and/or required driver .INFs will not be included:

  • Within the Windows Preinstallation Environment Phase (WinPE) of setup certain devices cannot be discovered because there is no support for them. In Standard 7, there is no support to install from a previous operating system (downlevel phase) which can mitigate this (setup in Standard 7 always initiates from WinPE).
  • Certain driver .INF files are included by other .INF files because they contain common data for several drivers. These .INF files may not contain device IDs, so they aren’t discoverable.

To mitigate this, the following solution is suggested.

  1. Install Windows 7 Ultimate on the target machine you will install Standard 7 on, making sure that all the necessary device drivers are installed and that all of the devices are functional.
  2. Run TAP.EXE (available from the Standard 7 tools) to generate a devices.PMQ file by running “TAP.EXE /q /o” on the target machine.
  3. You can now import the generated devices.PMQ file from within IBW or ICE to add all the required driver packages to the Standard 7 image.
Conclusion

You can build on the techniques outlined here to solve more difficult Driver installation issues. There are more ideas which I will share in future articles.

For background and insight into why and how the Standard 7 in-box drivers have been componentized and packaged, look out for the whitepaper “Componentization of Device Drivers in Windows Embedded Standard 7”.

Best of luck!

- Mark

Technorati Tags: Embedded Standard,Drivers