Core Concept: Hardware IDs for Individual Devices

A Hardware ID is a vendor-defined identification string that Windows uses to match a physical or virtual device to a compatible driver package. It serves as a digital fingerprint for the device, indicating that any driver declaring support for that ID can provide at least basic functionality.

Most devices report multiple Hardware IDs, ordered from most specific to least specific. Windows selects the best match during driver installation. The maximum number of Hardware IDs in a list is 64.

Common formats include:

• <enumerator>\<enumerator-specific-device-ID> — the most frequent form for PnP devices (e.g., reported by a bus driver).
• \*<generic-device-ID> — for devices supported by multiple enumerators.
• Device-class-specific or other specialized forms.

Examples:

• Generic PnP: root\*PNP0F08
• PCI device: PCI\VEN_1000&DEV_0001&SUBSYS_00000000&REV_02
• USB device: USB\VID_v(4)&PID_d(4)&REV_r(4) (where VID is the vendor ID, PID the product ID, and REV the revision)

These strings typically encode bus type, manufacturer/vendor code, device model, subsystem, and revision information. Compatible IDs (a related but less specific list) provide fallback matching options.

Primary uses:

• Driver matching and installation via Windows Update or INF files.
• Troubleshooting unknown or problematic devices.
• Identifying hardware for support, inventory, or custom driver development.

Hardware IDs are reported by the device’s enumerator (usually a bus driver) to the Plug and Play manager.

A. Computer Hardware IDs (CHIDs)

Distinct from per-device Hardware IDs, Computer Hardware IDs (CHIDs) uniquely identify an entire computer system or model. Windows generates CHIDs at boot by hashing combinations of System Management BIOS (SMBIOS) field values with the SHA-1 algorithm, producing GUIDs.

CHIDs exist in a ranked hierarchy (HardwareID-0 through HardwareID-14 or similar, depending on Windows version). Lower numbers are more specific (incorporating more fields such as manufacturer, family, product name, SKU, BIOS details, and baseboard information); higher numbers are more general (often just manufacturer).

Key points:

• A CHID is generated only if all required SMBIOS fields for that combination are populated.
• They support device metadata packages, allowing OEMs and IHVs to deliver precise metadata, drivers, or experiences tailored to specific PC models.
• The ComputerHardwareIds.exe tool (included in the Windows Driver Kit) can report a system’s current CHIDs or simulate them from provided SMBIOS values.

CHIDs are particularly relevant for OEMs, system builders, and developers working with Windows hardware metadata or Windows Update targeting.

B. Device Hardware IDs (PnP Hardware IDs)

These are the classic, official Hardware IDs that Windows uses to match individual devices (graphics cards, network adapters, USB devices, etc.) to driver packages.

• Nature: Vendor-defined identification strings reported by a device’s bus driver (enumerator) to the Plug and Play manager.
• Format examples:
  • PCI: PCI\VEN_10DE&DEV_1B06&SUBSYS_85EA1043&REV_A1
  • USB: USB\VID_v(4)&PID_d(4)&REV_r(4)
  • Generic: root\*PNP0F08
• Characteristics: Most devices report a ranked list (most specific to least specific). Windows selects the best match during driver installation. A device can have up to 64 Hardware IDs.
• Primary uses: Driver matching and installation, troubleshooting unknown devices via Device Manager, and locating the correct drivers from manufacturers or Windows Update.
• How to view: Device Manager → device Properties → Details tab → Hardware Ids property. PowerShell (Get-PnpDevice) or tools such as DevCon also retrieve them.

These are the most precise “Hardware IDs” when working with individual components.

C. Composite Hardware Fingerprints (Common “HWID” in Licensing and Anti-Abuse)

In software licensing, anti-cheat systems, activation, and digital rights management, “HWID” or “hardware ID” often refers to a composite fingerprint assembled from multiple hardware and system values rather than a single official Windows string. Common components include:

• SMBIOS UUID / system UUID
• Motherboard and BIOS serial numbers
• CPU identifiers (ProcessorId or CPUID-derived values)
• Disk drive serial numbers
• Network adapter MAC addresses
• TPM-related keys (where present)
• GPU identifiers
• Volume serial numbers
• Various registry-based values (Machine GUID, etc.)

This composite is calculated on demand and used to bind licenses or detect hardware changes. It is not a single stored value and differs from pure device Hardware IDs.

Related but distinct identifiers frequently confused with Hardware IDs:

• Device ID / Product ID shown in Settings > System > About — support and licensing-related system identifiers, not driver Hardware IDs.
• Machine GUID and similar registry values.
• GDID (Global Device ID) — a persistent, server-generated identifier tied to a Windows installation (physical or virtual), stored locally in the registry and used across certain Microsoft services. It survives updates but changes on reinstallation. Recent reporting has highlighted its role in device-level identification.
• Windows activation HWID structures used in older or specialized activation processes (distinct binary formats involving hashed hardware components).

