Cool Tools, Insider stuff, PowerShell, Recent Activity, Secure Boot, WED Blog, Windows 11

Fixing Macrium Rescue Disk

Leave a comment

Microsoft updated its Secure Boot revocation database (DBX) in mid-2026. That update requires Boot Manager binaries to carry a minimum Security Version Number (SVN) of 11.0. It also bans the older “Production PCA 2011” signing certificate. Rescue media that Macrium Reflect X builds fails both tests out of the box. That means with Secure Boot enabled, the Reflect’s boot media won’t work. That’s why I’m writing today about what’s involved in fixing Macrium Rescue Disk.

Most important, this post walks you through a PowerShell script named fixmrrd.ps1 that fixes all three BANNED files in a single pass. Buckle up! There’s LOTS of ground to cover…

Why Fixing Macrium Rescue Disk Is Necessary

Macrium Reflect X builds its WinPE rescue environment from the Windows ADK (Assessment and Deployment Kit). The ADK ships once per Windows release and never gets Patch Tuesday updates. Its boot files stay frozen at the SVN level they carried on release day.

For Windows 11 24H2, the WADK 11 ADK shipped with boot files at SVN 2.0. The current DBX floor is SVN 11.0. That nine-version gap is the core problem that requires fixing.

The standard boot manager file, aka bootmgfw.efi that lives under C:\Windows\Boot\EFI\ also carries the banned Production PCA 2011 certificate. Even when the SVN is correct, that certificate triggers a hard BANNED result. Garlin’s check_bootMedia.ps1 diagnostic tool makes both problems visible immediately.

Introducing fixmrrd.ps1

fixmrrd.ps1 bridges the gap Macrium leaves open. It pulls every replacement file from your live, fully patched Windows 11 installation. Those files already meet the SVN 11.0 requirement and carry the correct Windows UEFI CA 2023 certificate.

Here is what the script does at each step:

  1. Validates the target USB drive and confirms it carries a MACRIUM label.
  2. Locates boot.wim on the rescue media, typically at sources\boot.wim.
  3. Identifies three source files from your live Windows installation: bootmgfw.efi, bootmgfw_EX.efi, and winload.efi. It reports the version number of each file.
  4. Replaces the external bootmgfw.efi on the USB EFI partition. It uses the EX variant (bootmgfw_EX.efi) as the source — not the standard bootmgfw.efi. The standard file carries the banned Production PCA 2011 certificate. The EX variant carries the required Windows UEFI CA 2023 certificate.
  5. Mounts boot.wim using DISM. Then it adjusts ACLs on the internal target files. WIM images lock their contents with restrictive ACLs. Even Administrator hits an access-denied error without a takeown and icacls step first.
  6. Replaces bootmgfw_EX.efi and winload.efi inside the mounted WIM.
  7. Commits the changes and unmounts the WIM. If any step fails, DISM discards the mount and leaves the original WIM intact.

The script backs up every replaced file with a timestamped .bak_ suffix before touching it. Color-coded [OK], [!!], and [FAIL] status lines show progress at each step.

Before You Run the Script…

There are four prerequisites apply before you run fixmrrd.ps1.

  • Run as Administrator. DISM mount operations require elevation.
  • Use Windows PowerShell 5.1 (powershell.exe). Do NOT use PowerShell 7.x (pwsh.exe). The DISM /Mount-Image command does not work correctly under PowerShell Core. The script detects PS 7.x automatically and exits with a clear message if you start it from the wrong shell.
  • Your Macrium rescue USB must be plugged in and assigned a drive letter. Note that letter before you start.
  • Your execution policy must allow local scripts. Run this in an elevated PS 5.1 window if needed:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Download fixmrrd.txt from its OneDrive link (read only). Rename it to fixmrrd.ps1. Place it in a convenient location, such as C:\tools\scripts\.

Running the Script…

Open an elevated Windows PowerShell 5.1 window. Navigate to the folder holding fixmrrd.ps1. Then run:

.\fixmrrd.ps1 -TargetDrive G:

Substitute your actual rescue drive letter for G:. If you omit -TargetDrive, the script prompts you for it.

The script runs without further interaction. The DISM commit step takes the longest — typically 30 to 60 seconds. Do not interrupt that step.

Each replaced file gets a timestamped .bak_ backup before the script writes anything new. You can restore any original file by renaming the matching backup.

One timing note: the script reports source file versions from C:\Windows\Boot\EFI\ and C:\Windows\Boot\EFI_EX\. You may notice the version number on the USB after copy differs slightly from what the script reported. This is a FAT32 metadata quirk. The SVN level is what really matters, and transfers correctly.

Verifying Results

Run Garlin’s check_bootMedia.ps1 against the drive when the script finishes:

.\check_bootMedia.ps1 G: -audit -verbose

A correctly fixed drive shows all three boot files as ALLOWED:

USB Drive g: "MACRIUM_PE"
    Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.
        g:\EFI\Microsoft\Boot\bootmgfw.efi
        File Version: 28000.367, SVN 11.0

    boot.wim:1 (WinPE 26100.1)
        Boot Manager [Windows UEFI CA 2023] is ALLOWED.
            \Windows\Boot\EFI_EX\bootmgfw_EX.efi
            File version: 28000.367, SVN 11.0

    \Windows\System32\winload.efi is ALLOWED.
        File version: 26100.9444

If any file still shows BANNED, check that you ran the script in PowerShell 5.1 with elevation. Re-run if needed — the backup files let you roll back safely.

The Net-Net: Working Rescue Disk

This is a product gap in Macrium Reflect X, not a user error. Macrium builds from ADK components that Microsoft does not update through Patch Tuesday. The recoverydrive.exe tool that ships with Windows sources its boot files directly from the live OS. Macrium does not. Until Macrium ships a fix that closes that gap, fixmrrd.ps1 fills it. It ticks me off, and that’s why I decided to script my way around it.

