Fix STATUS_OBJECTID_NOT_FOUND (0XC00002F0) Error on Windows
An object ID is missing from the file system. Usually happens after moving or copying files between drives. Simple chkdsk often fixes it.
What Causes STATUS_OBJECTID_NOT_FOUND?
This error 0XC00002F0 means Windows can't find the object ID metadata for a file or folder. Happens most often when you copy data from an NTFS volume to another with different cluster sizes, or restore from backup that didn't preserve file metadata properly. You'll see it when trying to open a file from a network share, removable drive, or after a manual move operation.
The culprit here is almost always a corrupt NTFS Master File Table ($MFT) entry for that specific file. Don't bother reinstalling drivers or replacing hardware — it's a file system issue, not a hardware one.
Step 1: The 30-Second Fix — Run CHKDSK on the Volume
This should fix the problem 70% of the time. Don't skip it. Open Command Prompt as Administrator and run:
chkdsk X: /f /r
Replace X: with the drive letter showing the error. The /f switch fixes file system errors, /r locates bad sectors and recovers readable info. On a system drive, you'll get a prompt to schedule at next reboot. Say yes, then restart.
Don't bother with /scan or /perf — they're slower and don't fix object IDs. Stick with /f /r.
After chkdsk finishes, try accessing the file again. If it works, you're done. If not, move to Step 2.
Step 2: The 5-Minute Fix — Reset Object IDs on the Affected File
Chkdsk didn't cut it? Let's manually nuke the object ID for that specific file. Object IDs are optional metadata — Windows creates them for file tracking and link support, but they're not critical for file access. Removing the corrupt one lets the system create a fresh one.
Open Command Prompt as Administrator and use fsutil. First, find the 8.3 short filename if the path is long or has spaces. Then run:
fsutil objectid query "C:\full\path\to\file"
This will either show the current object ID or error out. If it shows one, delete it with:
fsutil objectid delete "C:\full\path\to\file"
If the file is a system file or in use, you'll need to boot from a WinPE or another OS installation to run this. For regular user files, this works immediately.
After deletion, try opening the file. The OS will auto-generate a new object ID on next access. Problem solved for most cases.
Step 3: The 15+ Minute Fix — Advanced MFT Repair with NtfsDisableLastAccessUpdate
This one's for when the above fails, or the error affects multiple files across a volume. It's a registry tweak plus a full CHKDSK with offline repair.
- Disable last access time updates — this reduces metadata thrashing that can corrupt object IDs. Open Regedit and go to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
Find NtfsDisableLastAccessUpdate. If it doesn't exist, create a DWORD (32-bit) with that name. Set it to 1. Reboot.
- Run CHKDSK with offline repair — boot from Windows installation media (USB/DVD), choose Repair your computer > Troubleshoot > Command Prompt. Then run:
chkdsk C: /f /r /x
The /x forces the volume to dismount first, giving chkdsk exclusive access. This catches MFT corruptions that online chkdsk misses. Let it run — can take 30 minutes to hours on large drives.
- As a last resort, copy all data off the volume, reformat it with default cluster size (4KB for under 16TB), and copy back. Use robocopy with
/COPY:DATSOUto preserve all metadata including object IDs:
robocopy source\ dest\ /E /COPY:DATSOU /R:2 /W:5
If you don't care about object IDs (most people don't), you can skip the /COPY:DATSOU flag and just copy normally.
Prevention Tips
- Always use robocopy or xcopy with proper flags when moving files between volumes — avoid drag-and-drop for large data sets.
- Keep your drives at least 10% free space. NTFS metadata fragmentation spikes when a volume is over 90% full, and that's when object IDs get corrupted.
- Run a monthly
chkdsk /fon drives that see heavy file creation/deletion (like Temp drives or user shares). - If you're on a server with deduplication enabled, this error pops up more often. Disable dedup for volumes with critical file metadata.
That's it. You probably didn't need the advanced steps — chkdsk fixes 7 out of 10 cases. If you got to Step 3 and still have the error, the drive might be failing hardware-wise. Check the SMART data with CrystalDiskInfo before replacing the drive — but at this point, I'd back up everything immediately.
Was this solution helpful?