Debugging My PC Which Hangs on a Black Display Prior to the Login Screen

Thanks so much!

Though out of curiosity and so that I can solve these problems in the future, how were you able to get those files?

To me, the files seemed pretty critical and would have been part of the windows image file that I tried to use as a source. Were the files not in this wim file or is DISM really bad at pulling source files from wim files? Or was I just stuffing it up lol.
 
Ah ok that makes sense, I guess the way I ended up getting the files for my win11 OS was similar. Cheers I'll check that article out.

The win10 install works!!!!!! I ran /restorehealth with the files you provided and then scannow, they both completed without an issue.

This is the most progress I've made on this issue in weeks haha. Thanks again for providing the files I need!

One OS down, one to go
 
I'll let you know if I'm able to fix it, but I think I'm all out of options at the moment. It didn't respond to any of the /restorehealth or scannow actions, so I think we're in miracle territory now
 
Yeah, all have been checked for sequence number issues and repaired, though booting with them causes the numbers to not match again. All except the SOFTWARE hive actually this time. Can doing a forced shutdown with the power button do this to a hive?

I'm currently also looking at the processes loaded during the boot through the debugger. I noticed that when the system reaches the black screen it has only loaded up to the winlogon.exe process. LogonUI.exe is apparently next to load and is triggered by winlogon.exe, but it doesn't load. The problem then might be with winlogon.exe so I have been looking at its registry entry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon. Do you have an idea of what I should be looking for here, or of particular entries that could cause a problem?
 
Yes, forced shutdowns are definitely the cause of corrupted hives because the system couldn't unload the hive's and write them correctly to the system drive which may result in uncommitted data.

Please provide an export of the key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon.

My first thought is that explorer could not be loaded, as proof of concept we can try to change the "shell" value for explorer.exe with cmd.exe to see if it will load into the black screen with curser.
 
Thanks for the export, I will try some things on a Windows 11 VM here. Because I've never used the CMD.exe 'tweak' on Windows 11 machine to bypass the regular GUI.
 
It seems the CMD 'tweak' is not working in this case because 'cmd.exe' will be loaded after 'winlogon.exe', however we can try something else.

WARNING! No one else should follow these instructions as it may cause more harm than good if you don't have recent backups of the system.

1. Download NativeShell from Github: Releases · amdf/NativeShell
2. Unzip the file and copy native.exe to %systemroot%\system32\
3. Load the SYSTEM hive into the recovery environment and import add.reg (from the package) to create the following 'BootExecute' entry'.

Rich (BB code): 
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager]
"BootExecute"=hex(7):61,75,74,6f,63,68,65,63,6b,20,61,75,74,6f,63,68,6b,20,2a,\
  00,6e,61,74,69,76,65,20,48,65,6c,6c,6f,20,57,6f,72,6c,64,21,00,00

Rich (BB code): 
BootExecute: autocheck autochk * native Hello World!

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
    BootExecute    REG_MULTI_SZ    autocheck autochk *\0native Hello World!

This entry will load native.exe before the winlogon session, if this works it must be something in the SOFTWARE or SYSTEM hive related to the 'BootExecute' or 'BootShell' value.
 
Ok so I followed the steps as closely as I could but native.exe did not load. What I did was:
  • Downloaded, unzipped and copied native.exe into the \system32 folder of the broken win11.
  • From within my working win11, I loaded the SYSTEM hive of the broken win11 into regedit, but I couldn't get add.reg to import into that hive.
  • Instead, I imported add.reg into the working win11 SYSTEM hive and then copied the BootExecute: value "autocheck autochk * native Hello World!", into the same key of the broken win11 SYSTEM hive. As "currentcontrolset" was not present in the offline broken win11 hive, I instead copied the value to the bootexecute key under the ControlSet001 path (\SYSTEM\ControlSet001\Control\Session Manager). I assume that this is the same thing?
When I rebooted into the broken win11, native.exe did not load and the boot process failed at a black screen like it normally does. I attempted it again with the debugger attached and after a quick look I couldn't see any indication of native.exe running.

