Question NTFS partition is good on the system drive but it just won't boot ?

Status
Not open for further replies.
Sep 16, 2023
9
1
15

TL;DR: My second system drive is 'a little' corrupt: files can be accessed, partition taken/used space information is correct, sectors are good but it just won't boot past Windows loading. Chkdsk, sfc etc. all good. The only error is seen in SRTTrail.txt (Startup repair) logs.​

I now have 2 SSD system drives with Windows 10.
Drive C: (2TB) is new.
Drive D: (1TB) has been in my PC for a 1 year.
They are both good in terms of chkdsk and HD Tune (test for bad sectors).

# Background:

My idea was to install system on the new C, review and copy data I needed from D in the span of few days, and then format D.
But what happened is:
1. I installed the system on C along with the basic software that I need (VcRedist, notepad++, VSCode, Adobe programs etc.) and Windows Updates.
2. Suddenly, can't give an exact timeframe or which action triggered it, but a notification popped up that computer should be restarted so that chkdsk could scan the drive for errors, and so I rebooted it.
3. As soon as POST went by, a BSOD appeared "NTFS_FILE_SYSTEM" - image.
4. It restarted itself and again the same BSOD appeared, so I went into bios and booted into the D drive.
5. It booted just fine, but I of course couldn't access the C drive from This PC. (I didn't investigate it further from the system level at that time)
6. I figured it might be an issue with the last Windows Update (?) and it could have corrupted the C file system. I switch the boot to C again.
7. It started doing chkdsk during startup, I waited a little and then cancelled the process by turning off PC with power button (fatal mistake).
8. I again switched to boot from D drive and... the SAME BSOD APPEARED - NTFS_FILE_SYSTEM.
so I thought: Did I just toast my old drive by canceling chkdsk? Why would it? Was it checking the D drive also? (instead of focusing on C).
I checked the registry for BootExecute and it had the following command: autocheck autochk *
So chkdsk most likely was indeed fixing the D drive at the time.
8. I switched again to boot from C drive, and Startup Repair showed up with "repairing disk errors. This might take over an hour to complete". It lasted only 9 seconds (!) after which PC booted just fine! (weird, huh?)
9. So now I'm yet again on the new C drive (which is now good) but with the D drive showing the same ntfs BSOD.
10. I tried forcing the Startup Repair on the D drive in hopes it will get fixed too and it kinda did! It no longer shows the BSOD but instead...

# Background end​

The D drive goes through this Windows loading and just gets stuck on the next Windows loading black screen - image. I left it running on that for the whole night but to no avail. So the D drive can't be booted but can be both seen (NTFS partition and its properties) and accessed (files can be copied).
Showcase images:
This PC
Disk management
I tried uninstalling quality and feature updates but both failed. I did also run DISM & sfc & chkdsk which found nothing wrong (watch out, long):
D:\>DISM /ImageD:\ /cleanup-image /checkhealth ... No component store corruption detected. The operation completed successfully. D:\>SFC /scannow /OFFWINDIR=D:\Windows /OFFBOOTDIR=D:\ Beginning system scan. This process will take some time. Windows Resource Protection did not find any integrity violations. D:\>chkdsk d: The type of the file system is NTFS. WARNING! /F parameter not specified. Running CHKDSK in read-only mode. Stage 1: Examining basic file system structure ... 3216640 file records processed. File verification completed. Phase duration (File record verification): 19.45 seconds. 11447 large file records processed. Phase duration (Orphan file record recovery): 0.00 milliseconds. 0 bad file records processed. Phase duration (Bad file record checking): 0.62 milliseconds. Stage 2: Examining file name linkage ... 8466 reparse records processed. 3927610 index entries processed. Index verification completed. Phase duration (Index verification): 1.57 minutes. 0 unindexed files scanned. Phase duration (Orphan reconnection): 56.94 seconds. 0 unindexed files recovered to lost and found. Phase duration (Orphan recovery to lost and found): 0.25 milliseconds. 8466 reparse records processed. Phase duration (Reparse point and Object ID verification): 22.26 milliseconds. Stage 3: Examining security descriptors ... Security descriptor verification completed. Phase duration (Security descriptor verification): 10.50 milliseconds. 355486 data files processed. Phase duration (Data attribute verification): 0.20 milliseconds. CHKDSK is verifying Usn Journal... 39977824 USN bytes processed. Usn Journal verification completed. Phase duration (USN journal verification): 186.41 milliseconds. Windows has scanned the file system and found no problems. No further action is required. 976098127 KB total disk space. 882420056 KB in 1941907 files. 935612 KB in 355487 indexes. 0 KB in bad sectors. 3354503 KB in use by the system. 65536 KB occupied by the log file. 89387956 KB available on disk. 4096 bytes in each allocation unit. 244024531 total allocation units on disk. 22346989 allocation units available on disk. Total duration: 2.85 minutes (171255 ms).

