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:
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:
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...
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.
See guide to creating journals here:
See also some good advice here:
