You're trying to modify a file and Windows throws 0xC00000D5 — annoying as hell. Let's fix it.
The culprit here is almost always another process renaming the file out from under your application. Most of the time it's real-time antivirus scanning or a backup tool that's holding the file handle stale.
Step-by-Step Fix
- Close all programs accessing the file. Yes, even that Explorer window you left open. Reboot if you have to — it's the nuclear option but works when you're stuck.
- Disable real-time antivirus temporarily. Windows Defender, third-party AV — turn it off for 5 minutes. If the error goes away, add an exclusion for the folder or file type. Don't bother disabling the entire AV permanently, just the real-time component.
- Check for backup/sync software. OneDrive, Google Drive, Dropbox, Veeam, Acronis — these love to rename temp files mid-write. Pause all sync and backup jobs. If the error stops, you found the culprit.
- Run the file operation from an elevated command prompt. Open CMD as admin and try your operation there. Sometimes permissions and handles are cleaner.
# Example: If copying the file fails, try from CMD: copy C:\path\to\file.txt D:\backup\file.txtWhy This Happens
NTFS allows multiple processes to have handles on a file. When one process renames the file, all existing handles become stale — they point to the old name. Any write operation through that stale handle triggers 0xC00000D5. It's not corruption, just a timing conflict. The OS isn't broken, your file isn't lost.
Less Common Variations
- Network shares. If the file is on a NAS or SMB share, the remote server might rename the file (e.g., during dedup or tiering). Try copying the file locally first.
- Developer tools. Visual Studio or IDEs running file watchers (like Webpack, Gulp, or hot reload) can trigger this. Disable automatic renames in your IDE settings.
- Symbolic links or junction points. If the file path goes through a reparse point, the target rename can cause 0xC00000D5. Use
dir /aLto check for junctions. - Database files (SQL Server, Exchange). These are extremely sensitive to rename operations. Never manually rename a database file while the service is running.
Prevention
- Add folder exclusions in your antivirus for directories where you frequently modify files — your project folders, temp directories, sync folders.
- Schedule backups during off-hours to avoid coinciding with active file edits.
- Close file handles properly. If you're writing code, always call
CloseHandleor dispose of your file streams. Leaked handles are a ticking time bomb.
One last thing — if none of this works, check the Windows System Event Log (Event Viewer → Windows Logs → System). Filter by source 'NTFS' or 'Ntfs' and look for entries around the time of the error. They'll tell you exactly which process renamed the file. That's your smoking gun.