The only place where I managed to find any indication of an error is... Startup Repair. It fails every time. SRTTrail.txt logs:
... Root cause found: A recently serviced boot binary is corrupt. Repair action: Uninstall latest LCU Result: Failed. Error code = 0x905 Time taken = 4766 ms
and doing dir D:\Windows\servicing\LCU shows:
Directory of D:\Windows\servicing\LCU 16.09.2023 00:18 <DIR> . 16.09.2023 00:18 <DIR> .. 10.05.2023 12:17 <DIR> Package_for_RollupFix~31bf3856ad364e35~amd64~~19041.2965.1.8 0 File(s) 0 bytes 3 Dir(s) 87 091 617 792 bytes free
This message led me to this topic which suggested recreating the Win 10 EFI bootloader. I did that but nothing has changed. It's still stuck on the Windows loading screen.
So my question is: How can I check logs of the Windows Loading black screen? It would be nice to know where it is stuck and why, and then go from there.

I'm also almost 100% certain that I could easily recover all of my files just now (because again, the main partition looks to be healthy and is accessible through C but I would rather try to recover the whole system, especially that it just seems easily repairable.
Secure boot is disabled.

Disk C - Kingston kc3000 2TB
Disk D - Crucial MX500 1TB
Windows 10 Pro 64bit,
AMD ryzen 3600x
RTX 3060 Ti
16 GB Ram
 
Last edited:
I went ahead and manually renamed the `LCU` folder to see if startup repair could go beyond that, but instead, it errored even faster with a new message.
Startup Repair diagnosis and repair log
---------------------------
Number of repair attempts: 1

Session details
---------------------------
System Disk =
Windows directory = C:\Windows
AutoChk Run = 0
Number of root causes = 1

Test Performed:
---------------------------
Name: Check for updates
Result: Completed successfully. Error code = 0x0
Time taken = 0 ms

Test Performed:
---------------------------
Name: System disk test
Result: Completed successfully. Error code = 0x0
Time taken = 0 ms

Root cause found:
---------------------------
A hard disk could not be found. If a hard disk is installed, it is not responding.
 
Run chkdsk with /F switch - from elevated command prompt.
chkdsk /F d:
But when it ran in the read-only mode, it confirmed there were no errors. Yet just to be sure, I did re-run it with the fix flag:
Code:
C:\Windows\system32>chkdsk /F d:
The type of the file system is NTFS.
...
Windows has scanned the file system and found no problems.
No further action is required.
 

TL;DR: My second system drive is 'a little' corrupt: files can be accessed, partition taken/used space information is correct, sectors are good but it just won't boot past Windows loading. Chkdsk, sfc etc. all good. The only error is seen in SRTTrail.txt (Startup repair) logs.​

I now have 2 SSD system drives with Windows 10.
Drive C: (2TB) is new.
Drive D: (1TB) has been in my PC for a 1 year.
They are both good in terms of chkdsk and HD Tune (test for bad sectors).

# Background:

