I have a volume corruption: Specifically, it is a chkdsk Stage 3 Error. At stage 3, Chkdsk verifies Security Descriptors and USN Journals. However, chkdsk /f repair fails to run at Windows restart. enter image description here

I have run chkdsk. It reports no issues. However, when I run chkdsk /scan, which executes further checks on the NTFS file system, I am getting an error at Stage 3. Stage 3 of the chkdsk process verifies security descriptors and USN journals (USN = Unique Sequence Number). Chkdsk reports the following message:

'Windows has found problems which must be fixed offline. Please run "chkdsk /f" to fix the issue.'

When I execute fsutil dirty query at the command prompt, I get the result:"

Volume C: is dirty

This means the dirty bit has been set for the volume, marking the drive as being corrupt and in need of a chkdsk repair.

However, when I attempt to run chkdsk /f at the next reboot of Window, I get the message "Scanning and Repairing" but do not see any progress percentages to indicate that repair is taking place. Windows successfully boots and does so quickly further indicating that a repair did not run. When I run fsutil dirty query again, I find the dirty bit remains set and running chkdsk /scan continues to report the stage 3 error.

I am seeing the "Scanning and Repairing Drive (c:) at every Windows start-up. Windows is detecting the dirty bit and attempting to run the repair at each start-up but fails to even commence the repair (as I do not see any progress indicators).