Keep this script on hand. The next time you rebuild a Macrium rescue drive, perhaps after a major Windows update or a new ADK release, you will need it again. The whole process takes under two minutes once you know the steps. Here in Windows-World, when vendors don’t fix their stuff, we users must sometimes step in to help out. Cheers!


Facebooklinkedin
Facebooklinkedin	

	
	




	
	

			
	

				

			Cool Tools, Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11
		

			
In-app Update Beats Remove/Replace

		

			 			Leave a comment
						

	


		

		
Running WinGet just now on my Flo6 desktop, I got reminded that installer changes sometimes stymie its update facilities. If you look at the lead-in graphic, you’ll see that one upgrade gets blocked because of “different install technology.” Winget goes onto recommend “Uninstall each package, then install the newer version.” Not so fast: IMO, an in-app update beats remove/replace when that’s an option. I’ll explain, and use the Edge browser as an illustration.




You can jump to Edge, click the ellipsis, and get to Help and feedback in 3 clicks. Uninstall/reinstall takes 20+ keystrokes, and might fail.


Why Say: In-app Update Beats Remove/Replace?


My explanation boils down to: less time and effort, fewer keystrokes involved. Jumping to Edge, clicking the ellipsis for Settings, then visiting Help and Feedback to prompt the update process takes 3 mouse clicks (add one more click to restart, and the update is done). Uninstalling, then re-installing edge takes at least 20 keystrokes (“winget uninstall edge”). Worse, it then falls victim to exit code 93. TLDR version: Edge is considered a Windows built-in feature, so it blocks its own uninstall by default.


Sure, you can work around this. And it works for other browsers as directed for Chrome, Firefox, and so forth. But my preferred approach for browsers in particular is: try the built-in update mechanism first, if WinGet steers around an update. It usually does so for a good reason, as is the case here with Edge.


Here in Windows-World, it pays to recognize such cul-de-sacs when they pop up. It saves you the time involved in driving to the end, turning around, and doing something else. Not an unfamiliar experience for Windows warriors, but one best avoided when possible!

Facebooklinkedin
Facebooklinkedin	

	
	




	
	

			
	

				

			Cool Tools, Insider stuff, Recent Activity, Secure Boot, WED Blog, Windows 11
		

			
Post Patch Tuesday Secure Boot Cleanup

		

			 			Leave a comment
						

	


		

		
September’s Patch Tuesday landed on 9/8. And it brought more than the usual security fixes. KB5124008 and KB5124012 quietly expanded device targeting for Microsoft’s ongoing Secure Boot trust chain. If you haven’t verified your machines yet, now is the time. Secure Boot cleanup is not optional — it is essential maintenance for every managed Windows environment. Indeed, I’d argue that a routine post Patch Tuesday Secure Boot checkup is part of a “new normal” for Windows, with a cleanup to follow if needed.


Why Do a Post Patch Tuesday Secure Boot Check?


Here is the backstory. The old Microsoft UEFI CA certificates that were issued back in 2011, expired in June 2026. Microsoft has been rolling out replacement 2023 certificates through Windows Update for months. September’s updates expanded that rollout further.


KB5124008 and KB5124012 added more “high confidence” device targeting data. That means more PCs are now eligible to receive the new certs automatically. However, some devices still fall through the cracks.


Don’t panic. Devices that haven’t received the new certificates will still boot. Standard Windows updates will still install. But the clock is ticking. A second major deadline arrives in October 2026. You don’t want to be scrambling then.




Why It Matters


Devices that miss the Secure Boot cleanup lose future boot-level security protections. Over time, they become progressively more exposed to boot-level threats. These are the kind that load before Windows even starts. Also, BitLocker and device encryption may break on out-of-synch systems. That means recovery key prompts, startup hangs, and frustrated users calling the help desk.


Running the Garlin Remediation


Garlin is a long-time, high-status (and value) member of the online community for ElevenForum.com. He’s been stewarding a long-running thread (now at 188 pages) entitled “garlin’s PowerShell scripts for updating Secure Boot CA 2023” since January 2025. He’s got scripts to handle certificate synch-ups, with all the related DB and DBX fixes to boot (pun intended). Just remember to visit his GitHub site regularly to download the latest ZIP file with scripts to match (his latest update on 9/8 handles the newest Patch Tuesday updates).


As you can see in the lead-in screenshot, after the update Windows incremented SkuSiPolicy.p7b from version 3.0.0.17 to 3.0.0.18. It also updates the Secure Version Variable (SVN) stored in NVM in firmware as part of Secure Boot’s DBX values. After the OS update, certain operations are need to catch the UEFI up with the OS.


Actual Remediation : SkuSiPolicy.p7b


The SkuSiPolicy.p7b value governs which Windows editions (aka “SKUs” such as Home, Pro, Education, etc.) that Secure Boot regards as trusted and bootable. If the policy in the OS and the policy in a boot structure (whether in EFI, on disk, or on bootable media) don’t match, you get “Secure Boot Violation” when you try to boot and nothing more. Not good!


No worries. Garlin’s got a fix for that. If you run his latest Update UEFI script with the right argument it will fix it for you (reboot required). Here’s the syntax:


Update_UEFI-CA2023.ps1 -SkuSiPolicy


If you’re running this in an admin PowerShell session, prepend “.\” (period-backslash) to get it to run. Tip: if you unblock the ZIP file after downloading it from GitHub, the archive’s content will also be unblocked. Otherwise, you’ll end up unblocking them piecemeal. I speak from direct experience on this…


Actual Remediation: SVN