These serve licensing, telemetry, support, and identity purposes and should not be conflated with PnP Hardware IDs or CHIDs.

How to Retrieve Hardware IDs on Windows

Method 1: Device Manager (Recommended for Individual Devices)

1. Open Device Manager (search for it or run devmgmt.msc).
2. Expand the relevant category (e.g., Display adapters, Network adapters, USB controllers).
3. Right-click the target device and select Properties.
4. Go to the Details tab.
5. In the Property drop-down, select Hardware Ids (or Compatible Ids).
6. The Value box lists the IDs; the top entry is typically the most specific. Right-click to copy.

This works on Windows 10 and 11 and requires no extra tools.

Method 2: PowerShell

• List devices and their Hardware IDs: Get-PnpDevice -PresentOnly | Select-Object Name, HardwareID | Format-Table -AutoSize
• Export to a file: append > “$env:USERPROFILE\Desktop\HardwareID.txt”.
• For a specific device’s properties, use Get-PnpDeviceProperty with the appropriate InstanceId and key DEVPKEY_Device_HardwareIds.
• System UUID (often treated as a primary system HWID): Get-CimInstance -ClassName Win32_ComputerSystemProduct | Select-Object UUID
• Other useful queries: baseboard serial, processor ID, disk serials via corresponding Win32_ or CimInstance classes.

Method 3: Command Prompt / WMIC (Legacy Notes)

Commands such as wmic csproduct get UUID, wmic bios get serialnumber, or wmic baseboard get SerialNumber remain useful on many systems, though WMIC is deprecated in newer Windows 11 builds. Prefer PowerShell equivalents.

Method 4: Advanced Tools

• DevCon (from the Windows Driver Kit): devcon hwids * lists Hardware IDs.
• ComputerHardwareIds.exe (also from the WDK): generates and displays CHIDs based on current or simulated SMBIOS data.
• Programmatic access via APIs such as SetupDiGetDeviceProperty or CM_Get_DevNode_Property for the DEVPKEY_Device_HardwareIds property.

For system-level identifiers like the UUID or serials used in broader fingerprints, the PowerShell CimInstance or WMI approaches above are reliable.

Practical Applications and Considerations

• Driver troubleshooting and development — Copy a Hardware ID into search engines, manufacturer sites, or Windows Update catalogs to locate the correct driver.
• OEM and metadata packaging — CHIDs enable precise targeting of device experiences.
• Software licensing and security — Composite HWIDs help bind licenses to hardware and detect significant changes (e.g., motherboard replacement may trigger reactivation).
• Inventory and management — Enterprise tools and Autopilot use related hardware hashes for device enrollment and tracking.
• Limitations and changes — Hardware IDs are relatively stable for a given device but can vary with firmware or bus presentation. Composite fingerprints change when key components are replaced. Registry-based values are more mutable. Reinstalling Windows can alter certain installation-tied identifiers such as GDID.

Privacy and security notes: Device Hardware IDs themselves do not contain personally identifiable information; they identify hardware. Broader system identifiers and telemetry identifiers raise different considerations around tracking and data retention, which organizations and individuals should evaluate according to their threat models and applicable policies.

Summary of Key Distinctions

1) Computer Hardware IDs (CHIDs)

Computer Hardware IDs (CHIDs) are specialized hardware identifiers that uniquely identify an entire computer system (or a class of similar systems) rather than an individual peripheral device. They form a ranked set of GUIDs derived from System Management BIOS (SMBIOS) data and play a key role in matching device metadata packages, targeting drivers via Windows Update, and enabling OEM-specific experiences.

Unlike standard per-device Hardware IDs (used by Plug and Play for driver matching on components such as GPUs or network adapters), CHIDs are generated by Windows itself at every system boot. Each CHID is produced by hashing a specific combination of SMBIOS field values with the SHA-1 algorithm, resulting in a GUID.

A critical rule applies: a given CHID is generated only if every SMBIOS field required for that combination is populated (non-null) in the system’s SMBIOS tables. Missing or empty fields simply omit the related CHIDs.

SMBIOS Fields Used in CHID Generation

CHIDs draw from a defined set of fields in the SMBIOS structures (primarily Type 0 BIOS Information, Type 1 System Information, Type 2 Baseboard, and Type 3 System Enclosure). Key fields include:

