This is my second question regarding my case of a non-booting Windows 10, but with a different focus this time. As a reminder:
Since something(TM) happened with my laptop (Dell Latitude E6440) yesterday (I suspect a Windows Update, but who knows), my Windows 10 Pro installation (17134.1, if that matters) does not boot any longer. Basically, during bootup I saw only a Dell logo indefinitely, with nothing else happening beside some initial hard disk activity.
I have ruled out the Windows Boot Manager as a root cause, not least by installing the same version of Windows 10 on a second partition, managed by the same one EFI boot manager. [There seems to be no way to upgrade/in-place-install over an existing, non-booting Windows installation and keep apps installed, so this is not my preferred solution. I would like to repair the broken one.] The boot menu works fine with all configured options, it's just that I cannot boot one of the two Windows installations. Despite corresponding BCD configuration, a %WINDIR%\Ntbtlog.txt log file is not written, so I suspect that the boot sequence fails very early on (that is, even before ntoskrnl.exe is loaded.) I thought that maybe the Windows Boot Loader of that installation was broken.
So I started to look for differences between the respective files. I made sure the BCD looks the same except for additional logging and debugging options:
Windows Boot Loader
-------------------
identifier {the-working-one}
device partition=C:
path \WINDOWS\system32\winload.efi
description Windows 10
locale en-US
inherit {bootloadersettings}
recoverysequence {uid1}
displaymessageoverride Recovery
recoveryenabled Yes
isolatedcontext Yes
flightsigning Yes
allowedinmemorysettings 0x15000075
osdevice partition=C:
systemroot \WINDOWS
resumeobject {uid2}
nx OptIn
bootmenupolicy Standard
Windows Boot Loader
-------------------
identifier {non-working-one}
device partition=D:
path \Windows\system32\winload.efi
description Windows 10-1
locale en-US
inherit {bootloadersettings}
recoverysequence {uid3}
displaymessageoverride Recovery
recoveryenabled Yes
isolatedcontext Yes
flightsigning Yes
allowedinmemorysettings 0x15000075
osdevice partition=D:
systemroot \Windows
nx OptIn
bootmenupolicy Standard
bootstatuspolicy DisplayAllFailures
bootlog Yes
sos Yes
Then I continued by comparing files that I suspect have something to do with booting - but everything that I have tested so far is identical, too:
C:\Windows\Boot\* == D:\Windows\Boot\* (recursive)
C:\Windows\System32\*boot*.* == D:\Windows\System32\*boot*.*
C:\Windows\System32\*bcd*.* == D:\Windows\System32\*bcd*.*
C:\Windows\System32\*winload*.* == D:\Windows\System32\*winload.*
C:\Windows\System32\Boot\* == D:\Windows\System32\Boot\* (recursive)
What am I missing? What are other relevant boot components of Windows 10 that I could compare? Is there another way to isolate the relevant differences between the two installations that might allow me to copy over part from the-working-one to the non-working-one?
Two additional pieces of information that might help point into the right direction:
During recovery with just the non-working Windows installation, "bootrec /fixboot" also exited with "Access denied", but I could not figure out which access was denied. I am not really eager to try this command out now, not knowing what it does exactly.
D:\Windows\System32\LogFiles\Srt\SrtTrail.txt(the log file for start-up repair, run during Windows Recovery as well) contains this line;
Boot critical file d:\efi\microsoft\boot\resources\custom\bootres.dll is corrupt.
I have no idea why a custom bootres.dll might be required, I don't have that anywhere. Where might this be registered? Interestingly, the only place I can find part of this error message are these two threads, which relate to the 17133.73 (from 17133.1, I assume) update. I had indeed installed that update (successfully) after I had installed a clean 17133.1, but the subsequent clean update to 17134.1 went smoothly as far as I can tell. Still, I wonder whether this might indicate any left-overs from problems related to Microsoft pulling 17133 as an RTM build (e.g., in the EFI NVRAM).
- The logos for the two entries in the Windows Boot Manager, when using the graphical versions, are different. So there must be a difference at the level of the Windows Boot Manager (or the Loaders) still:
I find it not too far off to hypothesize that the custom\bootres.dll issue above and the boot manager logo issue here are closely related. (Related question: Can I change the icon of a Windows Boot Entry?) What I don't get (yet) is why the Boot Manager thinks this entry needs custom resources at all.
