How to Check Connected Devices with CMD Commands

Practical overview of checking connected devices from the command line

Using cmd to check connected devices on Windows is a fast, reliable way to list USB peripherals, network endpoints, Bluetooth devices, and system hardware without installing third-party tools. From a single terminal, built-in commands such as devcon, pnputil, wmic, and Get-PnpDevice in PowerShell return concise status, hardware ID, and driver details you can use to troubleshoot connectivity and security. This guide explains which commands work across Windows 10 and 11, how to interpret results, and how to combine them for everyday diagnostics.

Core commands for listing hardware and devices

devcon for detailed device enumeration

devcon is a command-line utility delivered by the Windows Driver Kit (WDK) that enumerates devices exactly as the Plug and Play manager sees them. It can list devices, enable or disable them, and show driver information. Common verbs include list and status. Running devcon status =usb, for example, shows all USB devices currently recognized. Note that devcon is not in the default Windows PATH; you must run it from an elevated command prompt after opening the correct driver environment or copying the binary into an accessible folder.

pnputil for driver packages and device status

pnputil primarily manages driver packages, but pnputil /enum-devices provides a clean, built-in listing of devices reported by the system, including devices with and without compatible drivers. While verbose, its output shows device instance IDs and status codes that are useful for scripting and audits. On most systems, pnputil /enum-devices /class USB limits the view to USB hardware, making it easier to correlate installed drivers with physical devices. This is a low-overhead alternative when WMI or PowerShell remoting is restricted.

PowerShell alternatives for modern workflows

Get-PnpDevice for Plug and Play inventory

PowerShell exposes the same Plug and Play database through Get-PnpDevice, giving object-oriented output that is easier to filter than raw command lines. You can quickly retrieve devices by status, such as Get-PnpDevice | Where-Object {$_.Status -eq 'Error'}, to identify hardware with driver or resource conflicts. Cmdlets like Get-PnpDeviceProperty and Get-PnpDevice -PresentOnly help distinguish currently connected hardware from legacy entries that no longer have a physical counterpart.

WMI and CIM for networked and system devices

Windows Management Instrumentation (WMI) and its successor, CIM, let you query hardware and network endpoints from the command line. wmic remains available on Windows 10 and 11 for backward compatibility, while Get-CimInstance in PowerShell is the recommended approach for new scripts. Typical queries include listing network adapters with wmic nic get Name,DeviceID,Status or enumerating disks via Get-CimInstance Win32_DiskDrive. These methods are especially valuable for remote checks and for correlating device IDs with driver dates and versions.

Interpreting results and common pitfalls

Not every entry reported by these commands corresponds to a currently plugged peripheral; some are legacy or virtual devices. Focus on entries with a status of OK or Running, and cross-reference hardware IDs with Device Manager when in doubt. If a device appears in Device Manager but returns an error in command output, update or roll back the driver. If it is missing entirely, reseat the hardware, check Physical Device Presence settings, and test different ports or controllers. Elevated prompts are required for some actions, and on modern systems, driver store operations may need explicit administrator approval.

Quick reference for everyday diagnostics

• List USB devices: devcon status =usb (elevated prompt)
• Enum all devices: pnputil /enum-devices
• Show devices with errors: Get-PnpDevice | Where-Object {$_.Status -eq 'Error'}
• Query network adapters: wmic nic get Name,DeviceID,Status
• Check disks: Get-CimInstance Win32_DiskDrive

Command and output highlights at a glance

When to use these methods and when to prefer GUI

Command-line checks are ideal for scripted inventories, remote troubleshooting across management tools, and environments where third-party utilities are restricted. They produce concise, parseable output that integrates well with logs and automation. For casual users, Device Manager and Settings remain faster for single-device investigations. Use cmd when you need repeatable, documented steps or need to query many machines simultaneously, and rely on PowerShell when object-oriented filtering will save time later.

Verifying integrity and avoiding misconfigurations

After making driver or firmware changes, rerun the same commands and compare results to a known baseline. Log output to a file for future reference by appending > devices.txt or using Start-Transcript in PowerShell. Watch for unexpected device duplicates or missing hardware IDs, which can indicate driver conflicts or failing connections. When possible, verify firmware and Windows Update history alongside command output to distinguish hardware faults from configuration issues.

Extending checks to network and Bluetooth endpoints

Beyond local USB peripherals, you can use cmd and PowerShell to probe network endpoints and Bluetooth devices. Get-NetAdapter and Get-WmiObject Win32_NetworkAdapter list active and disabled network interfaces, while Get-PnpDevice | Where-Object {$_.Class -eq 'Bluetooth'} surfaces paired radios. For remote checks, invoke these commands via PowerShell remoting or deployment tools, but remember that permissions and firewall rules may limit what is visible. Combine these with TCP tests and driver queries to build a complete picture of device health across the environment.

Bottom line on using cmd to audit connected hardware

Mastering a few core cmd and PowerShell commands gives you a lightweight, always-available toolkit for auditing connected devices, diagnosing errors, and documenting hardware inventories. Because these tools are built into Windows, they work consistently across editions and versions, making them dependable for both ad hoc checks and automated workflows. Used carefully, with attention to status codes and driver details, they reduce downtime and provide clear evidence when escalation or vendor support becomes necessary.