• Manufacturer (System Information Type 1) — Computer manufacturer/brand name.
• Family (System Information Type 1) — Product family or line (grouping of similar models).
• Product Name (System Information Type 1) — Specific product/model name.
• SKU Number (System Information Type 1) — Stock-keeping unit or configuration identifier.
• BIOS Vendor / Vendor (BIOS Information Type 0) — BIOS vendor name.
• BIOS Version (BIOS Information Type 0) — BIOS version string.
• System BIOS Major Release and Minor Release (BIOS Information Type 0).
• Enclosure Type (System Enclosure Type 3) — Chassis type (e.g., portable, desktop).
• Baseboard Manufacturer and Baseboard Product (Baseboard Type 2, motherboard-specific) — Added for greater precision in Windows 10 and later.

These fields must be set carefully by OEMs and system builders. Values are case-sensitive, and Unicode characters are treated distinctly (for example, different forms of the letter “I” are not equivalent). Consistent population of these fields across a product line ensures reliable CHID generation and targeting.

CHID Hierarchy by Windows Version

CHIDs are ordered from most specific (lower numbers) to most general (higher numbers). Windows maintains different hierarchies depending on the OS version.

Windows 7

Windows 8 / 8.1

Windows 10 and later (expanded hierarchy incorporating baseboard details)

Lower-numbered CHIDs provide the most precise matching (ideal for model-specific metadata or drivers). Higher numbers enable broader coverage (e.g., all systems from one manufacturer).

Generating and Viewing CHIDs

Microsoft provides the ComputerHardwareIds.exe tool as part of the Windows Driver Kit (WDK). It is available in both x86 and x64 versions under the WDK bin directory and runs on Windows 7 and later.

Default behavior — Run the tool with no parameters. It reads the live SMBIOS data, displays the relevant fields (BIOS vendor/version, system manufacturer/family/product name, enclosure type, etc.), and lists the generated CHIDs with annotations showing which field combinations produced each GUID.

Simulation behavior — Supply custom SMBIOS values to preview the CHIDs that would be generated on a system with those values. This is useful for OEMs planning metadata packages or driver targeting before hardware is finalized.

Example output structure (illustrative):

Using the BIOS to gather information
## Computer Information
BIOS Vendor: Contoso Inc.
BIOS Version string: A16
...
System Manufacturer: Contoso Inc.
System Family: (null)
System ProductName: Contoso SYS01
Enclosure Type: Portable
Hardware IDs
------------
{346511cf-ccee-5c6d-8ee9-3c70fc7aae83}    <- Manufacturer + Family + ProductName + BIOS Vendor + BIOS Version + Major Version + Minor Version
{d7be59e5-29b5-589a-b49d-de7265ef6a7b}    <- Manufacturer + Family + ProductName

Only CHIDs whose required fields are present appear in the output.

Practical Uses and Windows Update Behavior

Device metadata packages — CHIDs allow OEMs to associate rich metadata (icons, descriptions, experiences) with specific computer models or families. In the package XML, a computer CHID is specified with the prefix ComputerMetadata\ and delimited by curly braces, for example: DOID:ComputerMetadata\{c20d5449-511e-4cb5-902a-a541239322aa}.

Recommendations exist for preferred CHID levels depending on the Windows version and desired specificity (e.g., avoid certain reserved low-numbered IDs on older releases). Note that classic device metadata is deprecated in favor of Driver Package Container Metadata in newer Windows versions.

Driver targeting via Windows Update — CHIDs help narrow the set of systems to which a driver package applies before Plug and Play ranking occurs. Behavior changed across Windows 10 releases:

• Versions 1507–1703: CHIDs are ranked (CHID-0 outranks higher numbers).
• Version 1709 and later: Ranking by CHID level is removed. All applicable CHID-targeted drivers (0–14) are grouped, after which standard PnP ranking selects the best match.

OEMs must supply accurate CHID information to driver publishers so that packages reach the intended systems.

Additional considerations:

• Consistent SMBIOS population across production runs is essential for stable targeting.
• Missing fields reduce the available CHID set and can limit matching precision.
• CHIDs support scenarios beyond drivers, including inventory, support, and model-specific software experiences.
• Because generation depends on firmware data, changes to BIOS settings or firmware updates that alter the relevant strings can affect the resulting CHIDs.

Summary

Computer Hardware IDs provide a structured, hierarchical way for Windows to identify PC models using hashed SMBIOS data. They enable precise targeting of metadata and drivers while offering fallback broader matches. Proper population of SMBIOS fields by OEMs, combined with the ComputerHardwareIds tool for verification and simulation, is the foundation for reliable use. For the most current details, refer to the official Microsoft documentation on Computer Hardware IDs and related driver-development topics, as the hierarchy and tooling continue to evolve with Windows releases.

1.1) Generating and Viewing Computer Hardware IDs (CHIDs)

Computer Hardware IDs (CHIDs) are generated automatically by Windows at every boot from System Management BIOS (SMBIOS) data. To view the CHIDs currently produced by a system—or to generate them from simulated SMBIOS values for planning and testing—Microsoft provides the dedicated command-line tool ComputerHardwareIds.exe. This tool is part of the Windows Driver Kit (WDK) and is the standard method used by OEMs, system builders, and developers.

Prerequisites

• Windows 7 or later (including Windows 10 and Windows 11).
• The Windows Driver Kit (WDK) installed. Separate x86 and x64 builds of the tool are included.
• Typical location after WDK installation (version numbers vary): C:\Program Files (x86)\Windows Kits\10\bin\<version>\x64\ComputerHardwareIds.exe (or the corresponding x86 folder).

Download the latest WDK from the official Microsoft site if it is not already installed.

Default Mode: Viewing CHIDs from the Live System

Run the tool with no parameters. It reads the system’s current SMBIOS tables, displays the relevant fields, and lists every CHID that can be generated from the available data.

Steps:

1. Open an elevated Command Prompt or PowerShell.
2. Navigate to the tool’s directory (or add it to your PATH).
3. Execute:
   • ComputerHardwareIds
   • or the full path, for example:
   • "C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x64\ComputerHardwareIds.exe"

Example output structure:

Using the BIOS to gather information
## Computer Information
BIOS Vendor: Contoso Inc.
BIOS Version string: A16
System BIOS Major Version: 6
System BIOS Minor Version: 0
System Manufacturer: Contoso Inc.
System Family: (null)
System ProductName: Contoso SYS01
Enclosure Type: Portable
Hardware IDs
------------
{346511cf-ccee-5c6d-8ee9-3c70fc7aae83}    <- Manufacturer + Family + ProductName + BIOS Vendor + BIOS Version + Major Version + Minor Version
{d7be59e5-29b5-589a-b49d-de7265ef6a7b}    <- Manufacturer + Family + ProductName

Only CHIDs whose required SMBIOS fields are fully populated appear. Missing or null fields (for example, an empty SKU Number) cause the related higher-specificity CHIDs to be omitted.

Simulation Mode: Generating CHIDs from Custom SMBIOS Values

The tool also supports generating CHIDs from user-supplied strings. This is useful for:

• Planning metadata or driver packages before hardware is finalized.
• Testing different manufacturer/family/SKU combinations.
• Verifying consistency across product lines.

When any simulation parameters are supplied, the tool ignores the live BIOS data and uses only the provided values.

Common command-line options (based on tool documentation):

Example simulation command:

ComputerHardwareIds.exe /ven "Contoso Ltd." /ver "0.158" /major "12" /minor "9" /mfg "Contoso" /family "Q Workstation" /product "3C273" /sku "SKU-ABC" /enclosure "6" /bb_mfg "Contoso Boards" /bb_product "MB-XYZ"

The tool outputs the set of CHIDs that would be produced on a system with those exact SMBIOS values. Only combinations for which all required fields are supplied will be generated.

Important Generation Rules and Tips

• Case sensitivity: SMBIOS string values are case-sensitive. “Contoso” and “contoso” produce different hashes. Maintain consistent casing across all systems in a product line.
• Unicode handling: Special characters (including different forms of the letter “I” in some languages) are treated as distinct. Avoid mixing variants.
• Completeness requirement: A CHID is produced only when every field needed for that specific combination is present and non-null. Incomplete data simply results in fewer CHIDs.
• Hierarchy awareness: Lower-numbered CHIDs (more fields) are more specific; higher-numbered ones are broader. The Windows 10+ hierarchy includes baseboard fields for additional precision.
• No parameters listed in official “Parameters: None” notes: Some documentation pages emphasize the default (no-argument) mode. The simulation switches are supported in practice and documented in tool help and community references; always check ComputerHardwareIds /? on your installed version for the authoritative list.

Alternative Ways to Inspect Related Data

While ComputerHardwareIds is the dedicated tool for CHIDs, related system information can be viewed with built-in utilities:

• PowerShell:
  • Get-CimInstance -ClassName Win32_ComputerSystemProduct
  • Get-CimInstance -ClassName Win32_BIOS
  • Get-CimInstance -ClassName Win32_BaseBoard
  • Get-CimInstance -ClassName Win32_SystemEnclosure
• These show the raw SMBIOS strings that feed CHID generation but do not compute the hashed GUIDs themselves.

Practical Workflow Recommendations

1. Populate SMBIOS fields consistently during firmware development (Manufacturer, Family, Product Name, SKU, BIOS details, baseboard information).
2. Run ComputerHardwareIds in default mode on representative hardware to capture the live CHID set.
3. Use simulation mode to validate planned values before production.
4. Supply the appropriate CHIDs (typically mid-to-high specificity for model-level targeting) when publishing drivers or metadata packages.
5. Re-verify after any BIOS update that alters the relevant strings, because the resulting CHIDs will change.