The Secure Version Number (acronym: SVN) is a monotonically increasing integer value also stored in the UEFI DBX value. It provides anti-rollback enforcement. When a bootloader or boot manager tries to loan, UEFI checks its built-in SVN against the minimum SVN stored in firmware. If the boot agent SVN is lower than what’s in UEFI, UEFI won’t load it. Here again, it’s necessary for what’s in the OS and what in the bootloader to agree. After an update (like Patch Tuesday) remediation may be needed.


Here’s what that looks like in PowerShell (admin):



manage-bde -Protectors -Disable C: -RebootCount 1




reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x200 /f




powershell Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"



The first line turns off BitLocker for the next boot to avoid key lookup and entry. It’s only needed for PCs whose C: drive is BitLocker protected. The next line adds a registry key to define and schedule a Secure Boot update task to update the SVN. The third line calls powershell to run that scheduled task immediately. All this stuff shows up in the output of the Garlin check script if you run it properly, so you can copy it from there, right inside PowerShell.


Here’s that syntax:

check_uEFI-CA2023.ps1 -verbose -audit


Don’t forget to prepend the “.\” (period backslash) to run it in PS.


Also: Boot Media Needs Catchup, Too


Here is a step that many admins overlook. Your Windows installation USB drives and WinPE recovery media also need attention. For sure, any media created before January 2025 won’t include the new 2023 Secure Boot certificates. I’ve gotten in the habit of rebuilding boot media each time that SkuSiPolicy.p7b or the SVN increments myself.


What happens if you don’t build new boot media? They may fail to launch on a fully updated machine. Rebuild everything from the latest Windows ADK, MCT (Media Creation Tool), or a current Windows ISO. Then test the rebuilt media on at least one device before you rely on it to get something done.


Run through this quick checklist before you close this task out:


    

  • ☑ Rebuild WinPE USB from the latest ADK
    • 

  • ☑ Rebuild Windows installation USB from a current ISO
    • 

  • ☑ Update MDT and WDS boot images if applicable
    • 

  • ☑ Test rebuilt media on a pilot device before wide deployment
    • 

  • ☑ Document any devices that cannot update (unsupported hardware) as formal exceptions
    • 



This is a new and interesting wrinkle on dealing with Windows Updates, especially around the Patch Tuesday milestone. Here in Windows-World such wrinkles accumulate. Don’t let them put your PCs and boot media in peril. Do the necessary, please!



Facebooklinkedin
Facebooklinkedin	

	
	




	
	

			
	

				

			Cool Tools, Device drivers, Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11
		

			
Fixing False Vantage Update

		

			 			Leave a comment
						

	


		

		
If you’ve ever dealt with a Lenovo Vantage false update, you know how maddening it gets. That goes double, when every install attempt fails silently and the same ghost package reappears on every subsequent scan. Sigh.


But that’s precisely what happened to me on a Lenovo ThinkStation P3 Ultra Gen 2 (Arrow Lake-S desktop). There, Lenovo Vantage’s System Update panel stubbornly flagged Intel Dynamic Tuning Technology (DTT) Driver version 9.1.10001.173 as a required update, even after reporting a successful install on the previous try. Sigh again.


Why I’m Fixing False Vantage Update


Here’s the wrinkle: DTT is a laptop-exclusive power-management feature. It’s tightly coupled to Intel’s thermal sensor bus. Specifically, it applies to SWC\VID8086_DTT_* ACPI devices. Alas desktop platforms don’t sport them. My ThinkStation doesn’t have one. It never will. Yet Vantage keeps insisting otherwise.


Furthermore, every install attempt failed without so much as an error dialog. Vantage just re-offered the driver on the very next scan, politely pretending nothing had gone wrong. Time to dig in, and get this thing outtah heah!


Ruling Out the Obvious


First, I tried some obvious remedies. Logging into Vantage directly as Administrator changed nothing. There’s no ellipsis menu, no right-click context option. That means no “suppress this update” checkbox anywhere in the System Update panel. Lenovo simply hasn’t built that in.


Next, I turned to the standalone Lenovo System Update app. After installing the optional Lenovo SoftwareComponent Driver 26.9.0.20 from Windows Update, System Update scanned the machine and correctly reported “No packages applicable.” Clean bill of health. Meanwhile, Vantage still flagged the DTT driver for update. Sigh one more time.


However, that discrepancy was actually useful. It proved the issue lived entirely inside Vantage itself. It’s an artifact of its System Update addin, not  Lenovo’s underlying package catalog. The two tools evaluate the same catalog through completely different pipelines. Importantly, only one of them is wrong.


Tracing That False Positive…


With the obvious paths ruled out, I dug into Vantage’s session data folder: 

C:\ProgramData\Lenovo\Vantage\AddinData\

LenovoSystemUpdateAddin\session\.


Inside, I found two SQLite databases: update_history.db (Vantage’s live working store, rewritten on every scan) and editable_update_history.db (which appears designed to accept external edits). I tried setting the DTT entry status to NotApplicable in the editable_update_history.db. Alas, nothing changed on screen. Vantage reads update_history.db for all rendering decisions and overwrites it with Applicable again after each rescan. The “editable” database, it turns out, is a red herring.


I also found available_updates.json.It’s a 5 KB file that’s rewritten upon each update scan. It gave me a fully parsed package definition, including a Dependencies block that pointed me toward the real culprit.


A (Bogus) WildCard in the XML


Vantage caches each package’s raw XML in its own repository subfolder. For this machine, the DTT package XML lives at:


session\Repository\m1dpf015d_p3ultrag2_25h2\m1dpf015d_p3ultrag2_25h2_2_.xml


