ERROR_JOURNAL_ENTRY_DELETED (0x0000049D) Fix
This error means a program tried to read a USN journal entry that was already deleted. Usually happens after disk cleanup or defrag. Here's how to resolve it.
Quick Answer
Run fsutil usn deletejournal /d C: in an elevated command prompt, then reboot.
What Actually Happens Here
I know this error is infuriating—it usually pops up when you're running a backup tool, antivirus scanner, or file indexing app, and suddenly it throws 0x0000049D at you. The technical name is ERROR_JOURNAL_ENTRY_DELETED, and it means your NTFS USN journal (Update Sequence Number) has a gap. The journal keeps a record of every file change on a volume. When a program reads it sequentially and finds a missing entry—usually because disk cleanup, defrag, or a third-party tool deleted it—Windows bails out with this code.
This tripped me up the first time too. I had a colleague running Veeam backups on Server 2019 who hit this every Wednesday after the scheduled Defrag task ran. The defrag tool internally invalidated old journal entries, and the backup agent couldn't reconcile the sequence. The fix is straightforward: delete the journal and let Windows recreate it fresh.
Step-by-Step Fix
- Open Command Prompt as Admin. Hit Windows Key, type
cmd, right-click and select Run as administrator. Accept the UAC prompt. - Check current journal state. Run
fsutil usn queryjournal C:(replace C: with your drive). You'll see the USN Journal ID and range. If the UsnJournalID is 0, the journal is already gone—skip to step 4. - Delete the journal. Run
fsutil usn deletejournal /d C:The/dflag forces deletion even if the journal has active readers. This is the nuclear option, and it's exactly what you need. Yes, you'll lose tracking data for file change auditing, but the journal rebuilds automatically. - Reboot the machine. Restart Windows. During boot, the NTFS driver creates a new empty journal. No further action needed.
- Verify recreation. After reboot, run
fsutil usn queryjournal C:again. You should see a new USN Journal ID and a start range of 0.
Alternative Fix: Use PowerShell
If you prefer PowerShell, open it as Admin and run:
Get-Volume -DriveLetter C | Set-Volume -DedupJournalSize 0Wait—that's for dedup journals, not USN. For the actual fix, stick to fsutil—PowerShell doesn't have a native cmdlet for USN journal management. Sorry, I've seen people get confused here. Just use fsutil.
Why Not Just Ignore the Error?
Some apps let you skip the error and continue. Don't. A corrupted journal can cause incremental backups to fail silently, or file change notifications to stop firing. Your file auditing (if you use it) will have gaps. The real fix is to delete and recreate—takes 30 seconds.
Prevention Tip
To avoid this in the future, stop any disk cleanup or defrag tool from touching the USN journal. On Windows 10/11, the built-in Defragment and Optimize Drives tool (dfrgui.exe) is safe—it doesn't delete journal entries. But third-party tools like CCleaner's Drive Wiper or older versions of O&O Defrag might. Check their settings: look for an option like "Delete USN journal" or "Wipe free space including journal." Uncheck it.
Also, if you run chkdsk /f often, know that it can reset the journal too. Only run chkdsk when you actually suspect disk errors—not as routine maintenance.
Real-world scenario: I once saw this on a Windows 11 laptop after the user ran "Optimize Drives" with a third-party defragger that had a "Deep Clean" mode enabled. The error popped up in Microsoft OneDrive sync logs. One
fsutilcommand fixed it.
That's it. No complex registry edits, no reinstalling apps. Just delete the journal, reboot, and move on.
Was this solution helpful?