0

I have a dell Inspiron 3542 with 8gb memory I have installed windows 10 up to build 1909 many times from bootable USB using Rufus on my laptop but one day I stopped my laptop while installing windows because it's taking too long as it generally takes. from that situation, I can't able to boot windows 10 from USB. I am using UEFI boot with GPT. I restored bios many times and installed a bios update. but strangely it booting kali and Linux mint and other Linux distros and also unofficial windows 10 Alienware os also working but the original os file is not booting it and showing black screen a while with hyphen not blinking at the left top corner of the screen I tried legacy and UEFI but didn't work and I used Rufus, windows media creation tool and many.

still, I don't know why Windows 10 Alienware iso booting and installing.

I found something that may be useful

Trail-1 I created bootable USB using that windows 10 Alienware iso and I changed sources folder I replaced that with windows 10 2004 iso sources folder now its also not booting.

Trail-2 all files I kept as in Windows 10 Alienware iso but only "install.wim" file I replaced with windows 10 2004 iso in USB stick now its booting and installed the latest build no custom effects noting now it's fine but I don't know why that booting original iso's not.

and I tried with both NTFS and fat32 USB as I converted "install.swm" files for fat32 to make the size below 4gb but nothing helped. same issue

that windows 10 Alienware iso is 1903 build and for that, I also tried the original windows 10 1903 iso but the same black screen.

I also tested that bootable USB in another laptop (hp) same UEFI but it is booting fine

enter image description here

enter image description here

enter image description here

Ramhound
  • 44,080

1 Answers1

0

A black screen before anything (graphical or even textual) is loaded is as bad as you can get probably, but you can still fight your way out if you know an older OS version worked and you use it as a reference point.

Trail-1 means we can exclude the few pre-actual-boot components, so I would just focus on boot.wim (the very next thing that gets loaded, responsible for all the preinstallation environment). In turn, rather than using the full ISO one, I'd recommend you to work on its corresponding 32-bit WinPE release. It is way smaller, and it only has a single volume image.. meaning that you can just use 7-Zip to tinker with its content (I suppose flat boot is also a possibility, but DISM always seemed to glitch for me).

Now for the real challenge, you have to bisect. Meaning you need to mix and mash together a bunch of files at a time from the broken Windows version WIM to the old functioning one until it breaks the way you are used to (or the other way around I guess).

If you could not even boot the slightest, you'd probably start with the whole Windows folder, then just System32, and eventually some of the stuff inside (some good candidates here). Once you start meddle in there.. BSODs start to become a common occurrence, but in this case they would still be a step forward compared to "nothing at all" (take note that when you touch the second-stage bootloader found in the Boot subfolder, that should always match with ntoskrnl.exe, hal*.dll and pshed.dll).

Last but not least, once you have eventually found and circumscribed the culprit, if you want to apply any change to the original setup archives I'd use DISMGUI to mount them and a run-as TrustedInstaller cmd to copy, delete or overwrite whatever required file (don't forget to replicate the modification for both WIM indexes). And you are done. Probably even ready to report Microsoft back of such and such bug if it still applied to the latest Windows version.

By the way, I'd also recommend you to use bcdedit to enable all boot logging/display options, and disable all the integrity checks for your boot media while doing all these tricks. Failures are far more granular and verbose this way (I also found some good suggestion about using a debugger while writing this post, but the difficulty involved is quite higher arguably).

mirh
  • 1,172