One of the symptoms is that I am unable to take backups (specifically I use the legacy Windows 7 Backup which fails) as Windows reports the backup failed because my disk is corrupt. When backup fails due to volume corruption, it can I believe, suggest an issue with the NTFS USN journals (I'm only guessing).

I have read that chkdsk /f and defrag can fail to run when there is an NTFS journal corruption and that a journal reset can resolve the issue. This can be done running the command fsutil usn deletejournal at the command prompt with administrator privileges. It may be necessary to apply the /d /n switches and also to recreate the journal afterward by running the command fsutil usn createjournal afterward. However, I do not know how safe it is to delete the journal. Furthermore, I am unsure about the switches: /d appears to disable the journaling. Is this permanent? I do not even know what this means.

To recreate the journal various parameters need to be provided with the fsutil usn createjournal and I do not know what they should be or how to properly run that command.

ALSO PLEASE NOTE: I AM SPECULATING HERE with deleting and recreating the NTFS journal as a possible solution.

Can anyone please suggest any solutions to my issue. Thank you.

2 Answers 2


OK, for the benefit of others, I will provide you with all the knowledge I have acquired which has helped me to resolve this issue.

In my case chkdsk was failing to execute its repair on my machine at each Windows start-up. With the dirty bit set, Windows was trying to execute chkdsk /f at every boot, but the execution of the repair was failing. I suspect the reason for this may be that my computer is quite modern and has BitLocker encryption activated on the drive. Hence, when I restart my PC, chkdsk fails as the drive remains in a RAW and encrypted state at the time chkdsk is initiated. If I am correct, then this may prove to be an increasingly common problem as the sale of computers with encrypted drives becomes the norm. Microsoft also needs to revisit this issue. Its design of the way chkdsk works when executed on the primary drive, needs to be revisited due to encryption preventing chkdsk from running at Windows startup.

I followed the advise of @tsc_chazz and booted to the command prompt, then ran chkdsk /f from there. Bam! problem solved! I could not believe it, it worked! Of course as the drive was encrypted, I had to provide the 48 character encryption key (which I knew nothing about and had to obtain from Microsoft via aka.ms/myrecoverykey). In my first attempt I skipped the page asking for the recovery key (ie: bitlocker encryption key) and was receiving error messages when I tried to run chkdsk /f from the boot-to-command-prompt environment. Chkdsk failed stating the type of the volume is RAW and that chkdsk does not run on RAW volumes.

All of this also suggests that any attempt to run chkdsk on the drive when it is mounted externally, may also fail. So for example, if I were to boot to a USB recovery disk and ran chkdsk on my primary partition from this recovery environment, it too would fail because the drive remains encrypted. The way around this would be to turn off the BitLocker on the drive via the Control Panel, beforehand. See guide here. The drive's decryption process can take a very long time. However, this step should not be necessary as booting to command prompt takes you to a different drive (X: in my case) thus allowing you to run chkdsk /f on your primary partition (usually the c: drive).

So in summary, booting to command prompt and entering the recovery key in the process to decrypt the drive, then running chkdsk /f from there fixed the problem for me. Also, there is no need to run chkdsk /r. This takes much, much longer (hours to days) and is usually not necessary as physical issues (bad clusters) are much less likely to be the culprit or cause of the corruption.

However, had this not worked, I would have recreated the NTFS file system's USN journals. This is because a chkdsk Stage 3 corruption relates to a corruption of these journals -I would imagine a hiccup with the USNs (Update Sequence Numbers). It has been noted that such a corruption can itself be the cause of chkdsk failing to run. Corruption here, can also cause backups and Defragging to fail. When running a backup, such as the Windows 7 backup, you may see an error message saying something like...

The backup failed for the following files because they are on corrupted drive c:

To recreate the NTFS USN journals, first delete, then recreate the journal.

Deleting the Journal
You can delete the NTFS USN journal using...

fsutil usn deletejournal /d /n c:

This can take hours to run and will "lock your PC" until completed if you use the /n switch. So alternatively you can leave out the /n switch and it will delete the journal in the background and across reboots if necessary.

The /d and /n switches are poorly documented. Microsoft documentations here conflicts with information presented when you query the use of the command at the command prompt:

enter image description here

Both are inaccurate! The command prompt documentation is wrong as BOTH switches delete the journal, not just the /d. The Microsoft webpage documentation is misleading because the journal is actually deleted rather than disabled. The switches dictate how it gets deleted.

Because deleting the journal can take a very long time, the switches allow you to control whether it runs in-process or out-of-process. The /n switch executes deletejournal in process locking the handle to it (think of it as "locking the computer"). This forces you to wait until it has completed. The /d switch executes out-of-process and allows you to continue working. Deleting the journal can take hours to run and will continue across successive reboots until it has been completed. I have seen people apply both switches together when they are mutually exclusive.

Deleting the journal is nearly always safe, but it can sometimes have consequences with backup processes. Applications that are using the journal will not see file changes between the last time the application ran and when the journal was deleted. Well-programmed applications will detect that the journal was deleted and will revert to an alternative method of finding changed files or recreate it. I would advise it is safe to delete despite the consequences because at worst, you will only compromise the incremental ability of the backup. You can still do a FULL backup and start again; at least your data is not lost!

Recreating The Journal
I am informed it is not necessary to manually recreate the journal as running a backup program such as the Windows-7 backup option via the Control Panel (despite its name this option is available on Windows 8/8.1 and 10 also) will automatically recreate the NTFS journal.

If you want to manually recreate the journal, then at the command prompt, run either:

fsutil usn createjournal m=536870912 a=67108864 C:

...if you have a very large drive (4TB+ with 400,000+ files);

Or for smaller drives, with fewer files, run:

fsutil usn createjournal m=67108864 a=8388608 C:

If you are curious where these figures come from, they are the number of bit states raised to a sufficient power that provides the size in bytes for the journal log. IE: These figures are 2^x which gives the precise size in bytes around the size you want. Journals are typically kept between 30Mb to 40MB in size. I have hence, gone up to the next highest available size (67Mb) for the maxSize (m) parameter:

2^25 bytes x 2 = 33Mb x 2 = 67Mb

The allocationDelta (a) parameter needs to be around 1/8 of m, which is around 8Mb. You will not find this explanation anywhere else on the internet!!! Microsoft especially, have shamefully failed to adequately document the use of these two journal commands.

FYI: You can query the current size of your journals, by typing the following command at a command prompt with elevated privileges:

C:\Windows\system32> fsutil usn queryjournal C:

You will get an output similar to this:

enter image description here

The a and m parameters are provided in BYTES, in hexadecimal. For my Windows 8.1 PC with a 2TB primary partition, the values equate to:

m = 33,554,432 bytes = 33Mb

a = 8,388,608 bytes = 8Mb

You can query the number of files on your system by executing the following command at a command prompt with elevated privileges:

C:\Windows\system32> dir C:\ /s /a /w

You will see an output like this...

enter image description here

Add the number of files and directories together for the total amount; 1,616,718 in this example.

You can then use the following table (reproduced from this page ) as an alternative guide to find the appropriate values for Maximum Size and Allocation Delta.

enter image description here

See guide to creating journals here: See also some good advice here:


I think that in this case you might have to get serious. If it was my system, the first thing I'd do is try getting back to a command prompt - on the login screen, hold Shift while selecting reboot; boot into repair your PC, go to the advanced pages and start a command prompt - confirm the disk letter that contains your live Windows install and chkdsk /f from there. Alternately, it would be possible to pull the disk, and use a USB/SATA adapter to attach it as an external to some other machine which could then do the chkdsk. I'm reluctant to suggest booting from a Linux distro and running the Linux fsck, because while their NTFS implementation is very good, it may be missing some of the finer details.

  • The author has already tried your suggestion based on their description. The point they are running the command chkdsk /f has already been issued from the command prompt after booting into Advanced Startup.
    – Ramhound
    Apr 15, 2021 at 20:15
  • Hi actually, I have only run chkdsk /f from the command prompt within Windows only. If it really does make a difference, I will attempt to run it from the pure command prompt, boot-up environment. Does this have the same effect as running it from an external drive? That is to say, boot to a usb device and run chkdsk from there?
    – IqbalHamid
    Apr 16, 2021 at 22:04
  • 1
    Possibly. Booted from the recovery partition, and using the command shell in the recovery partition, it should not be using any files in the primary partition at all, and chkdsk should run unhindered. But note that "should," and bear in mind that I don't entirely trust Windows. As an external disk, the command prompt definitely won't be using any files on the partition you want to check.
    – tsc_chazz
    Apr 17, 2021 at 2:46
  • @ tsc_chazz Hey thanks buddy, your advice really helped. I did just that and it worked like a charm. I could not believe it after unsuccessfully trying so many other solutions.
    – IqbalHamid
    Apr 21, 2021 at 13:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .