Fix STATUS_JOURNAL_NOT_ACTIVE 0XC00002B8 on NTFS

You're probably here because an app or Windows itself threw error 0XC00002B8.

It's the STATUS_JOURNAL_NOT_ACTIVE error. The volume change journal (USN journal) on one of your drives is turned off or corrupted. This journal tracks file changes, and when it's missing, backup software, antivirus, or disk tools can't work. Let's get it back.

The fix: Recreate the USN journal

This works on Windows 10 and 11, all editions. You'll need an admin command prompt.

Press Windows Key + X, then click Command Prompt (Admin) or Windows Terminal (Admin).
Type fsutil usn queryjournal C: and press Enter. Replace C: with the drive where the error appears (D:, E:, etc.).
Expected outcome: If the journal is inactive, you'll see Usn Journal : Not active. If you see a long list of fields, the journal is active—skip to the next section.
If inactive, type this command: fsutil usn createjournal m=1000000 a=1000000 C:
The m=1000000 is max size (1 MB) and a=1000000 is allocation delta (1 MB). You can raise these if needed—more on that later.
Press Enter. You should see Change journal created successfully.
Now verify: run fsutil usn queryjournal C: again. You'll see the journal is active.
Close the command prompt. Test whatever app gave the error—it should work now.

That's the main fix. Takes about 30 seconds.

Why the journal goes inactive in the first place

The USN journal can be disabled by disk cleanup tools, third-party defragmenters, or a bad shutdown. I've also seen it happen after a failed system restore or a Windows update that messes with volume mount points. The journal isn't critical for everyday file access, but software that monitors changes depends on it.

When you create a new journal, Windows starts fresh. The old entries (if any) are gone, but that's fine—they're just a log of past changes, not the files themselves. You won't lose data.

Real-world scenario: A user ran a disk optimizer that accidentally deleted the journal. Their backup software (Veeam) threw 0XC00002B8. Recreating the journal fixed it instantly.

Less common variations of this issue

1. Journal exists but shows errors

Sometimes fsutil usn queryjournal returns data but the journal is corrupt. You'll see strange numbers in the Next Usn field or the Max Size is zero. Fix: delete and recreate the journal.

Run these commands in order:

fsutil usn deletejournal /d /n C:
fsutil usn createjournal m=2000000 a=1000000 C:

The /d flag disables and deletes the journal. The /n prevents a confirmation prompt. Then you recreate it.

2. The drive is too full to create a journal

If the drive has less than 1 MB free, the journal can't be created. Free up space by deleting temp files or moving data. Then retry the createjournal command.

3. The error comes from a different drive (like a network share)

0XC00002B8 only applies to local NTFS volumes. If it appears on a network path, the remote server has the journal issue. You'd need admin access on that server to fix it.

4. Third-party software that uses change journals (like File History or backup tools)

Some apps have their own journal management. If you keep seeing the error after recreating the journal, the app might be reading a stale handle. Restart the app or reboot the machine. That refreshes the handles.

Prevention: Keep the journal healthy

Do these three things and you'll rarely see this error again:

Don't run sketchy disk cleanup tools. Stick with Windows Disk Cleanup (cleanmgr.exe). Some third-party tools have an option to wipe the USN journal—leave that unchecked.
Schedule regular chkdsk scans. Once a month, open an admin command prompt and run chkdsk /f C: (replace C: with your drive). It'll schedule a scan on next reboot. This catches file system corruption before it kills the journal.
Keep your drive healthy. A failing hard drive can corrupt the journal. Check drive health with CrystalDiskInfo or the built-in wmic diskdrive get status command. If status is not OK, replace the drive.

If you have backup software that complains about the journal, recreate it once. That's usually a one-time fix. If it happens again every few weeks, suspect a deeper file system issue—run chkdsk /f /r on that drive (this can take hours).

That's it. You're done. The error shouldn't come back unless something deliberately deletes the journal again.