To see which devices are currently configured to wake a Windows PC, run powercfg /devicequery wake_armed. To see devices whose wake behaviour users can configure, run powercfg /devicequery wake_programmable. These are different lists: a configurable device is not necessarily enabled to wake the computer, and an enabled device is not proof of what caused yesterday’s unexpected wake.
This workflow collects device-permission evidence without disabling your keyboard, mouse or network adapter. It is useful before proposing a change on a shared or remotely managed computer, where removing a wake route could interrupt legitimate access.
Start with the symptom and a read-only query
Write down the computer involved, the approximate wake time, whether it was on battery or mains power, and whether you selected Sleep manually. Do not assume that a dark screen means the whole computer slept. If the machine never entered sleep, device wake permissions may not explain the problem.
Open Command Prompt as administrator using an authorised account. On a managed PC, follow your organisation’s support procedure instead of obtaining additional privileges yourself. Run this inspection command:
powercfg /devicequery wake_armedMicrosoft describes this query as listing devices currently configured to wake the system from a sleep state. Record the complete output and collection time. Do not copy device names from an online example: your installed hardware and driver names can differ.
If the command fails or requests privileges, preserve the exact error. An unsuccessful query is not evidence that no devices have wake permission. Likewise, a list collected this morning describes current configuration, not necessarily the configuration when an incident happened overnight.
Compare configurable devices with enabled devices
Now run the second read-only query:
powercfg /devicequery wake_programmableThe Microsoft reference defines this list as devices that are user-configurable to wake the system. Compare it with the armed list rather than treating the two as synonyms. For a hypothetical example, a mouse appearing in the programmable list but not the armed list is a candidate for configuration, not evidence that it currently has wake permission.
If a network adapter appears in the armed list, record that observation without concluding that network traffic caused the wake. A configured route is a possible mechanism, not an event record. Similarly, neither list promises that every wake method will work under every hardware, firmware, power-source or sleep-state condition.
Keep repeated or similar device names intact in your notes. Collapsing entries to a friendly description such as ‘USB device’ can remove the detail a technician needs to investigate the correct hardware.
Keep wake permission separate from wake history
Immediately after an unexpected wake, the following query asks a different question:
powercfg /lastwakeMicrosoft documents this as information about what woke the system from its last sleep transition. Compare any reported source with the permission snapshot, but do not turn a blank or unclear report into a confident diagnosis. Another sleep cycle may also change which transition is the last one.
For the distinction between scheduled wake opportunities and historical evidence, see wake timers versus last-wake evidence. A wake timer, a device permission and a request that prevents automatic sleep are separate mechanisms. Investigating one does not rule out all the others.
Prepare a change proposal, not a blanket disable command
Before anyone changes wake permissions, identify which device entry is relevant and how the PC should be woken afterwards. Ask whether remote management, maintenance or accessibility arrangements depend on that route. On a work device, send the evidence to IT for an approved, targeted change.
This tutorial deliberately does not run the documented device-enable or device-disable operations. No power-setting rollback is needed for the queries above. If a later authorised troubleshooting step changes permission, retain the original state, document the exact target, and agree how to restore access if the change does not help.
Quick handoff checklist
- Record the observed event time separately from command collection times.
- Keep the full armed and programmable lists, including similar names.
- Capture last-wake information after the relevant transition.
- Explain which normal wake routes must remain available.
- Review hardware names and other details before posting output publicly.
Does an empty armed list prove the PC cannot wake? No. It does not establish the absence of timers or other wake mechanisms. Does a listed mouse prove it caused the incident? No. Permission is not event attribution.
Source and safe use
Microsoft’s powercfg command-line reference documents both device queries and last-wake reporting. The examples here explain those inspection operations; they are not a claim that your hardware has been tested.
This tutorial is for educational purposes. Test carefully before using steps in production. The site owner is not responsible for misuse, damage, data loss or production issues.