My idea was to install system on the new C, review and copy data I needed from D in the span of few days, and then format D.
But what happened is:
1. I installed the system on C along with the basic software that I need (VcRedist, notepad++, VSCode, Adobe programs etc.) and Windows Updates.
2. Suddenly, can't give an exact timeframe or which action triggered it, but a notification popped up that computer should be restarted so that chkdsk could scan the drive for errors, and so I rebooted it.
3. As soon as POST went by, a BSOD appeared "NTFS_FILE_SYSTEM" - image.
4. It restarted itself and again the same BSOD appeared, so I went into bios and booted into the D drive.
5. It booted just fine, but I of course couldn't access the C drive from This PC. (I didn't investigate it further from the system level at that time)
6. I figured it might be an issue with the last Windows Update (?) and it could have corrupted the C file system. I switch the boot to C again.
7. It started doing chkdsk during startup, I waited a little and then cancelled the process by turning off PC with power button (fatal mistake).
8. I again switched to boot from D drive and... the SAME BSOD APPEARED - NTFS_FILE_SYSTEM.
so I thought: Did I just toast my old drive by canceling chkdsk? Why would it? Was it checking the D drive also? (instead of focusing on C).
I checked the registry for BootExecute and it had the following command: autocheck autochk *
So chkdsk most likely was indeed fixing the D drive at the time.
8. I switched again to boot from C drive, and Startup Repair showed up with "repairing disk errors. This might take over an hour to complete". It lasted only 9 seconds (!) after which PC booted just fine! (weird, huh?)
9. So now I'm yet again on the new C drive (which is now good) but with the D drive showing the same ntfs BSOD.
10. I tried forcing the Startup Repair on the D drive in hopes it will get fixed too and it kinda did! It no longer shows the BSOD but instead...

# Background end​

The D drive goes through this Windows loading and just gets stuck on the next Windows loading black screen - image. I left it running on that for the whole night but to no avail. So the D drive can't be booted but can be both seen (NTFS partition and its properties) and accessed (files can be copied).
Showcase images:
This PC
Disk management
I tried uninstalling quality and feature updates but both failed. I did also run DISM & sfc & chkdsk which found nothing wrong (watch out, long):
D:\>DISM /ImageD:\ /cleanup-image /checkhealth ... No component store corruption detected. The operation completed successfully. D:\>SFC /scannow /OFFWINDIR=D:\Windows /OFFBOOTDIR=D:\ Beginning system scan. This process will take some time. Windows Resource Protection did not find any integrity violations. D:\>chkdsk d: The type of the file system is NTFS. WARNING! /F parameter not specified. Running CHKDSK in read-only mode. Stage 1: Examining basic file system structure ... 3216640 file records processed. File verification completed. Phase duration (File record verification): 19.45 seconds. 11447 large file records processed. Phase duration (Orphan file record recovery): 0.00 milliseconds. 0 bad file records processed. Phase duration (Bad file record checking): 0.62 milliseconds. Stage 2: Examining file name linkage ... 8466 reparse records processed. 3927610 index entries processed. Index verification completed. Phase duration (Index verification): 1.57 minutes. 0 unindexed files scanned. Phase duration (Orphan reconnection): 56.94 seconds. 0 unindexed files recovered to lost and found. Phase duration (Orphan recovery to lost and found): 0.25 milliseconds. 8466 reparse records processed. Phase duration (Reparse point and Object ID verification): 22.26 milliseconds. Stage 3: Examining security descriptors ... Security descriptor verification completed. Phase duration (Security descriptor verification): 10.50 milliseconds. 355486 data files processed. Phase duration (Data attribute verification): 0.20 milliseconds. CHKDSK is verifying Usn Journal... 39977824 USN bytes processed. Usn Journal verification completed. Phase duration (USN journal verification): 186.41 milliseconds. Windows has scanned the file system and found no problems. No further action is required. 976098127 KB total disk space. 882420056 KB in 1941907 files. 935612 KB in 355487 indexes. 0 KB in bad sectors. 3354503 KB in use by the system. 65536 KB occupied by the log file. 89387956 KB available on disk. 4096 bytes in each allocation unit. 244024531 total allocation units on disk. 22346989 allocation units available on disk. Total duration: 2.85 minutes (171255 ms).

