Redmond.. We have a problem !!!

After updating to Build 26200.8655, I ran check script by revolutionist @garlin, I had some anomalies in Windows installation. I had posted them here in the following thread.


I tried to correct the anomalies using options from check script output but I couldn't correct Winload.efi's version problem. The following is the situation I am in now.



As can be seen from the screenshot above, Winload.efi file is reported as blocked.

Fortunately, Windows was still booting properly. I love Microsoft...

I used Powerrun, which was advised by @garlin when I had a similar problem in an earlier Tuesday patch, to correct version problem of Winload.efi.

Unfortunately, Powerrun was not able to replace the Winload.efi file in System32 folder with the one with correct properties in WinSxS folder. The following screenshot shows file version of Winload.efi in WinSxS folder. It is correctly correct.



Therefore, I wanted to take chances to make a Repair install from Windows Settings in order to see if things would go the proper way.

This below output is from after the Repair install was over.



I was unlucky. Windows has not been repaired after hard work and no play.

I do hope that this will be the last time I spend hours in vain to try to repair what Microsoft seems to have broken.

Or am I cursed ???

What version of the script are you running? Re-download it, because you probably have an old version which checks ProductVersion instead of FileVersionRaw. It's still in pre-release, because I paused work on it in May to focus on bug fixes for the Secure Boot scripts.

garlin said:

What version of the script are you running? Re-download it, because you probably have an old version which checks ProductVersion instead of FileVersionRaw. It's still in pre-release, because I paused work on it in May to focus on bug fixes for the Secure Boot scripts.

Click to expand...

I downloaded the script this morning. It must be the most recent one. The check script is dated 08 June.

The strange thing is, the HP notebook PC does not have this problem. Its install language is en-GB. The one with the problem is tr-TR, the Asus desktop PC.

Download it again, I put a newer version on the other thread a half hour ago.

The result has changed now after downloading BlockedOrNot script a minute ago.



But this time I cannot read winload.efi file info. It yields an error ".VersionInfo was unexpected at this time." Whatever that means.

Something to note: Winre.wim position has changed from "Volume number 10" to "Partition 5".

Volume 10 points to the other Windows installation, which I have not yet updated to June patch.

Partition 5 points to the correct WinRE partition. But my problem was Winload.efi file being blocked.

So it seems my desktop PC is badly broken but works without a hitch. Which OS boots to which partition or volume, I am not sure. They were once dual-boot but now separated.

Anyway, thanks for your help.

please try rebuilding your BCD/EFI
this link is for Windows 10 but applies to Windows 11 also
i used this to bypass MS requirements to install Windows 11 in VM on Linux

there is also another way using a live Linux USB and swapping the BOOT/EFI contents from your good computer over to your BOOT/EFI partition on the computer that is not working. i will give details about that after you have tried rebuilding the BCD/EFI. if you require it.

best of luck Steve ..

@XxXxX Thanks for your input. My PC, which is incompatible with Win 11 requirements, runs perfectly. I encounter no problems unless I deliberately look for one.

For test purposes, I have disabled all other physical drives in the PC and left only the Windows drive with a separate data partition. I will observe for some time how it goes along before I apply radical changes software-wise.

I will keep your advice in mind and execute it when conditions are met.

Thanks again.

$env:windir is an environment variable. By itself, it returns a value.

If you use it as part of a pathname, PS requires you to use double-quotes to allow the variable to expand its value inside the string expression.

The issue with the new version is certainly not universal. I ran the @garlin check script and it correctly found that the SVN was out of date. I ran the suggested commands and updated the files and all's well again.

@garlin I was using the command without quotes before for good result. But whatever happened in my PC, it did not run. So both commands, the one without the quotes and the one with quotes run fine now without any error.



What I did was, I disabled all other drives in BIOS. Windows took a long time to boot up and eventually it booted up. Most probably, it found the real EFI partition to boot to. Now all is well, it seems.

My PC was also running fine with all other drives enabled but probably, Windows was booting to boot files on another drive. It might be no problem to someone else but not to me. I like to fiddle with the PC and to quarrel with it.

@garlin I think this Winload.efi file anomaly I am experiencing when I use "BlockedOrNot.ps1" script happens when I get preview update and then patch Tuesday update afterwards. Because both files have the same FileVersionRaw versions, they are not replaced when patch Tuesday update is installed. So BlockedOrNot.ps1 script gets confused. The Winload.efi file in System32 directory has both preview build version and new version in its file attributes whereas the Winload.efi file in WinSxS directory has the correct version all over in its file attributes.

This screenshot below shows Winload.efi file attributes in System32 directory. It has both versions 8655 and 8457. This file must have been put there when I got the preview update in advance.



This screenshot below shows Winload.efi file attributes in WinSxS directory. It has only one versions 8655 all over in its file attributes. This file must have been put there during patch Tuesday update.



There must be a reason why Microsoft does not replace this file in System32 directory when patch Tuesday update is installed along with WinSxS directory.

Therefore, depending on when I use BlockedOrNot.ps1 script, I get confusing messages.

Maybe my logic is not correct ?

1. Windows updates work on the Component-Based Servicing (CBS) model. Individual Windows features are broken down into components which may include an entire feature, or just a subset of the feature. It's designed for modularity, so that one component may be changed and leaves other untouched components alone.

2. An update package contains a group of newer replacement components intended to replace previous, older components. Because Windows updates are mostly cumulative, every new update should have the same components as the last update if those components haven't changed since then. Some components in a KB may be very old, and other components may be very new. It depends on what needed to get patched.

They don't renumber older components just because the KB has a higher build number.

3. Preview Updates and the following Monthly Update mostly overlap. That's the whole point of the Preview, which allows users (mostly IT admins and devs) to test a new update for backwards compatibility. Does this Preview break my software? So installing the Monthly after a Preview doesn't require the included components to change. In fact, most of the new components first arrive in the Preview.

Have you read the release notes on the W11 Updates History page? Usually the details on new Windows features are only listed on the Preview Updates, and not on the Monthly. The only thing a Preview Update cannot have are security fixes, they're reserved only for the Monthly Update (Patch Tuesday rules for security disclosure) or an Out-of-Band (Emergency) Update.

4. As stated in another thread, there are different "versions" reported depending on what is the reason for knowing the version. Why is W11 reported as 10.0.2xxxxx.yyyy? This implies every W11 build is supposed to be W10 (10.0). It's done for compatibility reasons.

There are legitimate reasons to pretend your build/version number is something else, because other programs depend on this knowledge. As SkuSiPolicy is a MS security tool, obviously MS knows how to correctly determine what version detail they will be using for policy enforcement.

All my script needs to do is to match the same version info as used by Core Integrity.

If you want to see which component folder is currently being used: