| Previous | Next |
| ERROR_MAPPED_ALIGNMENT | ERROR_SET_POWER_STATE_FAILED |
ERROR_SET_POWER_STATE_VETOED
An attempt to change the system power state was vetoed by another application or driver.
ERROR_SET_POWER_STATE_VETOED is Win32 error 1140 (0x474). It indicates that a requested system power transition was rejected by another software component. The exact veto mechanism depends on the Windows version, power API, device stack, and whether the result came from a legacy compatibility path.
Where to look for the veto
- a legacy application responding to a suspend or power query
- a driver refusing a device or system power IRP
- a service or management agent coordinating sleep, hibernation, or shutdown
- virtualization, docking, storage, or display components that cannot enter the requested state
- compatibility code translating a newer power-management failure into 1140
Modern Windows diagnostics often expose active power requests, device problems, or transition reports rather than a simple application veto. Therefore, preserve the API and operating-system build that produced 1140 instead of assuming every case uses the same historical broadcast contract.
Evidence to collect
- requested state: sleep, hibernate, shutdown, restart, or device-specific transition
- initiating process, API, flags, user session, and power policy
- System log events from Kernel-Power, Power-Troubleshooter, device drivers, and firmware
powercfg /requests, sleep diagnostics, and available sleep states- device-instance and driver information for components that failed a power request
A timestamped transition ID is useful when several services request power changes. Correlate the initiator, the first component that rejected the transition, and any later retry or cancellation.
Diagnostic sequence
- reproduce with nonessential applications closed to separate user-mode from driver vetoes
- inspect active power requests and system sleep diagnostics
- update or test the suspected device driver and firmware
- compare behavior on AC and battery power and with external devices detached
- capture an energy or power trace when ordinary logs do not identify the component
Do not use broad power-request overrides as the first fix. An override can force a transition while a device, recording application, or update process genuinely requires the system to remain active.
Recovery and product behavior
An interactive application can explain which component blocked the transition and allow the user to close or save work. A managed system should back off, record the veto owner, and retry only after the blocking state changes. Forced power loss is not equivalent to a successful managed transition.
Driver developers should complete power requests promptly, avoid indefinite waits, and log the device state that makes a transition unsafe. Application developers should release power requests and veto conditions on every error and shutdown path.
Comparison with ERROR_SET_POWER_STATE_FAILED
ERROR_SET_POWER_STATE_VETOED attributes refusal to an application or driver. ERROR_SET_POWER_STATE_FAILED says the BIOS or firmware failed the attempted transition. The investigation boundary therefore moves from software policy and device drivers toward platform firmware for 1141.
Example
A workstation cannot enter sleep while an older capture driver holds a device in an active recording state. The power request returns 1140. Closing the capture session allows sleep, proving that firmware replacement is not the first remedy; the driver and application must release the device before transition.
References
- Microsoft: System Error Codes (1000–1299)
- Microsoft: Powercfg command-line options
- Microsoft: PwrTest requests scenario
- Microsoft: Windows power management
Looking for a different code? Search another status or error code.