Inside that XML, the Dependencies/_Bios/Level section contained two machine-type entries: “*” and “S0NKT*”. The S0NKT* pattern correctly targets specific Lenovo laptop lines that carry DTT-capable thermal silicon. That entry belongs there. The “*” wildcard, however, matches every machine type on the planet — including the ThinkStation’s 30J5 machine type. That entry almost certainly doesn’t belong there, and it looks like a straightforward Lenovo catalog error.


Consequently, without the wildcard, Vantage evaluates the ThinkStation’s machine type against S0NKT*, finds no match, and writes NotApplicable to update_history.db automatically on every future scan. No database patching, no registry hacks — just the correct answer from a corrected applicability list.


PowerShell to the Rescue!


I wrapped the repair into a short PowerShell script called fix_dt.ps1. The logic is straightforward: clear the file’s read-only attribute, load the XML into an XmlDocument object, locate the offending node using an XPath query, remove it, save the file, restore read-only protection, then restart the LenovoVantageService so Vantage picks up the change cleanly.


The lines that do the heavy lifting are (edit to remove line breaks):


$node = $v.SelectSingleNode("//_Bios/Level[. = '*']")

if ($node)

{ $node.ParentNode.RemoveChild($node) | Out-Null }


Setting the file back to read-only afterward is an important step. It prevents Vantage from silently re-downloading a fresh copy of the XML on its next catalog sync and re-introducing the wildcard. Sadly, that would undo the fix entirely.


To run the script, open an elevated PowerShell prompt and execute:


powershell -ExecutionPolicy Bypass -File

"C:\Temp\fix_dt.ps1"






Note: Run this from an elevated (Run as Administrator) PowerShell session. The script must stop and restart the LenovoVantageService, which requires administrator rights. Edit so it runs on one line.






Lessons Learned


This exercise surfaced a few things worth minfing for anyone who’s doing deep Vantage troubleshooting:


    

  • Vantage and the standalone System Update utility maintain completely separate state databases and catalog evaluation pipelines. Agreement between them is not guaranteed. Disagreement is a useful diagnostic clue, not a dead end.
    • 

  • The “editable” SQLite database is a red herring for display suppression. Vantage ignores it when rendering the System Update panel. Don’t waste time on this.
    • 

  • A single bogus wildcard in a machine-type applicability list causes a laptop-only driver to haunt a desktop indefinitely. The fix is in the XML, not in the database.
    • 

  • When the official UI offers no suppress or hide option for a persistently wrong update, the XML repository is the right lever to pull. Appearances aside, it’s not the SQLite layer above it at fault.
    • 



Ultimately, this is a reminder that catalog quality control matters. One stray “*” in a dependency block can send thousands of ThinkStation owners chasing a ghost driver that will never install. If you’ve hit the same Lenovo Vantage false update on a different ThinkStation model, or if you’ve spotted a similar wildcard problem in another Vantage package XML, please drop a comment here. I’d love to know how broadly this catalog bug extends beyond the P3 Ultra Gen 2.


Here in Windows-World, updates sometimes get weird. This time, for once in a blue moon, it’s not WU that’s the culprit. It’s Lenovo. That makes me oddly glad. Go figure!

Facebooklinkedin
Facebooklinkedin	

	
	




	
	

			
	

				

			Cool Tools, PowerShell, Recent Activity, WED Blog, Windows 11
		

			
WinGet.Config Drives Developer Config

		

			 			Leave a comment
						

	


		

		
As I was reading a Windows Latest article about a “…special Windows 11 for power users…” this morning, I found myself wondering. “Could this be a big, fancy WinGet config file at work?” Indeed, reading further into the story absolutely confirmed my hunch. The file in question, in fact, is named winget.config, in keeping with current naming conventions around desired configuration states. Thus, it’s simple truth that Winget.Config drives “Developer Config” as described in the story (and at MS Learn as well).


WinGet.Config Drives Developer Config from End to End


The MS Learn article‘s intro paragraph is worth quoting in full to put this capability into clear context:


Windows Developer Configurations are a curated, open-source collection of configuration files that take a fresh Windows machine to a ready-to-code state with a single command. Each config is a declarative file that is safe to re-run. It describes the packages, OS settings, and post-install steps for a specific scenario (a full developer workstation, a comfortable WSL shell, or a single language toolchain), so you can rebuild your environment on any machine without clicking through installers or maintaining custom scripts.


Windows Developer Config is built from the ground up on winget configure and a single .winget desired state configuration (DSC) file named dev-config.winget. It is not a new Windows SKU, a custom ISO, nor a registry script. The whole thing is one winget configure call pointing at that file.


The commands necessary to instill this configuration are (mostly) shown in the lead-in graphic. I repeat them here for completeness’ sake (and for easy cut’n’paste, by copying non-comment lines completely):




# Enable WinGet Configuration first

winget configure --enable


# Clone the repo

git clone https://github.com/microsoft/WindowsDeveloperConfig.git

cd WindowsDeveloperConfig


# Apply the config

winget configure -f .\windows-dev-config\dev-config.winget –accept-configuration-agreements –disable-interactivity


More About WinGet.Config


That .winget file is a YAML-based DSC manifest that handles everything in one shot: installing PowerShell 7, Git, GitHub CLI, VS Code, .NET SDK, Python, Node.js, PowerToys, setting up WSL with Ubuntu, tweaking Windows Terminal defaults, enabling Developer Mode and long-path support, and applying a long list of Explorer/Start/Search/Widgets settings to declutter the UI.


Indeed, Project Zenith hardware ships with those same changes baked-in by the OEM. But the underlying mechanism Microsoft used to define and apply that configuration is exactly the same winget configure + .winget file approach. In fact, the .winget config file format is doing real work here. That is, it’s not just installing apps; it’s functioning as full-blown Windows DSC, a notable expansion beyond what most people think winget does.


