| Previous | Next |
| ERROR_DEVICE_NOT_PARTITIONED | ERROR_UNABLE_TO_UNLOAD_MEDIA |
ERROR_UNABLE_TO_LOCK_MEDIA
unable to lock the media eject mechanism.
ERROR_UNABLE_TO_LOCK_MEDIA means that windows or the device could not prevent removal of the currently loaded removable medium. In this case, the decisive context is backup software preparing a tape job, together with device path, media type, owner process/service, and reservation state.
Where the result appears
- backup software preparing a tape job.
- optical, removable, or sequential devices with software-controlled eject locks.
- library robotics coordinating drive ownership.
- maintenance tools that require stable media during a long operation.
Typical causes
- the device does not support locking or is in a state that rejects it.
- another process, service, or library manager owns the device.
- media is being ejected, unloaded, or changed.
- driver, firmware, reservation, or hardware problems prevented the command.
Evidence to collect
- device path, media type, owner process/service, and reservation state.
- the exact lock command, returned device status, and sense data.
- library and removable-storage service events.
- whether a physical operator or automation system initiated unload.
For this condition, begin the investigation with device path, media type, owner process/service, and reservation state. Correlate it with the exact lock command, returned device status, and sense data and check whether the device does not support locking or is in a state that rejects it. 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 start a destructive or long-running operation that assumes stable media when the lock failed. Resolve ownership and device state, then retry once the condition changes. On hardware without locking support, require an operational safeguard instead of pretending the media is secured.
Any retry policy for this Win32 error should be tied to evidence that another process, service, or library manager owns the device has changed. Before another attempt, verify library and removable-storage service events. If driver, firmware, reservation, or hardware problems prevented the command still applies, stop the retry sequence and preserve the first diagnostic event.
Common misinterpretation
The code does not necessarily mean the media itself is write-locked. It concerns the eject/removal mechanism.
Guidance for developers
When surfacing this result through another layer, retain its Win32 domain, numeric value, and the operation described by optical, removable, or sequential devices with software-controlled eject locks. A useful telemetry record also includes whether a physical operator or automation system initiated unload. 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 media is being ejected, unloaded, or changed, assert this result, and confirm that the program releases resources associated with library robotics coordinating drive ownership. The recovery test should also verify that device path, media type, owner process/service, and reservation state is refreshed before the operation resumes.
References
Looking for a different code? Search another status or error code.