I then tried the same process as above on the working win11. This time native.exe did appear to run early in the startup sequence, I was presented with a command line interface but was not able to interact with it.
 
Sorry that statement that you quoted wasn't very clear, what I meant was that I was able to get /restorehealth and scannow to complete successfully on the win11 disk. They fixed about 50 corrupted files, but it didn't have an effect on the system's ability to boot. I've run chkdsk in the past, which completed successfully but I thought I'd run it again since you mentioned it. This time it looks to have fixed some minor issues which I don't think it did before. I didn't fix my problem but just in case it's useful, its output is below.

C:\Windows\System32>chkdsk d: /f
The type of the file system is NTFS.
Volume label is Samsung 990 Pro 2TB.

Stage 1: Examining basic file system structure ...
927744 file records processed.
File verification completed.
Phase duration (File record verification): 4.81 seconds.
26038 large file records processed.
Phase duration (Orphan file record recovery): 11.35 milliseconds.
0 bad file records processed.
Phase duration (Bad file record checking): 0.34 milliseconds.

Stage 2: Examining file name linkage ...
11828 reparse records processed.
CHKDSK discovered free space marked as allocated in the bitmap for index $I30 for file 1F6D1.
CHKDSK discovered free space marked as allocated in the bitmap for index $I30 for file 21E3A.
1202338 index entries processed.
Index verification completed.
Phase duration (Index verification): 12.04 seconds.
CHKDSK is scanning unindexed files for reconnect to their original directory.
Correcting minor file name errors in file 37.
Recovering orphaned file LOGNVC~1.LOG (7D9C) into directory file 6538.
Correcting minor file name errors in file 31C13.
Recovering orphaned file ASA644~1.LOG (BC1A9) into directory file 21E3A.
Recovering orphaned file ASA733~1.LOG (C5523) into directory file 21E3A.
Recovering orphaned file BI9000~2.LOG (C5526) into directory file 1F6D1.
7 unindexed files scanned.
Correcting minor file name errors in file C76ED.
7 unindexed files recovered to original directory.
Phase duration (Orphan reconnection): 1.29 seconds.
0 unindexed files recovered to lost and found.
Phase duration (Orphan recovery to lost and found): 5.32 milliseconds.
11828 reparse records processed.
Phase duration (Reparse point and Object ID verification): 21.00 milliseconds.

Stage 3: Examining security descriptors ...
Security descriptor verification completed.
Phase duration (Security descriptor verification): 31.30 milliseconds.
137298 data files processed.
Phase duration (Data attribute verification): 0.38 milliseconds.
CHKDSK is verifying Usn Journal...
Usn Journal verification completed.
CHKDSK discovered free space marked as allocated in the
master file table (MFT) bitmap.
CHKDSK discovered free space marked as allocated in the volume bitmap.

Windows has made corrections to the file system.
No further action is required.

1847810047 KB total disk space.
1562389932 KB in 659649 files.
448920 KB in 137299 indexes.
0 KB in bad sectors.
1067599 KB in use by the system.
65536 KB occupied by the log file.
283903596 KB available on disk.

4096 bytes in each allocation unit.
461952511 total allocation units on disk.
70975899 allocation units available on disk.
Total duration: 18.27 seconds (18274 ms).
 
Last edited:
Okay, is the key combination CTRL + SHIFT + ESC working when the black screen appears to open the task manager?
 
Are you able to boot in safe mode with CMD using the Windows 11 ISO?

Follow these steps to enter Safe Mode from the Winddows Recovery Environment:
  1. Click Choose an option, and select Troubleshoot.
  2. When the Troubleshoot screen opens, select Advanced Options and select Advanced Startup Options.
  3. Select Startup Settings and Restart.
  4. The system will now reboot and open the Startup Settings menu. Select option 6 to start the system in Safe Mode with CMD.
 
I'm really out of ideas now, normally, different operating systems on the same hardware and different drivers shouldn't be a problem when you use the Bios Boot Selector instead of an (third party) boot loader! Since the tweak with NativeShell isn't working either I don't know what else we can try to resolve this issue....
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!


Write your reply...
Back
Top