Summary

ComputerHardwareIds.exe is the official, reliable method both to view the CHIDs that Windows generates from a live system and to simulate CHIDs from arbitrary SMBIOS values. Default execution requires no arguments and reports everything available from the current BIOS. Simulation mode, activated by supplying the relevant /parameter “value” switches, enables offline planning and testing. Correct use of the tool, combined with disciplined SMBIOS population, ensures accurate targeting of drivers, firmware, and metadata across Windows systems.

1.2) Practical Uses of Computer Hardware IDs (CHIDs)

Computer Hardware IDs (CHIDs) serve as a hierarchical, system-level identification mechanism that allows Windows and related Microsoft services to match content, drivers, and experiences to specific PC models or families with controlled precision. Derived from hashed combinations of SMBIOS fields, they enable OEMs, independent hardware vendors (IHVs), and enterprises to target resources more accurately than broad hardware IDs alone. Below are the primary practical applications, drawn from Microsoft’s driver and update infrastructure.

1. Driver Targeting and Delivery via Windows Update

The most prominent operational use of CHIDs is narrowing the applicability of driver packages before Plug and Play (PnP) ranking occurs. Windows Update uses CHIDs to reduce the pool of systems that can receive a given driver.

• Precision filtering: A driver can be published against a specific CHID (or set of CHIDs). Systems whose generated CHIDs match receive the package; others do not. This prevents overly broad distribution that could install unsuitable drivers on unrelated hardware.
• Hierarchical matching: Lower-numbered (more specific) CHIDs allow tight targeting (e.g., one exact model and SKU). Higher-numbered CHIDs enable broader coverage (e.g., an entire manufacturer or family).
• Version-dependent behavior:
  • Windows 10 versions 1507–1703: CHIDs themselves are ranked (CHID-0 outranks higher numbers).
  • Windows 10 1709 and later: Ranking by CHID level is removed. All matching CHID-targeted drivers are grouped, after which standard PnP ranking selects the best candidate.
• Real-world impact example: An OEM can publish one driver package targeted at a precise CHID (Manufacturer + Family + Product Name + SKU) for a specific laptop configuration and a second, broader package for the wider product family. Systems receive the most appropriate match without unnecessary or conflicting updates.
• Recent refinements for display drivers: Microsoft has moved toward combining 2-part hardware IDs with CHIDs for new display (graphics) driver submissions. This narrower targeting helps reduce unintended driver downgrades—where Windows Update previously replaced a user- or OEM-installed newer driver with an older “higher-ranked” package based on broader 4-part IDs. The change is rolling out for new devices (pilot mid-2026, broader enforcement late 2026–early 2027).

OEMs must supply accurate CHID information to driver publishers so packages reach the intended systems.

2. Device Metadata Packages and PC Experiences

CHIDs identify the computer itself as a device container in the Devices and Printers interface and related UI surfaces. They allow OEMs to associate rich, model-specific metadata—product names, descriptions, high-resolution icons, functional categories, and branding—with particular systems.

• In metadata package XML, a computer CHID is specified with the ComputerMetadata\ prefix and curly-brace delimiters (example form: DOID:ComputerMetadata\{GUID}).
• Recommended CHID selection varies by Windows version and desired specificity (most precise model-level CHIDs for exact matches; family- or manufacturer-level for broader coverage). Certain low-numbered CHIDs were historically reserved.
• Classic device metadata is deprecated; the modern replacement is Driver Package Container Metadata (supported starting in Windows 11 24H2 with specific updates). Container metadata still relies on precise targeting mechanisms, including support for the OEM computer device node, to customize how physical systems appear to users.

This use case improves the out-of-box and ongoing user experience by ensuring systems display accurate manufacturer and model information rather than generic placeholders.

3. Firmware Update Package Targeting

Microsoft requires Computer Hardware ID (CHID) targeting for firmware update packages, in addition to the unique system identifier listed in the EFI System Resource Table (ESRT). This ensures firmware updates reach only the intended hardware configurations, reducing the risk of applying incompatible firmware.

4. Enterprise Management and Driver Matching (Intune and Related Tools)

In Microsoft Intune and related management platforms, CHID-based matching supports more sophisticated server-side driver and firmware availability decisions. Hardware profile information collected from managed devices is used to match applicable drivers and updates with greater accuracy than older Configuration Manager approaches.

• CHIDs help determine which updates are relevant to specific models or SKUs within a fleet.
• Administrators can better control deployment of OEM-optimized drivers versus generic component-vendor drivers.
• Note that Intune driver update policies do not always strictly enforce OEM CHID targeting; a newer recommended driver may still surface in some cases, requiring additional configuration (e.g., Driver Update policies or rings) for full control.

