Hardware failures, missing drivers, and misbehaving Plug and Play (PnP) peripherals can cause system instability, device disconnections, and performance degradation in Windows 11. While the legacy Device Manager utility (devmgmt.msc) provides a familiar graphic interface, managing hardware fleets or diagnosing intermittent connection faults across hundreds of internal and external devices is significantly faster via the command line. The PowerShell Get-PnpDevice cmdlet retrieves granular PnP registry and hardware state information across every system bus.
Understanding PnP Device Classes and Operational Statuses
Windows 11 tracks all internal components, chipset bridges, USB hubs, audio codecs, and network controllers through the Plug and Play subsystem. The Get-PnpDevice cmdlet returns structured objects containing several key diagnostic properties:
- Status: The operational health state of the hardware. Common values include
OK,Error,Degraded, andUnknown. - Class: The functional category assigned by the driver INF file (such as
Net,Display,AudioEndpoint,DiskDrive, orBluetooth). - FriendlyName: The descriptive human-readable label displayed in Device Manager.
- InstanceId: The unique device instance path (e.g.,
PCI\VEN_8086&DEV_15F0...) identifying the exact physical bus location. - Problem: A numerical error code corresponding to standard Device Manager error codes (such as Code 10 for device start failures or Code 43 for hardware faults).
Querying Local Devices with Get-PnpDevice
To audit hardware states in PowerShell:
- Right-click the Start button on Windows 11 and select Terminal (Admin) or PowerShell (Admin).
- Confirm the UAC elevation prompt.
- Execute the baseline cmdlet:
Get-PnpDevice - PowerShell outputs a comprehensive list of all active and historically connected PnP entities on your system.
Filtering for Hardware Errors and Degraded Devices
To instantly isolate failing hardware without scrolling through hundreds of operational devices:
- Filter specifically for non-standard operational statuses:
Get-PnpDevice -Status Error, Degraded, Unknown | Select-Object FriendlyName, Class, Status, Problem, InstanceId | Format-Table -AutoSize - Review the Problem column for specific error codes:
- CM_PROB_FAILED_START (Code 10): The device failed to initialize. Often indicates an incompatible driver version.
- CM_PROB_OUT_OF_CAPACITY (Code 14): A system reboot is required before the device can function.
- CM_PROB_FAILED_POST_START (Code 43): The device reported an unrecoverable hardware problem to the kernel driver.
Inspecting Specific Device Classes (Network, USB, and Audio)
You can target specific hardware categories to evaluate connected peripherals:
To inspect all network interfaces:
Get-PnpDevice -Class Net -PresentOnly | Select-Object FriendlyName, Status, InstanceId
To list all currently connected USB controllers and hubs:
Get-PnpDevice -Class USB -PresentOnly | Select-Object FriendlyName, Status, InstanceId
Adding the -PresentOnly parameter ensures that disconnected or historic USB devices do not clutter your audit results.
Power Cycling and Resetting Misbehaving PnP Devices
If an audio interface, Wi-Fi controller, or external capture card freezes, you can power cycle the PnP entity directly via PowerShell without rebooting the PC:
- Capture the target device’s
InstanceIdusingGet-PnpDevice. - Disable the device cleanly:
Disable-PnpDevice -InstanceId "PCI\VEN_8086&DEV_15F0&SUBSYS_00000000&REV_00\3&11583659&0&A0" -Confirm:$false - Wait 5 seconds for the kernel to release resource allocations.
- Re-enable the device to force a fresh PnP negotiation:
Enable-PnpDevice -InstanceId "PCI\VEN_8086&DEV_15F0&SUBSYS_00000000&REV_00\3&11583659&0&A0" -Confirm:$false - Recheck the device state with
Get-PnpDevice -InstanceId "..."to confirm that the status has returned toOK.