Fix 0XC00002B7: NTFS change journal delete stuck

You're staring at 0XC00002B7 and can't access a drive — I've been there.

The culprit is almost always a hung fsutil usn deletejournal command or a backup tool that kicked off a journal delete and crashed. The change journal (USN journal) is marked for deletion, but the process died before finishing. The volume becomes read-only until the delete completes or is rolled back.

The fix: Force the delete to finish

Don't reboot yet — that rarely helps and sometimes locks the journal permanently. Do this instead:

Open an elevated Command Prompt (Run as Administrator).
Run:
```
fsutil usn deletejournal /d C:
```
Replace C: with your affected drive letter.
If it hangs, hit Ctrl+C to cancel, then immediately run:
```
chkdsk /f C:
```
This forces the volume offline briefly and clears the pending journal delete flag.
After chkdsk finishes, reboot. The volume should mount normally.

If chkdsk can't lock the volume (it's still in use), schedule it for next boot: chkdsk /f C: /r. Reboot and let it run.

Why this works

The NTFS change journal is a hidden file ($UsnJrnl) that tracks file changes. When a deletion starts, it sets a state flag in the volume's metadata. If the process crashes, the flag stays set. The OS sees that flag and blocks all write access. Running fsutil again tries to complete the delete, but if the journal is corrupted, chkdsk fixes the metadata and clears the stuck flag.

On Windows Server 2012 R2 and older, I've seen this happen when VSS (Volume Shadow Copy) writers crash mid-backup. On Windows 10/11, it's usually from a third-party antivirus or backup tool that tried to trim the journal and failed.

Less common variations

1. The journal delete is stuck on a system volume

If it's the C: drive and you can't run fsutil because the volume is busy, boot from a Windows Recovery Environment (WinRE) or a live Linux USB. In WinRE, open Command Prompt and run the same fsutil command. The journal delete will finish quickly because nothing else is touching the volume.

2. The error appears in Event Viewer, not on the volume

You'll see Event ID 133 or 134 from NTFS (source: Ntfs). The message says "The change journal for volume X: is being deleted." This is informational — it means the delete was requested. If it stays for hours, the process hung. Use Process Monitor (procmon) to find which process started the delete. Filter by path containing $UsnJrnl. Kill that process, then run the chkdsk fix above.

3. Disk management shows the volume as RAW but it's not

This is a classic red herring. The file system isn't damaged — the stuck journal flag makes Windows think the volume is invalid. Don't reformat. Run chkdsk as above, and it'll come back as NTFS.

Prevention

Never kill a backup tool mid-job. If you must, use Task Manager to stop it cleanly — don't end the process tree on the VSS service.
Update your backup software. Old versions of Acronis and Veeam had bugs that left journal deletes hanging. Check for updates.
Trim the journal manually if it's too big. Use:
```
fsutil usn deletejournal /d /n C:
```
The /n flag reads the journal and compacts it without a destructive delete. This avoids the stuck state entirely.
Monitor with: fsutil usn readjournal C: — if the UsnJournalID or LowestUsn changes unexpectedly, something triggered a delete.

One last thing: if you're on a RAID array or Storage Spaces, make sure the underlying health is good. A failing drive can cause I/O timeouts that make any journal operation look hung. Run wmic diskdrive get status or check the storage controller logs.