This capability is valuable for large organizations managing mixed hardware fleets where model-specific optimizations or stability requirements matter.

5. OEM and IHV Workflow Support

• Pre-production planning and verification: The ComputerHardwareIds.exe tool (part of the Windows Driver Kit) lets OEMs generate and inspect CHIDs from live or simulated SMBIOS data. This supports consistent population of SMBIOS fields across production runs and verification that the intended hierarchy of CHIDs will be available.
• Submission and publishing: Accurate CHIDs are supplied during driver or metadata package submission to the Windows Hardware Dev Center so that distribution targeting functions correctly.
• Product-line strategy: OEMs can design a deliberate hierarchy—tight CHIDs for flagship or specialized SKUs and broader CHIDs for volume or family-wide coverage—aligning software and firmware delivery with marketing and support strategies.

Limitations and Practical Considerations

• CHIDs are generated only when the required SMBIOS fields are fully populated. Incomplete firmware data reduces the available set of CHIDs and limits targeting precision.
• Values are case-sensitive; inconsistent casing or special Unicode characters across systems can produce unexpected GUIDs.
• Classic device metadata is being phased out in favor of container metadata, so long-term planning should account for the newer model.
• CHIDs are not a general-purpose device fingerprint for licensing or anti-abuse outside Microsoft’s driver/metadata ecosystem; other identifiers (system UUID, composite hardware hashes, etc.) serve those roles.

Summary of Value

CHIDs give OEMs, IHVs, and IT administrators a structured way to deliver the right drivers, firmware, and user-facing information to the right systems at the right level of specificity. Their hierarchical design balances precision (model- and SKU-level targeting) with scalability (family- or manufacturer-level fallbacks). When SMBIOS data is carefully managed and CHIDs are correctly applied in publishing workflows, they significantly improve update reliability, reduce unintended driver changes, and enhance the overall Windows hardware experience.

2) Device Hardware IDs (PnP Hardware IDs)

Device Hardware IDs, also called Plug and Play (PnP) Hardware IDs, are vendor-defined identification strings that Windows uses to match a physical or virtual device to a compatible driver package. They form the core mechanism by which the operating system identifies individual hardware components—graphics adapters, network controllers, USB devices, storage controllers, and more—and selects the appropriate software to operate them.

A Hardware ID indicates that any driver package declaring support for that ID can provide at least some degree of functionality for the device. Most devices report multiple Hardware IDs, ordered from most specific to least specific. Windows evaluates the list during driver installation and chooses the best available match.

How Hardware IDs Are Created and Reported

Hardware IDs are supplied to the Plug and Play manager by a device’s enumerator—typically its bus driver (PCI, USB, ACPI, etc.). When a bus driver reports a new device, it constructs one or more identification strings using established formats.

Common generic formats:

• <enumerator>\<enumerator-specific-device-ID> — the most frequent form for devices reported by a single enumerator.
• \*<generic-device-ID> — the leading asterisk indicates that more than one enumerator can support the device (for example, ISAPNP and BIOS).
• Device-class-specific or bus-specific custom formats defined by the relevant hardware specification.

The total length of a Hardware ID (excluding the null terminator) must be less than MAX_DEVICE_ID_LEN. A single device can report a maximum of 64 Hardware IDs. The full list is stored as a multi-string (REG_MULTI_SZ) value.

Root-enumerated devices require special care. Using overly generic namespaces such as ROOT\SYSTEM or ROOT\USB can cause conflicts. Best practice is to use a unique company-specific namespace, for example ROOT\[COMPANYNAME]\[DEVICENAME], and to verify that the device node does not already exist before installation.

Typical Formats by Bus Type

PCI devices (reported in order of increasing generality):

PCI\VEN_v(4)&DEV_d(4)&SUBSYS_s(4)n(4)&REV_r(2)
PCI\VEN_v(4)&DEV_d(4)&SUBSYS_s(4)n(4)
PCI\VEN_v(4)&DEV_d(4)&REV_r(2)
PCI\VEN_v(4)&DEV_d(4)
PCI\VEN_v(4)&DEV_d(4)&CC_c(2)s(2)p(2)
PCI\VEN_v(4)&DEV_d(4)&CC_c(2)s(2)

• v(4) = PCI-SIG vendor ID
• d(4) = vendor-defined device ID
• s(4)n(4) = subsystem ID and subsystem vendor ID
• r(2) = revision

Example: PCI\VEN_1000&DEV_0001&SUBSYS_00000000&REV_02

USB devices (single-interface example):

USB\VID_v(4)&PID_d(4)&REV_r(4)
USB\VID_v(4)&PID_d(4)

Composite or multi-interface devices add an interface number (&MI_zz).

Generic / root examples: root\*PNP0F08

