When You'll See This Error
You're copying a folder from one NTFS drive to another, or restoring files from a backup, and it stops dead with 0XC000022A. Windows tells you the operation couldn't complete because the ID is already in the index. It's not a permissions thing. It's not a locked file. It's an NTFS metadata collision.
This shows up most often after you've cloned a hard drive or used disk imaging software like Acronis, Clonezilla, or Macrium Reflect. The clone duplicates the unique Object IDs that NTFS assigns to files and directories. When you try to copy those files back to the original drive (or another volume that already has the same IDs), Windows says no.
Root Cause
NTFS gives every file and folder a 64-byte Object ID. It's not the filename — it's a hidden identifier used by distributed link tracking and the Indexing Service. When you image a drive, those IDs get copied verbatim. Now you've got two files claiming the same ID on the same volume. Windows can't have that, so it throws 0XC000022A.
The culprit here is almost always a clone or restore job that didn't use the "copy" or "move" semantics properly. Third-party backup tools sometimes strip or regenerate these IDs, but cheap or fast settings skip that step. You can also get this from a corrupted NTFS index, but that's rarer — maybe 1 in 20 cases.
How to Fix It
Skip any GUI tools for this. The fix is two commands in an elevated command prompt. I've done this on Windows 10, 11, Server 2019, and Server 2022 — same process every time.
Step 1: Find the offending file or folder
Open Command Prompt as Administrator. Navigate to the parent directory of whatever failed. Then run:
dir /x /q
This shows short names and owner. The file you're trying to copy is the one that broke. If the error message didn't give you the full path, use the Event Viewer — look under Windows Logs > Application for source "NTFS" with event ID 55. It'll tell you the exact file.
Step 2: Check the Object ID
Run this on the file or folder that failed:
fsutil objectid query "C:\path\to\your\file.ext"
If it returns an Object ID, note it down. You'll see something like:
Object ID : 9c4b5a6d-3f2e-1a0b-8c7d-6e5f4a3b2c1d
Step 3: Delete the duplicate Object ID
This is the fix. Run:
fsutil objectid delete "C:\path\to\your\file.ext"
This clears the Object ID from the file. Windows will assign a new unique one when the file is next accessed or modified. The file itself doesn't change — no data loss, no corruption. I've done this hundreds of times and never had a side effect.
Step 4: Retry the copy
Go back and copy the file or folder again. It should work now. If it doesn't, there's a second file somewhere else with that same ID. Use fsutil to query the whole volume for duplicate IDs (that's a PowerShell script — see Step 5).
If It Still Fails
Two things left to check.
Run Chkdsk
A corrupted index can cause persistent duplicates. Run this:
chkdsk C: /f
You'll need to schedule it and reboot. Chkdsk will fix orphaned or duplicate index entries. After the reboot, try the copy again. I'd say 60% of the time this resolves it if the fsutil delete alone didn't.
Find all files with the same Object ID
If you're still stuck, there are multiple files with the same ID. Use PowerShell (as Admin):
Get-ChildItem -Path C:\ -Recurse -Force | ForEach-Object {
$id = (fsutil objectid query $_.FullName 2>$null) -match 'Object ID'
if ($id) { [PSCustomObject]@{ Path = $_.FullName; ID = $id[0] } }
} | Group-Object ID | Where-Object { $_.Count -gt 1 } | Select-Object -ExpandProperty Group
This spits out every file with a duplicate Object ID. Delete the ID from all but one copy using fsutil objectid delete on each. The remaining file keeps its ID, the others get new ones when written.
Prevention
When cloning drives, use the "copy" option in your imaging tool if it has one — that skips Object IDs. Or better, use robocopy with /COPYALL which handles this cleanly. If you're stuck with a full image, always regenerate IDs after restore. Some tools have a checkbox for this. Look for "reset object IDs" or "regenerate file IDs".
I've seen this error on everything from Windows 7 to Server 2025 preview builds. The fix never changes. fsutil + chkdsk, in that order, and you're done.