0X80000011

STATUS_DEVICE_BUSY (0x80000011): The Device Is Currently Busy

The device is busy because another process or driver still holds an open handle. Find and release that handle, then the error clears.

Quick answer

0x80000011 means some process or driver still has an open handle to the device. Close that handle and the error goes away.

What's actually happening here

STATUS_DEVICE_BUSY is NTSTATUS code 0x80000011, returned by the kernel when a driver receives an I/O request it can't service because the target device is already locked, claimed, or mid-operation. It's not a hardware failure — it's a contention problem. The device is fine; something is using it.

Three situations cover most cases. First, a user-mode process has an open handle to the volume or device (backup software, antivirus scanning a USB stick, an Explorer window pointed at a drive letter you're trying to unmount). Second, a kernel driver has claimed exclusive access — for example, a filter driver from a disk imaging tool, or a virtual disk service still holding a VHD. Third, the device is in a state machine the driver won't leave until an outstanding request completes, which happens with flaky USB controllers and some NVMe hot-plug scenarios.

I hit this most often on Windows Server 2022 when a scheduled backup finishes but the VSS shadow copy hasn't been released yet. The drive letter still shows up in Explorer, but any attempt to dismount or resize returns 0x80000011. Wait 30 seconds and try again — it clears itself. If it doesn't, you've got a real handle leak.

Fix it

1. Identify which process holds the handle

Sysinternals handle.exe is the fastest way. Run an elevated command prompt and search for the device name.

handle.exe -a "\\Device\\HarddiskVolume3"

Or for a drive letter:

handle.exe D:\

The output lists the PID and process name for every open handle. Kill or close the offending process.

2. If handle.exe isn't available, use Process Explorer

Download Process Explorer, run as administrator, press Ctrl+F, type the device or drive letter, and hit Search. It'll show you the process in the lower pane. Right-click the handle and choose Close Handle — but only if you're confident closing it won't corrupt data. For a write operation in flight, killing the handle means losing whatever was being written.

3. Check for VSS and shadow copies

On servers, VSS is the usual suspect. List existing shadow copies:

vssadmin list shadows

If one is stuck, delete it explicitly:

vssadmin delete shadows /for=D: /oldest

The reason this works is that VSS holds an exclusive lock on the volume until the shadow is torn down. An orphaned shadow from a crashed backup job will hold that lock indefinitely.

4. Restart the device, not the machine

In Device Manager, find the device, right-click, Disable device, wait five seconds, then Enable. That forces the driver to release its handle and re-enumerate. It's faster than a reboot and usually clears transient states.

5. Check antivirus exclusions

Real-time scanning holds handles on removable media. If you're scripting something like mountvol or diskpart against a USB drive and Defender is scanning it, you'll get 0x80000011 intermittently. Add the drive letter to your AV exclusion list temporarily to confirm.

If that doesn't work

  • Reboot into Safe Mode. No third-party drivers load, so any handle leak from a filter driver disappears. If the error goes away in Safe Mode, the culprit is a driver — usually a storage filter from a backup or encryption product.
  • Check for driver updates. Older USB xHCI drivers on Windows 10 builds before 21H2 have a known bug where the device state machine won't release after a surprise removal. Grab the vendor's latest chipset driver, not the Microsoft generic one.
  • Look at mounted VHDs. If you've mounted a VHD or VHDX via Disk Management and forgotten about it, the parent volume stays busy. Get-DiskImage -ImagePath C:\path\to\file.vhdx | Dismount-DiskImage in PowerShell releases it cleanly.
  • Use fsutil volume dismount. For a specific volume, this forcibly dismounts it. Data loss risk is real if writes are pending, so only use it when you're sure nothing's mid-write.

Preventing it

Stop leaving Explorer windows open on removable drives. Explorer maintains a handle to every drive letter it's displaying, which is why you get "device busy" when you try to safely eject a USB stick while a folder from it is open in the background. Close all Explorer windows pointing at the device before unmounting.

Also stop backup jobs from overlapping. If a scheduled task fires while the previous run is still tearing down its VSS snapshot, the second run will hit 0x80000011 within seconds. Stagger your triggers, and check vssadmin list writers if you're not sure whether the previous run finished cleanly.

The error isn't telling you the device is broken. It's telling you someone else is using it. Find them, or wait them out.
Related Errors in Windows Errors
0X0000217B Fix ERROR_DS_NAME_NOT_UNIQUE (0X0000217B) in Active Directory 0X80290108 TPMAPI_E_ACCESS_DENIED (0X80290108) – TPM Caller Rights Fix 0XC0000284 STATUS_DESTINATION_ELEMENT_FULL (0XC0000284) — Changer Slot Already Loaded 0XC01E0345 Fix 0xC01E0345 VidPN path geometry transform error

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.