Other buses (ACPI, SD, etc.) follow analogous patterns that encode vendor, device, subsystem, and revision information according to their specifications.

Hardware IDs vs. Compatible IDs

• Hardware IDs — more specific; a match implies the driver is expected to provide full or near-full functionality.
• Compatible IDs — more general fallback identifiers. Windows uses them when no Hardware ID match is found. A match on a Compatible ID typically indicates basic or class-level support.

Both lists appear in Device Manager and are used by the driver ranking algorithm.

How to View Device Hardware IDs

Graphical method (Device Manager):

1. Open Device Manager (devmgmt.msc or search for it).
2. Expand the appropriate category and locate the device.
3. Right-click the device → Properties.
4. Select the Details tab.
5. In the Property drop-down, choose Hardware Ids (or Compatible Ids).
6. The Value box displays the ordered list. The top entry is usually the most specific. Right-click to copy.

PowerShell:

PowerShell

# List devices and their Hardware IDs
Get-PnpDevice -PresentOnly | Select-Object Name, HardwareID | Format-Table -AutoSize
# Export to a file
Get-PnpDevice -PresentOnly | Select-Object Name, HardwareID | Format-Table -AutoSize > "$env:USERPROFILE\Desktop\HardwareIDs.txt"
# Retrieve the property for a specific Instance ID
Get-PnpDeviceProperty -InstanceId "PCI\VEN_xxxx&DEV_yyyy..." -KeyName DEVPKEY_Device_HardwareIds

Programmatic access:

Retrieve the DEVPKEY_Device_HardwareIds property using APIs such as SetupDiGetDeviceProperty, CM_Get_DevNode_Property, or IoGetDevicePropertyData. The value is a null-terminated multi-string list.

Command-line alternatives:

pnputil /enum-devices /deviceids or the older DevCon tool (devcon hwids *) from the Windows Driver Kit.

Role in Driver Matching and Installation

When Windows searches for a driver (during device arrival, Windows Update, or manual installation), it compares the device’s Hardware ID and Compatible ID lists against the IDs declared in INF files. Ranking considers:

• Exact Hardware ID matches (preferred)
• Compatible ID matches
• Driver ranking scores (signature, date, version, etc.)

The most specific matching Hardware ID generally produces the highest-ranked candidate, assuming other factors are equal. This is why copying the top Hardware ID from Device Manager and searching for it is an effective way to locate the correct driver.

Practical Uses and Considerations

• Driver troubleshooting — Identify unknown or problematic devices and search for matching drivers using the vendor/device codes (e.g., VEN_8086&DEV_… or VID_046D&PID_…).
• Custom INF development — Declare the appropriate Hardware IDs (and optionally Compatible IDs) in the INF Models section so the package matches the intended hardware.
• Inventory and support — Collect Hardware IDs across a fleet for asset tracking or targeted update policies.
• Root-enumerated devices — Always use unique namespaces to avoid conflicts that appear as yellow exclamation marks in Device Manager.

Hardware IDs themselves contain no personally identifiable information; they identify hardware components only. They remain relatively stable for a given device, though firmware updates or changes in bus presentation can alter the reported strings in some cases.

Summary

Device Hardware IDs (PnP Hardware IDs) are the fundamental identifiers that allow Windows to associate individual hardware components with the correct driver packages. Reported by bus drivers in standardized, bus-specific formats and ordered from most to least specific, they drive the entire Plug and Play matching process. Viewing them through Device Manager or PowerShell is straightforward, and understanding their structure is essential for driver development, troubleshooting, and system management.

3. Composite Hardware Fingerprints (HWID Profiles)

A composite hardware fingerprint, commonly referred to as an HWID in software licensing, digital rights management, game anti-cheat systems, and certain activation scenarios, is not a single official Windows identifier. Instead, it is a derived value—or a set of values—assembled by reading multiple hardware and system identifiers and combining them (often through hashing) into a machine-specific profile. When an application or service states that a license is “tied to hardware” or that a system has been “hardware-banned,” it is typically matching against this composite profile rather than any one isolated ID.

Unlike Plug and Play Device Hardware IDs (used for driver matching) or Computer Hardware IDs / CHIDs (used for model-level targeting), a composite fingerprint is application-defined. Different vendors choose different components and different combination methods, so one product’s HWID is not interchangeable with another’s.

Core Components of a Typical Composite Fingerprint

A robust HWID profile usually draws from both firmware-level (highly stable) and software-level (more mutable) sources:

Firmware / Silicon-level identifiers (difficult or impossible to change without hardware replacement):

