0X000000DC

Fix ERROR_FILE_CHECKED_OUT (0X000000DC) in Windows

Windows Errors Intermediate 👁 7 views 📅 May 28, 2026

This error pops up when a file is locked by another user or process. The fix is usually releasing the lock or killing the holding process.

You're trying to open or save a file on a network share or SharePoint synced folder, and Windows throws back ERROR_FILE_CHECKED_OUT (0X000000DC). The exact message says "This file is checked out or locked for editing by another user." This usually happens when you're working with shared documents (Office files, CAD drawings, or any file that supports check-in/check-out) and someone else has a lock on it. I've also seen it when a previous session crashed and left a lock file behind.

What's actually happening here

The file isn't corrupt, and there's nothing wrong with your drive. The operating system is telling you that another user or process holds an exclusive write lock. On a local drive, this is usually a leftover lock from a crashed app. On a network share (especially with SharePoint or a document management system), it means the file is checked out to someone else's username.

The culprit here is almost always a stale lock — someone opened the file, walked away, their laptop went to sleep, and the lock never got cleaned up. Or a previous instance of Word or Excel crashed without releasing the lock.

Step-by-step fix

Start with the simplest checks. Don't bother reinstalling anything — that won't touch this error.

  1. Check who has it open. On a network share, ask around. If you're in a team, send a quick message. Nine times out of ten it's Bill from accounting who opened the file before lunch and forgot about it.
  2. Use Handle or Process Explorer. Download Sysinternals Handle from Microsoft. Open an admin command prompt and run:
    handle.exe -accepteula -a "\\server\share\path\to\file.xlsx"
    This shows the process ID and username holding the lock. If it's your own machine, you can kill the process with handle.exe -c <PID>. If it's a remote machine, you're out of luck — you need physical access or admin rights on that box.
  3. Check for hidden lock files. On a local drive or network folder, look for files with a tilde (~) at the start (like ~$presentation.pptx). These are temporary lock files. If the owner is gone, delete them. Make sure no one else is using the file first.
  4. SharePoint sync? Force a sync. If you're using OneDrive or SharePoint, sometimes the sync client gets confused. In OneDrive settings, go to Account > Stop sync on that folder. Then restart OneDrive and re-sync. This clears stale check-outs.
  5. Check-in from the document management system. If you're using SharePoint or a document library, go to the library in a browser. Find the file, hover over it, click the ellipsis (three dots), and look for "Check in" or "Discard check out." You need at least Edit permissions to do this.
  6. Kill the lock via command line (advanced). If you're on the same machine and nothing else works, run:
    net file
    This lists all open files on the local machine. Grab the ID number for your file, then:
    net file <ID> /close
    This is forceful — it'll close the file for all users. Use it only if you're sure no one is actively editing.

If it still fails

If none of that worked, you're likely dealing with a file that's checked out on a remote server you don't control. Here's what to check:

  • Permissions. Do you even have write access to the folder? Sometimes a permissions change mid-session leaves you in read-only limbo. Ask your admin to verify your NTFS and share permissions.
  • Antivirus real-time scanning. Some aggressive AV software (I'm looking at you, McAfee) can lock files during scans. Try temporarily disabling real-time protection and see if the error goes away. If it does, add an exception for that folder.
  • Third-party sync tools. Dropbox, Google Drive, or older SharePoint sync tools can leave ghost locks. Unlink and relink the folder. Or try pausing sync temporarily.
  • Restart the File Server. If you're the admin and this is happening to multiple users on a server, a reboot might clear all stale locks. Do it during maintenance hours.

Don't waste time with chkdsk or SFC — disk corruption rarely causes this specific error. And don't blame Windows itself; it's doing exactly what it's supposed to do by refusing to let you overwrite a file someone else is editing. The fix is always about finding and releasing the lock.

Was this solution helpful?