The only place where I managed to find any indication of an error is... Startup Repair. It fails every time. SRTTrail.txt logs:
... Root cause found: A recently serviced boot binary is corrupt. Repair action: Uninstall latest LCU Result: Failed. Error code = 0x905 Time taken = 4766 ms
and doing dir D:\Windows\servicing\LCU shows:
Directory of D:\Windows\servicing\LCU 16.09.2023 00:18 <DIR> . 16.09.2023 00:18 <DIR> .. 10.05.2023 12:17 <DIR> Package_for_RollupFix~31bf3856ad364e35~amd64~~19041.2965.1.8 0 File(s) 0 bytes 3 Dir(s) 87 091 617 792 bytes free
This message led me to this topic which suggested recreating the Win 10 EFI bootloader. I did that but nothing has changed. It's still stuck on the Windows loading screen.
So my question is: How can I check logs of the Windows Loading black screen? It would be nice to know where it is stuck and why, and then go from there.

I'm also almost 100% certain that I could easily recover all of my files just now (because again, the main partition looks to be healthy and is accessible through C but I would rather try to recover the whole system, especially that it just seems easily repairable.
Secure boot is disabled.

Disk C - Kingston kc3000 2TB
Disk D - Crucial MX500 1TB
Windows 10 Pro 64bit,
AMD ryzen 3600x
RTX 3060 Ti
16 GB Ram
What has likely happened, is that your D: drive has become dependent upon the boot files and system files in the boot folder. But if the fresh Windows version has "Fast Startup" enabled, then it is locking the partitions on your C: drive. This is just a guess, but "Fast Startup" is enabled by default on Windows 10 and 11. On Windows 10 go to "Settings>System>Power&Sleep" then click the link for "Additional Power Settings" That opens the old style Control Applet, on the left side of that window, click the link for "Choose What the Power Buttons Do" Then at the click the link for "Change Settings that are Currently Unavailable" and remove the Check Mark for "Fast Startup"
Then Reboot your computer for the changes to take hold.
Again, this is just a guess, tho I have had several issues with the "Fast Startup" feature.
Also please keep in mind that when their are multipe bootable Windows partitions in one computer, the booting system will rewrite and take control of system files on the other partition. This why Linux is the preferred troubleshooting and system utility OS.
Good Luck on your issues, don't hesitate let to me know if your have more issues or questions. 🔨🔨
 
I did disable Fast Startup before doing all this, so this by itself does not help in this case. But thanks for your input ❤️
That's great that you disabled it before these issues appeared. Fast Startup is one of the first things I disable on all new computers and fresh installs. In the age of SSD drives, that feature causes more issues than it fixes.
Whoever thought it was a good idea to lock the Fast Startup feature behind a link labeled "Choose What your Power Button Does" should be beat with a Pool Noodle till they admit it was a dumb idea!
If you really need that 2nd drive to be bootable, you could likely do a successful boot repair with with Windows install media, but should disconnect or disable the C: drive first.
🔨
 
Which repair method do you mean exactly? I tried a lot (as mentioned in the OP post).
As a part of my KISS (keep it stupid simple) rule, once the good drive is removed from the system, whether disconnected or disabled in BIOS. First to try would be the "Repair My Computer" option available when booted from Windows install media. If that doesn't work, the next option would be to use the command line option for BCDedit and or BOOTREC. This page explains better than I can.
I do realize you have done some of this already, but by not having multiple boot drives in the system, these tools may manage to correct the boot issue.
This of course, is just my semi-uneducated guess. Your ideas, opinions and actions are all valuable learning tools for all us. Keep us informed on what works and doesn't work!
If all else fails, I have a Hammer and know how to use it!
🔨
 
As a part of my KISS (keep it stupid simple) rule, once the good drive is removed from the system, whether disconnected or disabled in BIOS. First to try would be the "Repair My Computer" option available when booted from Windows install media. If that doesn't work, the next option would be to use the command line option for BCDedit and or BOOTREC. This page explains better than I can.
I do realize you have done some of this already, but by not having multiple boot drives in the system, these tools may manage to correct the boot issue.
This of course, is just my semi-uneducated guess. Your ideas, opinions and actions are all valuable learning tools for all us. Keep us informed on what works and doesn't work!
If all else fails, I have a Hammer and know how to use it!
🔨
I did indeed do that already, and with the D drive being the only one plugged in. C drive was not connected during that.
 
I copied all my data so I can be more 'aggressive' with my actions from now on. I need to know what exactly caused the D drive to screw it up so badly
 
Status
Not open for further replies.