| Previous | Next |
| ERROR_INVALID_MESSAGE | ERROR_INVALID_FLAGS |
ERROR_CAN_NOT_COMPLETE
cannot complete this function.
ERROR_CAN_NOT_COMPLETE means that windows could not finish the requested operation, but this code alone does not identify a narrower cause. In this case, the decisive context is filesystem, device, shell, service, or legacy subsystem operations, together with exact API, parameters, target object, and the first failing layer.
Where the result appears
- filesystem, device, shell, service, or legacy subsystem operations.
- wrapper APIs that collapse a more specific lower-level failure.
- operations interrupted by teardown, state changes, or unavailable dependencies.
- compatibility paths where the original subsystem exposes only a generic result.
Typical causes
- the target object changed state during the operation.
- a lower layer returned a failure that was not preserved by the caller.
- the operation is unsupported for the specific device, provider, or object type.
- required cleanup, synchronization, or prerequisite work could not finish.
Evidence to collect
- exact API, parameters, target object, and the first failing layer.
- preceding warnings and lower-level status values before translation.
- object lifecycle, device/service state, and concurrent operations.
- whether the same request succeeds for another object or under a simpler configuration.
For this condition, begin the investigation with exact API, parameters, target object, and the first failing layer. Correlate it with preceding warnings and lower-level status values before translation and check whether the target object changed state during the operation. Capture the original this result immediately after the failing call so later cleanup does not replace the thread-local error value.
Handling and recovery
Do not build a retry loop around this generic code without identifying the changing condition. Instrument the boundary immediately below the API that reports it, and preserve native status, provider error, or device sense information. Recovery depends on that missing context.
Any retry policy for this Win32 error should be tied to evidence that a lower layer returned a failure that was not preserved by the caller has changed. Before another attempt, verify object lifecycle, device/service state, and concurrent operations. If required cleanup, synchronization, or prerequisite work could not finish still applies, stop the retry sequence and preserve the first diagnostic event.
Common misinterpretation
The message is intentionally broad. It should not be presented as proof of corruption, access denial, or temporary unavailability without corroborating evidence.
Guidance for developers
When surfacing this result through another layer, retain its Win32 domain, numeric value, and the operation described by wrapper APIs that collapse a more specific lower-level failure. A useful telemetry record also includes whether the same request succeeds for another object or under a simpler configuration. For windows-related handling, decisions must use the numeric value and documented API contract rather than localized wording.
A focused test should reproduce the condition in which the operation is unsupported for the specific device, provider, or object type, assert this result, and confirm that the program releases resources associated with operations interrupted by teardown, state changes, or unavailable dependencies. The recovery test should also verify that exact API, parameters, target object, and the first failing layer is refreshed before the operation resumes.
References
Looking for a different code? Search another status or error code.