Critical Device Database TIP

On a fairly regular basis, Bob Golding, our resident GES storage guru, sends out debugging tips to our group. We thought our blog readers would find value in these tips so we’re posting one here. Let us know what you think of the nugget.




Hi everyone, Bob here.  Today I thought we’d have a little discussion about the Critical Device Database (CDDB) in the registry and an issue that can be caused when a device is not contained there.  This database stores configuration data for new devices that must be installed and started before the Windows components that normally install devices have been started.  The idea behind the critical device database is to allow the installation of devices without using user mode plug-and-play manager.   If a device is determined to be new, this database is queried to see if the information needed to install it are present. 

What was the issue?

A customer was getting a Stop 0x7B (Inaccessible_Boot_Device) after they installed a BIOS update.  Further investigation via the debugger using the !devnode command showed the following issue with a few devices:

         DevNode 0x8631f008 for PDO 0x8631f8e0

           InstancePath is “PCI\VEN_15B3&DEV_5A44&SUBSYS_5A4415B3&REV_A1\6&38f4f1f2&0&00080310”

           State = DeviceNodeInitialized (0x302)

           Previous State = DeviceNodeUninitialized (0x301)

           Problem = CM_PROB_NOT_CONFIGURED

The above device is a bridge, and according to the definition of CM_PROB_NOT_CONFIGURED, it does not have a ConfigFlags registry entry.  I saw that this same problem occurred with a few bridges.  If the bridge cannot be enumerated, devices on the bridge will not be discovered either.  The Instance ID is used to look up the particulars such as driver name and class in the HKLM\System\CurrentControlSet\ENUM key in the registry.  What happened here is the lookup failed and the system thought it was a new device.  Since based on the device class this device was needed for boot, a Stop 0x7B occurred.

What caused the issue?

When the BIOS was updated the Instance ID included the version number of the bridge.  The update increased the version number, so the Instance ID was changed.

       DevNode 0x8635ca40 for PDO 0x8634c4a8

          InstancePath is “PCI\VEN_8086&DEV_1A38&SUBSYS_02DD1014&REV_B1\3&11583659&0&40″

          State = DeviceNodeInitialized (0x302)

          Previous State = DeviceNodeUninitialized (0x301)

          Problem = CM_PROB_NOT_CONFIGURED

Looking at the registry data we could see:


So a revision change caused the issue.

What stops this from happening?

Certain devices in the system are required for boot.  The device class determines if the device is in the boot device family.  If so, the hardware ID is written to the CDDB in the registry, so that if the device is determined to be new, it can be found there during boot.

Below is an example of a bridge entry.  The contents of the pci#ven_8086&dev_244e contain the driver and the class.  This is enough to get the device started for boot.  The user mode PNP manager will complete the installation.


How come this bridge was not there?

When the INF was run, the device class was set to “unknown” class, so the OS did not know to write the information in the CDDB.  

What was done to correct the problem?

The BIOS update was temporarily reverted, and then the correct install package was found with the correct INF that has the bridges defined as a system device.  The device was re-installed (pre-update) so the device could be written properly in the CDDB, then the BIOS update was reapplied without a problem.



Comments (6)

  1. Nakul Patel says:

    how does one revert a BIOS update?

  2. nc says:

    @Nakul Patel

    Apply the previous version, or save the current version before updating, and apply that.

  3. Drewfus says:

    “When the INF was run, the device class was set to “unknown” class, so the OS did not know to write the information in the CDDB.”

    I don’t understand this. Why was the class set to unknown, instead of HDC or whatever it was? The class data is in the inf, so why did this occur?

    Also, i’m not understanding why the problem occured *at all*. Presumably, being a boot critical device, the following key would have already existed (as your post explains):




    is more general than




    So , after the BIOS update, the system decides there is a new device (can’t find it under Enum), so go looking for a match in CDDB, finds a compatible Id, and away we go. What’s the problem?

    Also, can you tell me something about ConfigFlags? Purpose, possible settings, etc. Thanks.

    [ Only certain device classes get written to the CDB. Unknown is not one of them. The inf writer determines the class be the class guid. Also the OS did not think it was the same device because the instance ID’s were different. The issue was the device was never written to the CDDB because the class was unknown. Bob ]
  4. Drewfus says:

    I understand your points, but i think i’m getting bogged down with the implications of "When the INF was run…".

    I’ve seen firmware updates change device revision numbers on things like printers, and consequently PNP Manager prompting for drivers for the "new" device (this was actually on W2K). This makes perfect sense.

    Obviously only boot critical devices are going to be added to the CDDB, and Unknown and Printers aren’t defined as boot critical. But i would have thought that BIOS updates would be changing revision numbers of HDCs often enough that i would have come across this issue before, except that since the CDDB entry is almost always only specific down to Dev or Subsys, that a change in Rev would have been handled by the existing CDDB entry anyway (as i queried about above). So i still don’t quite get it. 🙁

    Anyway, ive seen much advice on this subject, for example, changing to AHCI mode, where the author claims that it is not only necessary to pre-load the CDDB key and services key with basic values, but also to hack the Enum key, and add various subkeys to the service key. I understand that this is nonsense – the Enum key never needs to be hacked in a manner that fakes device detection, and that the most that needs to be done besides the basics is to tell PNP where to find drivers so that it can complete the installation of the new device.

    Any further info on this subject or more generally on device detection and install would be greatly appreciated.

  5. Dave says:

    With Windows 8 / Windows 2012 HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlCriticalDeviceDatabase is not available.

    Can some one explain how CriticalDevices are loaded in Windows 8 / 2012 ?

  6. says:

    HKLMSYSTEMCurrentControlSetControlCriticalDeviceDatabase  is not there in Windows 8 and Windows 2012

    How are these critical boot devices loaded in absence of key "CriticalDeviceDatabase"?

    [Thank you for the feedback.  We will consider adding an article on the boot process in Windows 8 in a future article.]