IntroductionHi 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_CONFIGUREDThe 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.Read more: Ntdebugging Blog
Subscribe to:
Post Comments (Atom)
Posts
0 comments:
Post a Comment