As an important step towards automating the creation of Windows disk assets/images, we will take a closer look at the Critical Device Database (CDDB) inside the Windows registry. The goal is to transform any locally installed instance to be bootable from iSCSI without having to run a full installation onto an iSCSI disk before.
In the second part of the iSCSI mini-series, we identified the necessary changes to a normal Windows installation to make it network-bootable. We relied on a previously completed installation to obtain the corresponding registry entries. In this article, we will take it one step further and construct these entries from information we collected using Windows PE.
The CDDB dissected
If you recall this screenshot from the previous article, the CDDB
entry was located under the PCI#VEN_xxxx&DEV_yyyy
subtree.

We will now go through this entry piece by piece to find the essential parts we need for constructing our own CDDB entry.
Generic driver information

Right at the top of the entry, we find information about the driver
that belongs to this critical device. The important ones are
ClassGUID
and Service
. This tells Windows that
the device is a network adapter, and the corresponding driver service is
called E1G60
. These two values are the essential ones we
have to keep in mind. The only variable here is the service name, and
this is very easy to determine from either the driver’s
.inf
file or the registry of a running Windows PE with the
driver installed.
The device location (a.k.a. DevicePaths)
The device path describes the location of the device within the PCI
tree. In our case, it is
PCIROOT(0)#PCI(1E00)#(0100)#PCI(0100)
. This corresponds to
the following lspci -vt
output:

lspci
is not included in Windows PE by default. You can obtain it by downloading the pciutils package.
In order to understand the mapping of this output to the identifier
used by Windows, we have to lay some basic PCI knowledge foundations.
Windows takes into account the tree property of PCI. Branching off the
root bridge (bus 0
), there can be additional bridge
devices, providing more buses. Devices can provide multiple
functions, which essentially translates into unique identifiers
for PCI devices (bus, device, function, or BDF).
Executing lspci
without the tree switch -t
yields a representation of the PCI bus using those identifiers. For more
detail on PCI, you can check out dedicated articles, e.g. on osdev.
We can now analyze how the device path is constructed: Every section
describes a node within the PCI tree (either a bridge or the actual
device). In our example, there is a PCI bridge attached to the root bus
PCIROOT(0)
with device number 1e
and function
0
. The remaining path sections are of the form
PCI(DDFF)
, where DD
stands for the device
part, and FF
for the function part. For the first bridge,
this results in PCI(1E00)
, the second becomes
PCI(0100)
. Finally, the device itself is listed as device
number 1, function 0, which also becomes PCI(0100)
.
Now that we found our first two important puzzle pieces, we can move on to examine the actual contents of this entry.
Hardware Key
Usually, this part does not contain a lot of essential information,
but it has a striking similarity to the Enum
section of the
registry, which can be found under
HKLM\SYSTEM\CurrentControlSet\Enum\PCI
. In there, you will
find a similar VEN_xxxx&DEV_yyyy
key, which in turn
contains a subkey called Device Parameters. This subkey
directly corresponds to the HardwareKey
section of the CDDB
entry.

The Enum
section lists all devices that Windows has
enumerated in a running system. That means it is possible to extract
this from Windows PE as well, as long as the hardware is present.
One noteworthy quirk is that there are elements in there that
interfere with the boot process and have to be removed before importing
them to the CDDB. At the time of writing, these are
InstanceIndex
, Routing Info
, and
Affinity Policy - Temporal
. Furthermore, a value named
PreInstalled=1
is added.
Software Key
The Software Key
subkey contains far more values. From
the looks of it, this is basically the entire driver configuration, plus
some settings for how Windows handles this driver. It is difficult to
tell which values are absolutely essential, because they appear to be
somewhat interdependent. Luckily, this section again has a striking
similarity to another spot in the registry, this time under
HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}
.

This subtree contains a list of network devices Windows has
configured. Most of them are internal devices like Miniports, but there
will be one that contains a field called DeviceInstanceID
that matches the device and vendor ID of the network adapter. The
subkeys of this entry need to be copied to the SoftwareKey
section, with some modifications.
First of all, values that do not correspond to driver parameters
(listed under Ndi\Params
) should be removed, except for
NetCfgInstanceId
, *IfType
,
*MediaType
, and *PhysicalMediaType
.
Furthermore, four additional values need to be added:
PreInstalled=1
BootNIC=1
Characteristics=dword:00000084
BusType="5"
The Service Entry
The last missing piece is the service entry that describes the actual
driver. The essential value here is the ImagePath
, which
contains the location of the driver binary. This entry can be found in a
running Windows instance under
HKLM\SYSTEM\CurrentControlSet\services\<service_name>
.

This entry can also be copied to the same location in the new image.
The only modification that might be necessary is to remove the subkeys
Enum
and Parameters
, if present.
Putting it all together
With all those puzzle pieces together, we can summarize the steps to transform a local disk installation:
- Boot Windows PE (in our case, based on Windows 7) on target machine
- Retrieve
lspci
output and determine device path - If necessary, load network driver
(
drvload <driver.inf>
) - Export class, enum, and service entry
- Determine PCI vendor/device id
- Construct CDDB and service entries from the obtained information and registry values
- Apply the registry changes to the installed OS (either offline or by booting it from disk)
Caveats
The biggest drawback is of course that a machine with the respective hardware is still needed. Unfortunately, any attempt to forge the CDDB entry just from driver files has failed so far. The CDDB mechanism has proven to be fairly sensitive to missing or incorrect information. But the method we discussed in this article is definitely a significant improvement to the previous approach of installing to an iSCSI disk to retrieve the entries.
What next
Given this method, it is possible to incorporate necessary registry modifications in an automated deployment process. Creating or duplicating golden images is very simple, as well as customizing installations during deployment.
For example, given a golden image of a stock Windows 7 installation, customizations can include different sets of software, drivers, or even updates. As an example of this use case, we will discuss deploying an updated Windows 7 image using the Microsoft Deployment Toolkit in an upcoming article.