• SMBIOS UUID (system UUID from the motherboard firmware)
• Motherboard serial number
• BIOS / UEFI serial or version strings
• CPU identifiers (ProcessorId / CPUID-derived values; note that modern CPUIDs are often identical across chips of the same model)
• Disk firmware serial numbers (NVMe or SATA controller serials)
• TPM 2.0 Endorsement Key (EK) public portion — a permanent, manufacturer-injected key that survives OS reinstalls and most clears
• GPU identifiers (device ID, subsystem ID, or driver-reported UUID)

Network and storage identifiers:

• MAC addresses of physical network adapters (Ethernet, Wi-Fi)
• NTFS volume serial numbers (partition-level; changeable with low-level writes)

Windows / software-layer identifiers (easier to modify):

• Machine GUID (HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid)
• HwProfileGuid and related profile values
• Product ID and other licensing-related registry entries
• SQM MachineId, SusClientId, and similar telemetry identifiers
• Computer name / hostname

The rule of thumb is that anything stored in firmware or silicon remains constant across OS reinstalls, while registry values and volume serials can be altered by software.

How Composite Fingerprints Are Constructed

Most implementations follow a similar pattern:

1. Query the selected components (via WMI / CIM, direct SMBIOS reads, IOCTL calls for disk serials, registry access, etc.).
2. Normalize or concatenate the raw strings.
3. Apply a cryptographic hash (commonly SHA-256 or a truncated variant) to produce a compact, fixed-length fingerprint.
4. Optionally store or transmit the fingerprint (or a subset of component hashes) for later comparison.

Some systems keep the individual component hashes and require a configurable number of matches (for example, “at least 5 of 8 identifiers must match”) rather than a single combined hash. This approach tolerates minor hardware changes such as adding a new drive or network adapter while still detecting major swaps (especially motherboard replacement).

Microsoft’s own App Specific Hardware ID (ASHWID) API, available to UWP and related apps, encodes characteristics of up to nine component types (processor, memory, disk, network adapter, audio, docking station, mobile broadband, Bluetooth, and system BIOS) into a structured byte stream. Cloud services are expected to handle variability across sessions.

Primary Practical Uses

• Software licensing (node-locked licenses) — Bind an activation to a specific machine so the same key cannot be freely shared. Common in professional tools (creative suites, CAD, audio production software) and many commercial applications. The fingerprint is recorded at activation time and verified on subsequent launches.
• Game anti-cheat and hardware bans — Kernel-level anti-cheats (examples include systems used by major multiplayer titles) build profiles from SMBIOS data, disk serials, MAC addresses, TPM information, and registry values. A hardware ban persists across account changes and often across Windows reinstalls because the underlying firmware identifiers remain the same.
• Windows digital license / activation binding — Digital entitlements are associated with a hardware hash. Significant changes (particularly motherboard replacement) frequently require reactivation or transfer through a Microsoft account.
• Enterprise and DRM systems — Device-bound licensing, offline activation, and usage tracking in managed environments.
• Security and forensics — Hardware fingerprints can help attribute activity to a physical machine even after OS reinstallation, although this raises privacy considerations.

Stability and Change Behavior

Because the most durable identifiers live in firmware or the TPM, simply reinstalling Windows or deleting registry keys does not produce a “new machine” from the perspective of a well-designed composite system.

Distinction from Official Windows Identifiers

• PnP Device Hardware IDs — Bus-specific strings for individual components (driver matching only).
• Computer Hardware IDs (CHIDs) — Hashed SMBIOS combinations used for model-level driver and metadata targeting.
• Machine GUID / GDID — Installation- or account-tied identifiers; useful pieces of a composite profile but not the full fingerprint.
• Composite HWID — Application- or service-defined combination of the above (and more), computed on demand for licensing or enforcement purposes.

Practical Considerations for Developers and Users

For developers implementing licensing:

• Prefer a weighted or threshold-based matching model over a rigid single hash so legitimate hardware upgrades do not break licenses.
• Document clearly which components are used and how users can request reactivation after major hardware changes.
• Avoid relying solely on easily spoofable values (simple registry GUIDs or volume serials).

For users:

• Motherboard replacement is the change most likely to invalidate a hardware-bound license or trigger a ban.
• Tools that claim to “spoof HWID” typically attempt to intercept or alter the values returned by queries; effectiveness varies widely and depends on whether the target system reads at kernel level or uses direct hardware access.
• Privacy implications exist whenever a persistent hardware profile is transmitted or stored; evaluate the trust model of the software involved.

Summary

A composite hardware fingerprint is a derived machine profile built by combining multiple hardware and system identifiers into a form that can be compared across sessions. It powers node-locked licensing, anti-cheat enforcement, and certain activation schemes precisely because many of its strongest components survive operating-system reinstallation. Understanding which layer each identifier lives in—firmware versus software—explains both its durability and the practical limits of changing it.

Reference

• Computer hardware ID (CHID)
• Using Computer Hardware IDs (CHIDs)
• Device identification strings