Device Manager Through Firmware Engineer Eyes

How to read Windows Device Manager symptoms as ACPI, PCI, resource, and firmware handoff clues.

2 min read
Shell & Firmware Tools cover

Device Manager is usually treated as a Windows tool.

For firmware engineers, it is also a mirror of firmware handoff quality.

An Unknown Device is not only a driver problem. It may mean the OS saw an ACPI device with _HID but could not bind a driver. A missing device may mean _STA returned unavailable. A resource conflict may point back to _CRS.

Symptom map

Item Value Note
Unknown Device Identity exists, driver missing Check _HID, _CID, hardware ID, compatible ID, and INF matching.
Device missing Not enumerated or hidden Check PCI enumeration, ACPI _STA, setup policy, power/reset, and table generation.
Code 10 Driver failed to start Check resources, firmware config, _DSM, power state, interrupts, and device-specific logs.
Resource conflict Bad or overlapping resource Check _CRS, IRQ, GPIO, I2C/SPI resources, MMIO windows, and PCI BARs.
Power issue Runtime PM failure Check _PS0/_PS3, _PR0/_PR3, _PRW, D-states, wake policy, and EC/GPIO events.

Real world example: Unknown Device after BIOS change

Start from properties:

Hardware Ids
Compatible Ids
Location Path
Resources
Problem Code

Then map back:

ACPI\VEN_DEV

_HID / _CID

DSDT / SSDT device node

_CRS resource template

_DSM vendor behavior

Driver INF match

Debug checklist

When Device Manager shows a firmware-related symptom

Collect evidence before changing BIOS code.

Found this useful?

Save it or share it with someone learning firmware, BIOS/UEFI, and embedded systems.

Nội dung liên quan

Một số bài viết, ghi chú hoặc project có liên quan đến nội dung bạn vừa đọc.

Biến note thành bài viết hoàn chỉnh

Notes là nơi ghi nhanh khái niệm.