STATUS_PROPSET_NOT_FOUND (0XC0000230) fix in Windows 10/11

When this error hits

You're copying files to an external drive, running a backup job with Veeam or Windows Backup, or syncing with OneDrive. Then it stops. The error code 0XC0000230 pops up, sometimes paired with "STATUS_PROPSET_NOT_FOUND" or just "The specified property set does not exist on the object."

This isn't random. It's tied to specific files that have been corrupted or partially written. Common triggers: an interrupted write during a power loss, a failed file move over the network, or a sudden USB disconnect while a file was being updated. The file still exists, but its extended attributes — the property set — got mangled.

What's actually happening

NTFS stores metadata about files in two main places: the file itself, and its extended attributes (EAs). Those EAs live in a separate structure on the disk, outside the file data. For certain operations — like reading a file's security descriptor, alternate data streams, or custom property sets — the system needs both the file data and its EA block.

When that EA block is missing or points to a location that's no longer valid, Windows returns 0XC0000230. The file looks fine in Explorer. You can even open it. But copying, backing up, or reading its properties triggers the error because those operations request the full metadata.

The fix

Skip the obvious stuff like running a virus scan — that won't touch EA corruption. Here's what works.

Step 1: Check which file is causing the trouble

If you don't know the exact file, use Process Monitor from Sysinternals. Run it, filter by Result is STATUS_PROPSET_NOT_FOUND, and look at the path column. That tells you which file has the bad property set.

Once you know the file, try something simple first: move it to a different folder on the same drive. If that works, you can delete it or restore it from backup. The move operation often forces Windows to repair the EA block during the relink.

Step 2: Rebuild the USN journal

The USN journal tracks changes on NTFS volumes. If the journal itself got corrupted, it can report phantom property sets. Killing it forces NTFS to rebuild it from scratch, which usually cleans up the bad entries.

Open Command Prompt as Administrator. Then:

fsutil usn deletejournal /d C:

Replace C: with the actual drive letter. This disables the journal and deletes it. Then reboot. On next boot, Windows recreates the journal automatically.

Don't worry about the warning that says "This operation may cause data loss." It's a generic message — the only thing lost is the journal history, not your files.

Step 3: Run chkdsk with spot fix

Standard chkdsk won't repair EA corruption. You need the /spotfix flag, which was added in Windows 10 version 1803. It's faster than a full /f scan and targets exactly the kind of metadata corruption we're dealing with.

chkdsk C: /spotfix

This runs only on the next reboot, so schedule it and restart. The scan takes seconds, not hours.

Step 4: Disable Remote Differential Compression (RDC)

RDC is a protocol Windows uses for sync operations — like BranchCache or DFS replication. It relies heavily on property sets to compare file changes. When those sets are broken, RDC throws 0XC0000230 instead of handling the error gracefully.

If the error happens repeatedly during sync or backup operations, just turn RDC off:

1. Open Control Panel > Programs and Features > Turn Windows features on or off.
2. Expand Remote Differential Compression API Support.
3. Uncheck the box. Click OK.

No reboot needed. The error should stop immediately. You lose the ability to sync over low-bandwidth links, but for most home and small office setups that doesn't matter.

Step 5: Wipe the file's extended attributes manually

If you still get the error on a specific file, you can strip its EAs using PowerShell. This is nuclear — the file's custom metadata (like Zone.Identifier or file tags) is gone, but the file itself stays intact.

Set-ItemProperty -Path "C:\path\to\file.txt" -Name Attributes -Value ([System.IO.FileAttributes]::Normal)

This resets all attributes including read-only, hidden, and extended attributes. The property set entry gets deleted. The file works again.

If it still fails

Check your disk health. Corruption that keeps coming back points to failing hardware. Run wmic diskdrive get status — if it returns anything other than "OK", replace the drive. Also check Event Viewer under System for Event ID 55 or Event ID 50. Those are the disk subsystem reporting that writes are failing silently.

Another thing: third-party backup software sometimes creates files with proprietary property sets that Windows doesn't understand. If the error happens only inside a backup application, contact that vendor's support. The file system isn't the problem — the app is writing corrupted metadata.

Finally, if none of these steps help, back up everything and format the drive. That sounds extreme, but a volume-level corruption that resists chkdsk and USN rebuilds isn't going to fix itself. Better to spend two hours reinstalling than two days chasing a ghost.