ERROR_JOURNAL_DELETE_IN_PROGRESS (0x0000049A) Fix

When This Error Hits

You're running chkdsk /f on a system drive, or maybe your backup software (like Veeam or a Windows Server Backup job) kicks off, and suddenly you get ERROR_JOURNAL_DELETE_IN_PROGRESS (0x0000049A). What's actually happening here is that the NTFS volume change journal — the USN journal — has entered a "marked for deletion" state but never finished cleaning up. This can happen after a failed fsutil usn deletejournal command, an unexpected reboot during disk maintenance, or when a third-party tool (like antivirus real-time scanning) locks the journal file during deletion.

Root Cause

The USN journal is a hidden NTFS feature that tracks every change to files on a volume. When you delete it, Windows sets a flag in the volume's metadata: delete in progress. Under normal conditions, the deletion completes in seconds. But if a crash, power loss, or concurrent process holds a reference to the journal file ($UsnJrnl), the deletion stays stuck. The error 0x0000049A means: any attempt to read or write to the journal sees that deletion flag and refuses to proceed. The file system is not corrupted — it's just waiting for a cleanup that never finished.

Fix: Force the Journal Deletion to Complete

The real fix is straightforward: you need to explicitly tell NTFS to finish deleting the journal. Do not try to re-delete it with fsutil — that'll just return the same error. What works is using fsutil usn with the deletejournal command, but you have to break the lock first.

1. Open an elevated Command Prompt. Press Win+X, choose "Terminal (Admin)" or "Command Prompt (Admin)". This is non-negotiable — normal user won't have the permissions.
2. Identify the volume. Run fsutil fsinfo drives to see all drives. The error will show the drive letter (e.g., C:).
3. Force delete the journal. Run:
   fsutil usn deletejournal /d C:
   Replace C: with your drive. The /d flag means "disable and delete". What's happening under the hood: this command tells NTFS to ignore any pending deletion flag and perform a fresh, forced teardown of the journal file. It may hang for 10–30 seconds — that's normal, it's waiting for the previous deletion to abort.
4. Verify the journal is gone. Run fsutil usn queryjournal C:. If it returns Usn Journal is not active on this volume, you're clear.
5. If the command fails with "access denied", you've got a process holding a lock. Use handle64.exe (from Sysinternals) to find what's holding the journal open:
   handle64 -a -p -nobanner "." | findstr /i usn
   Look for $UsnJrnl — usually it's System (PID 4). Kill the offending process (often the backup agent or a file watcher), then retry step 3.

Why step 3 works: The /d flag doesn't just delete the journal — it first disables it. Disabling flips the volume's state from "delete pending" to "disabled," which clears the lock that generated error 0x0000049A. Then the deletion runs clean. If you don't disable first, you'll keep hitting the same error because NTFS sees the existing deletion flag and refuses to start a new one.

If It Still Fails

Sometimes the journal is so thoroughly stuck that even fsutil can't touch it. In that case:

• Reboot into Safe Mode (without networking). Safe Mode loads minimal drivers and services, so nothing else will hold the journal open. Repeat steps 3–4 there.
• Check for disk corruption. Run chkdsk /f C: — but if you still get 0x0000049A, use chkdsk /f /offlinescanandfix C: to force an offline check at next boot. Corruption in the NTFS metadata (like the $Volume file) can prevent the journal delete from finalizing.
• Update your drivers or backup software. I've seen old versions of Acronis True Image (2020 era) and Veeam Agent 4.x cause this by keeping a stale handle to the journal after a failed backup. Updating to the latest version usually fixes it.
• Last resort — reformat. If none of the above works and the journal is still stuck, you can disable journaling entirely via fsutil usn disablejournal C: (note: disablejournal is a different command from deletejournal). This does not delete the journal but makes it inactive. After a reboot, you can then run fsutil usn deletejournal /d C:. If even that fails, you're looking at a full format — but that's rare.

Bottom line: error 0x0000049A is annoying but not dangerous. The file system is fine — it's just a housekeeping flag that got stuck. The fsutil usn deletejournal /d dance knocks it loose 95% of the time.