Here in Windows-World, it’s great to see real innovation put to useful work. Demitrius Nelon, the head of the WinGet team, has told me several times over the past few months that .winget configuration files represent a way to customize Windows seriously in one go. Now, I think I understand what he was getting at. Great work, guys!

Facebooklinkedin
Facebooklinkedin	

	
	




	
	

			
	

				

			Insider stuff, PowerShell, Recent Activity, Troubleshooting, WED Blog, Windows 11, Windows Update
		

			
Long DISM Pause at 63% Range

		

			 			Leave a comment
						

	


		

		
I’ve been reading online at ElevenForum about people having issues with DISM ... /restorehealth on Build 26100.8972 and 26200.8972. Naturally, I had to check to see if I fell into that same boat. On the plus side, none of my machines at that build level threw an error for the command. On the minus, I observed a long DISM pause at 63% range in completing the sequence that stretched to 70% and a bit more. Copilot tells me this is the stage during which DISM downloads files needed to repair questionable items found in the component store.


Varying Times for Long DISM Pause at 63% Range


The lead-in graphic shows a completion time of 22m 55.301s for the command on my Flo6 desktop (MSI B550 mobo, AMD Ryzen 7 5800X, 64 GB RAM, RTX 3070 Ti). Other intervals I recorded include:


    

  • 13m 33.008s on AsusSnap (Zenbook A14, SnapDragon X Plus X1P-42-100, 16 GB RAM, Adreno graphics)
    • 

  • 8m 36.148s on Lenovo ThinkStation P3 Ultra (Core Ultra 9 285, 64 GB RAM, RTX 4000 SFF)
    • 



In this admittedly small sample, I see a strong relationship between CPU speed and completion time. That tells me there’s a lot of thinking going on while the /restorehealth operation is underway. Download volumes were all consistently in the 3-4GB range, as measured by download values from the Network Meter gadget from GadgetPack.


Skip WU, Try ISO


Copilot suggests further that pointing the /restorehealth command at a local ISO could speed things up. But it also says that “the ISO build must match 26200.x [the reference/focus build] closely.” The only way to do that right now is to build an ISO using UUPdump.net to match the 26200.9278 build all 3 PCs are running. That can easily take an hour or longer. My total time for all 3 was under 46 minutes.


Here in Windows-World, if you don’t pay (or spend time) one way, you’ll almost always spend it another. I took the WU route, and was glad all those DISM ... /restorehealth commands completed successfully. That’s good enough for me!


 

Facebooklinkedin
Facebooklinkedin	

	
	




	
	

			
	

				

			Cool Tools, Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11
		

			
Examining Nerd Font Glyphs

		

			 			Leave a comment
						

	


		

		
Nerd Fonts patch popular programming fonts with thousands of extra icons. These icons live in the Private Use Area (PUA) and other reserved Unicode blocks. Terminals that load Nerd Fonts gain instant access to logos, arrows, file-type icons, weather symbols, and power glyphs. Have you ever wondered exactly which glyphs your installed font contains? The Show-NerdFontGlyphs PowerShell function answers that question fast. It is the key to examining nerd font glyphs, in fact, up close and personal (see lead-in graphic).


Script for Examining Nerd Font Glyphs


The script defines one function: Show-NerdFontGlyphs. It loops through 13 named glyph ranges and renders each glyph alongside its hex code point. It also arranges the output in a configurable column grid. The default is eight columns wide. That width fits comfortably in most terminal windows. Run it, and in seconds you have a full visual catalog of every icon your font supports.


Each section prints a cyan header, making it easy to scan. Each row shows the rendered glyph followed by its four-digit hex address. That pairing is the key feature. Specifically, if you spot an icon you want, note its hex value. Then, reference it in PowerShell with [char]0xXXXX. For code points above U+FFFF, use [System.Char]::ConvertFromUtf32(0xXXXX) instead.


Unicode Ranges Covered


The script covers 13 glyph families. Here’s a quick guide to each one.


    

  • Pomicons (U+E000 to U+E00A): This set holds 11 miscellaneous icons from legacy Powerline themes.
    • 

  • Powerline (U+E0A0 to U+E0B3): These glyphs power the core Powerline separators and branch symbols used in prompt themes worldwide.
    • 

  • Powerline Extra (U+E0A3 to U+E0D4, scattered): This range adds rounded, flame, and diagonal separator variants to extend the Powerline set.
    • 

  • Symbols (U+E5FA to U+E6B2): These general-purpose glyphs include file-type icons and folder symbols.
    • 

  • Devicons (U+E700 to U+E7C5): This section covers programming language and framework logos including Python, JavaScript, Git, and Docker.
    • 

  • Font Awesome (U+F000 to U+F2E0): This classic set delivers social, UI, and media icons from Font Awesome 4.
    • 

  • Font Awesome Extension (U+E200 to U+E2A9): These icons extend Font Awesome with additional symbols.
    • 

  • Octicons (U+F400 to U+F4A8): GitHub Octicons cover pull requests, issues, branches, and repository actions.
    • 

  • Font Logos (U+F300 to U+F372): This range holds OS and distribution logos including Linux distros, BSD variants, and Apple.
    • 

  • Power Symbols (U+23FB to U+2B58): These glyphs represent standby, power-on, sleep, and toggle functions from the Miscellaneous Technical block.
    • 

  • Weather Icons (U+E300 to U+E3EB): This section delivers sun, cloud, rain, snow, wind, and forecast glyphs.
    • 

  • Material Design (U+F0000 to U+F0200, first 512 only): These icons come from Supplementary Private Use Area-A and represent a subset of the Material Design set.
    • 

  • Codicons (U+EA60 to U+EBEB): Visual Studio Code uses these icons for debugging, source control, and editor UI elements.
    • 



Spotlight on U+E62A: Win11 Logo


One glyph deserves special attention: U+E62A. It sits inside the Symbols range (U+E5FA to U+E6B2) and renders as the four-pane Windows 11 logo. Furthermore, it behaves as a double-width glyph. In other words, it occupies two terminal columns rather than one. That property makes it ideal for building large logo art in FastFetch or other terminal info tools.


You reference it in PowerShell with [char]0xE62A. In a Nerd Font terminal, that expression produces the Windows logo glyph directly. Yesterday’s post on this site shows how to build a custom 8×8 FastFetch logo grid in Windows blue using this glyph.


Running the Script


Save the function to showglyphs.ps1. Next, dot-source it in your PowerShell 7 session and call it:


.\showglyphs.ps1

Show-NerdFontGlyphs


You can also adjust -Columns to fit your terminal width. Narrower windows work better with -Columns 4 or -Columns 6. The function handles code points above U+FFFF using [System.Char]::ConvertFromUtf32. As a result, it does not throw errors on supplementary characters.


Download the Script


Download the complete showglyphs.ps1 script directly from this post. Save it to your PowerShell scripts folder and dot-source it in your profile or on demand. Finally, pair it with a Nerd Font in Windows Terminal for the best results. CaskaydiaCove Nerd Font and JetBrainsMono Nerd Font are both excellent choices.


I wouldn’t have found the Win11 logo without this nifty little tool. Try it yourself, and be amazed at all the icon-like images that nerd fonts can offer. They’re amazing!

Facebooklinkedin
Facebooklinkedin	

	
	




	
	

			
	

				

			Cool Tools, Insider stuff, Recent Activity, WED Blog, Windows 11
		

			
Using WinLogo Glyph in FastFetch

		

			 			Leave a comment
						

	


		

		
FastFetch is a lightning-fast system information tool that runs in the terminal and displays your OS, CPU, GPU, memory, and disk details in a clean two-column layout. It ships with built-in text-art logos for major OSes. Alas, the default Windows logo in FastFetch is a modest ASCII rendering using the letter “l”. This post shows you how to replace it with the Windows 11 Nerd Font glyph. I call it the WinLogo glyph myself. And indeed, using the winlogo glyph in FastFetch is easy thanks to two short PowerShell scripts.


How Easy Is Using WinLogo Glyph in FastFetch?


Nerd Fonts are patched programming fonts that include hundreds of extra icons in their Private Use Area. The Windows 11 logo lives at Unicode code point U+E62A. When your terminal uses a Nerd Font such as CaskaydiaCove Nerd Font or JetBrainsMono Nerd Font, that code point renders as the familiar four-pane Windows 11 logo.


However, each U+E62A glyph is double-width. In other words, it occupies two terminal columns rather than one. That behavior matters when you configure FastFetch’s width parameter, as I’ll show later on. Knowing this upfront saves you trial and error later.


How FastFetch Reads a Custom Logo File


FastFetch supports a logo type called file. With this type, FastFetch reads a plain-text file and renders its contents to the left of your system information panel. Inside that file, color tokens such as $1 map to ANSI colors you define in config.jsonc. FastFetch re-applies the color at the start of each logo line, so any segment that needs consistent coloring must carry its own $1 re-arm token.


The design I used is a 2×2 arrangement of four 8×8 glyph blocks. Together, they form a large Windows logo built from smaller Windows logos. Each row contains two groups of eight glyphs separated by four spaces, with a single space between individual glyphs inside each group. A single blank line divides the top two blocks from the bottom two, giving the overall shape a clean four-pane look.


The key trick: after the left block and the four-space gap, FastFetch can silently drop the active color. Adding a second $1 token directly before the right block re-arms the color and keeps both sides uniformly blue across all 17 lines of the file. I figured this out by experiment, but I’m happy to share this “secret” openly.


Example 1: Writing the 8×8 Logo File


Run the following script in PowerShell 7. It writes the logo file with UTF-8 no-BOM encoding, which FastFetch requires to interpret this glyph correctly.


Example 1: win11logo.txt generator


$g = [char]0xE62A

$b = "$g $g $g $g $g $g $g $g"

$r = '$1 ' + $b + ' $1' + $b + ' '

$gap = '$1 ' + (' ' * 28)

$logo = ($r,$r,$r,$r,$r,$r,$r,$r,$gap,$r,$r,$r,$r,$r,$r,$r,$r) -join [char]10

[System.IO.File]::WriteAllText(

"$env:USERPROFILE\.config\fastfetch\win11logo.txt",

$logo,

[System.Text.UTF8Encoding]::new($false)

)




Note: the foregoing text is formatted for cut’n’paste use. Parsing it for human readability doesn’t work well in WordPress. Sorry! If you don’t have a fastfetch directory set up, start with this ahead of the previous commands: New-Item -ItemType Directory -Force "$env:USERPROFILE\.config\fastfetch" | Out-Null.


The [char]0xE62A expression converts the Unicode code point to an actual glyph character at runtime. The backtick before each $1 token tells PowerShell to treat the dollar sign as a literal character rather than the start of a variable name. The $gap variable fills the blank middle row with enough spaces so that FastFetch won’t collapse it.


Example 2: Write the FastFetch Config File


With the logo file in place, the next step is updating config.jsonc. The width value tells FastFetch how many columns to reserve for the logo panel. FastFetch counts each glyph as one character, not two display columns. Therefore, set width to the character count of the longest line in the logo file, not to the visual column count. For this 8×8 layout, that value is 38.


The height value is 17, matching the total line count of the logo file: eight rows, one blank gap row, and eight more rows. The color key maps $1 to Windows blue via the 24-bit ANSI code 38;2;0;120;212. A trailing space at the end of each logo row ensures the rightmost glyph renders in blue rather than in the terminal’s default foreground color.


Example 2: config.json generator

$lp = ("$env:USERPROFILE\.config\fastfetch\win11logo.txt") -replace '\\','/'

('{"logo":{"source":"' + $lp + '","type":"file","color":{"1":"38;2;0;120;212"},"width":38,"height":17,"padding":{"top":0,"left":1,"right":1}},"modules":["title","separator","os","host","kernel","uptime","packages","shell","display","cpu","gpu","memory","disk","battery"]}') | Set-Content "$env:USERPROFILE\.config\fastfetch\config.jsonc" -Encoding utf8NoBOM




Tips and Gotchas


A few points are worth keeping in mind before you run these scripts.


First, the default font must be a Nerd Font. The U+E62A glyph renders as a plain box or question mark in any non-patched font. CaskaydiaCove Nerd Font, JetBrainsMono Nerd Font, and FiraCode Nerd Font are all reliable choices that include the Windows logo glyph.


Second, width tuning requires some trial and error. If the right-side block renders in white instead of blue, increase width by two or three. If the gap between the logo and the info panel is too wide, decrease width by the same amount. The trailing space in each logo row prevents the rightmost glyph from getting clipped by the color boundary.


Third, always use Set-Content with -Encoding utf8NoBOM for the config file and [System.IO.File]::WriteAllText with an explicit UTF8Encoding $false object for the logo file. PowerShell’s default encoding on Windows adds a byte-order mark that FastFetch does not handle gracefully when reading Nerd Font glyphs. I learned this the hard way, so you don’t have to!


Enjoying the Fruits of Your Labor


After both scripts run, type fastfetch at the prompt. You should see a bold, blue 4×4 Windows logo grid on the left, assembled from 256 individual Windows 11 glyphs, flanking a full system information panel on the right. The result is a visually striking terminal greeting that is entirely Windows-native in spirit and thoroughly custom in execution.


The WinLogo glyph in FastFetch is a small but satisfying way to put your personal stamp on your PowerShell environment. If you tweak the grid size or colors, the same two-script approach scales to any N x N layout you prefer.


Here in Windows-World, I get my jollies where I can find them. Today, I found them using a Windows 11 logo glyph for my OS logo in FastFetch. Where will my jollies come tomorrow?

Facebooklinkedin
Facebooklinkedin	

	
	




	
	

			
	

				

			Cool Tools, Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 10, Windows 11
		

			
WinGet Misses ARM Browser Updates

		

			 			Leave a comment
						

	


		

		
If you run winget upgrade --all on an ARM-based Windows 11 PC (e.g. an Asus Zenbook A14), you may notice something odd: Chrome and Firefox don’t show in the upgrade list, even when they’re out of date. On an x64 desktop, winget catches them without fail. So what gives? Briefly put, and for various reasons, WinGet misses ARM browser updates for certain implementations.


It turns out there are four overlapping bugs and design gaps at play. All of them affect ARM64 PCs. None of them are your fault, either. But together they form a perfect storm that makes WinGet effectively blind to certain browsers. For now, anyway.


TLDR: On ARM64 Windows PCs, WinGet fails to detect and upgrade Chrome and Firefox due to four compounding issues: a name-normalization bug (winget-cli #6490), a registry hive mismatch, a broken ARM64 manifest entry for Chrome, and an architecture-selection bug (winget-pkgs #424881). Until Microsoft patches these, a handful of workarounds fill the gap. Here goes…


Diving in: Why WinGet Misses ARM Browser Updates


On x64 machines, the registry is simple: one hive, one architecture tag, and manifests that have been battle-tested for years. WinGet’s upgrade logic originates from that x64 worldview. Alas, things on ARM64 aren’t quite so simple, and all four failure modes described next come out of various diversions from the x64 situation.


Four Root Causes


    

  1.  The ARP Name-Normalization Bug (winget-cli #6490)
    2. 



Winget matches installed apps to its catalog by reading Add/Remove Programs (ARP) registry entries and normalizing display names. It strips “x86” and “x64” — but has no handling for “arm64” or “ARM64.” When Chrome or Firefox registers with an ARM64 architecture suffix on a Snapdragon device, winget cannot correlate it to the catalog entry and silently drops it. The app becomes invisible to winget upgrade.


    

  1.  The Registry Hive Mismatch
    2. 



ARM64 Windows splits app registrations across 3 registry hives:


 






Hive
Contents
Who Writes There






SOFTWARE\…\Uninstall
Native ARM64 apps
ARM64 installers




SOFTWARE\WOW6432Node\…\Uninstall
x64-emulated apps
x64 installers (Chrome, Firefox legacy)




HKCU\SOFTWARE\…\Uninstall
Per-user installs
Either architecture






 


If Chrome or Firefox were installed via an x64 installer — the only option before both browsers shipped native ARM64 builds — it lives in WOW6432Node. Winget, running as a native ARM64 process, reads the native hive first and, when name normalization is also broken, frequently misses those emulated entries entirely.


    

  1.  The Broken Chrome ARM64 Manifest
    2. 



Even when winget finds Chrome, the Google.Chrome manifest in the community repository lists an arm64 installer entry with a blank SHA256 hash. Winget requires a valid hash to verify any upgrade — blank means the ARM64 path is present on paper but non-functional. The Google.Chrome.EXE package ID does carry a properly populated hash, which explains why some users get inconsistent results depending on which package ID is in play.


    

  1.  The Architecture Selection Bug (winget-pkgs #424881)
    2. 



Even with a complete, valid manifest, winget’s upgrade logic has a documented bug where it selects the x64 installer over arm64 on Windows on ARM machines. Best case: you get the slower, emulated build pushed onto your ARM device. Worst case: the upgrade fails outright.


Viable WinGet Workarounds


Until Microsoft ships fixes, here are some WinGet options — from most precise to most blunt:


    

  1. Force the architecture explicitly: Use winget upgrade Google.Chrome --architecture arm64 and winget upgrade Mozilla.Firefox --architecture arm64. This bypasses both  correlation and selection bugs in one go.
    2. 

  2. Use the Chrome EXE package ID: winget upgrade Google.Chrome.EXE --architecture arm64 hits the manifest entry that actually has a valid SHA256 hash for ARM64.
    3. 

  3. Let the browsers self-update: Both Chrome (Google Update/Omaha) and Firefox (Mozilla Maintenance Service) are fully architecture-aware. Help → About in either browser triggers an immediate, correct ARM64 update — no winget involved, no ARM64 drama.
    4. 

  4. Add --include-unknown as a catch-all: winget upgrade --all --include-unknown is a blunt instrument, but it sometimes remcatches apps that fail normal ARP correlation.
    5. 



The real, true fix requires Microsoft to patch name-normalization and upgrade architecture-selection logic in winget-cli. Two of the four bug reports were filed in the last few days, so movement could come soon. Until then, –architecture arm64 is the cleanest workaround on your Zenbook A14 — or any other Snapdragon-powered Windows machine. In Windows-World, knowing where the bodies are buried is half the battle.

Facebooklinkedin
Facebooklinkedin	

	
	




	
	

			
	

				

			Insider stuff, Recent Activity, WED Blog, Windows 11, Windows Update
		

			
Version 26H2 Coming Soon Via eKB

		

			 			Leave a comment
						

	


		

		




If you’re running Windows 11 24H2 or 25H2, the next annual upgrade aka Windows 11 26H2 is almost here. For many users, the upgrade experience should be pretty low-key. Microsoft pushed Build 26300.9278 into the Release Preview Channel on August 27, 2026. That signals general availability (GA) is on track for September or October. Hence my proclamation about Version 26H2 coming soon via eKB. What’s that?


Qualifying devices won’t sit through a multi-gigabyte download or a lengthy offline install. Instead, they’ll receive a tiny enablement package (eKB) that flips the version number after a single restart.


TLDR: Windows 11 26H2 (Build 26300.9278) is in Release Preview now and coming this fall. It lands as a ~174 KB enablement package (KB5121794) for 24H2 and 25H2 users. Windows 11 23H2 and older face a full ~6.5 GB feature update. Windows 10 users, of course, need a full OS upgrade. And 26H1 (the Arm-only branch) has no standard eKB path to 26H2 at all. For them, a clean install is the only way to go forward.


What Is an Enablement Package?


An enablement package (eKB) works because 24H2, 25H2, and 26H2 share the same underlying servicing branch and codebase. Most of what defines 26H2 has already been delivered to your PC through monthly cumulative updates. Indeed, the eKB simply activates it, changes the build string to the 26300 series, and reboots. The download for KB5121794 weighs in at around 174 KB, and is smaller than most web images. One prerequisite: your system must already have KB5120998 (Builds 26200.9278 or 26100.9278) installed before the enablement package can run. A quick visit to Settings > Windows Update confirms if you’re current (or not).


As Paul Thurrott reported on Thurrott.com, for the first time, Microsoft is releasing a new Windows version to the Insider Release Preview ahead of general availability. That’s a sign that the company wants broader validation before the full rollout. The official announcement comes from Stephen Lines via the Windows Insider Blog.


Upgrade Paths: Know Where You Stand


Your path to 26H2 depends entirely on which version you’re running today. This table lays things out:






Current Version
Upgrade Method
Download Size
Restarts






Windows 11 25H2
Enablement Package (KB5121794)
~174 KB
1




Windows 11 24H2
Enablement Package (KB5121794)
~174 KB
1




Windows 11 23H2
Full feature update (different servicing branch)
~6.5 GB
Multiple




Windows 11 26H1 (Arm)
Separate core branch — no standard eKB path
N/A
N/A




Windows 10
Full OS upgrade or clean install
~6.5 GB+
Multiple






As TechPowerUp’s AleksandarK noted, devices on 23H2 and older sit on a different servicing branch. Thus, there’s no eKB shortcut for them. And 26H1, built specifically for new Arm silicon such as Snapdragon X2 Elite devices, runs a separate Windows core and won’t roll forward via the standard enablement path. Microsoft has said those devices will eventually receive a path to a future Windows release. Those who wish to jump that gun must, as I said earlier, do a clean install.


What 26H2 Actually Delivers


Let’s be blunt: 26H2 is a stability and lifecycle-reset release, not a features spectacular. Thanks to Microsoft’s continuous innovation model, most of what carries the 26H2 label has already landed on your device via monthly updates. That said, commercial customers do get a handful of features enabled by default for the first time: Windows Settings Backup, app-specific Taskbar actions, and several File Explorer enhancements.


The bigger prize is the support lifecycle reset. That is, 24H2 Home and Pro reach end of updates on October 13, 2026. Thus, upgrading keeps you beneath the security update umbrella.


How to Get It Now


Windows Insiders in the Release Preview Channel can grab 26H2 today via Settings > Windows Update using the seeker experience (enable “Get the latest updates as soon as they’re available”). For everyone else, wait for GA. At that time, Microsoft will offer 26H2 as an optional install first, then push it automatically as 24H2 nears its support deadline. If you’re still on 23H2 or older, the smartest move right now is upgrading to 24H2 or 25H2, so that when 26H2 arrives, it costs you 174 KB and one reboot instead of a 6.5 GB weekend project.


Here in Windows-World, it’s wise to get ahead of the curve when the opportunity presents. This is one such opportunity. I plan to jump on it as soon as I can!

Facebooklinkedin
Facebooklinkedin	

	
	

		
			
		

	

	




		
Author, Editor, Expert Witness