Category Archives: PowerShell

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

Dude, Where’s My Icons?

Leave a comment

I just spent a couple of frustrating but informative hours trying to get icons to show up with WinGet on the latest Canary build (29558.1000). What started out as a minor visual quirk turned into a deep dive into the innards for App Installer, feature flags, and system-level packages. I’ll provide a step-by-step list of what I did, what I learned, and what others running Canary builds should know. At this point I’m still asking “Dude, where’s my icons?” for WinGet output. But I now know I won’t see them any time soon. I’ll explain…

Steps in Resolving “Dude, Where’s My Icons?”

The first step was to verify the WinGet version and its capabilities. Running winget –info revealed I was on version 1.29.50-preview. Notably, that output lacked usual capability lines including VT Support or Rich Output. That was my first clue that something wasn’t quite right.

Next, I visited the Microsoft Store. I navigated directly to the App Installer product page using the canonical link. The Store offered an Install button. When I clicked same, I expected it to overwrite the preview build with the stable version. After installation, the Store indeed reported the app as Installed. It lied!

I then closed all terminal sessions and opened a fresh CMD tab to recheck winget –info. Unfortunately, the version remained 1.29.50-preview. Worse still, the missing icon issue persisted. To investigate further, I ran PowerShell as Administrator and executed Get-AppxPackage Microsoft.DesktopAppInstaller -AllUsers. The output showed only one package: version 1.29.50.0, marked as NonRemovable. Was I stuck?

Yes, I Was Stuck…

The crux of the matter rests on how Canary builds handle App Installer. On these builds, the preview version of App Installer is baked into the OS image. Indeed, it’s registered as a system-level package. Because it is marked NonRemovable, neither the Microsoft Store nor PowerShell can uninstall or override it. That explains why even though the Store shows the stable App Installer as Installed, Windows continues to use the preview version.

Yep, sez right at bottom: NonRemovable: True

This locked-in preview build lacks support for feature flags like Visual Icons and Rich Output. Alas, their lack also explains the missing icon column in WinGet output. No attempts at reinstalling, resetting, or tweaking settings.json can override this limitation. Stuck indeed.

Note: the lead-in graphic for this story comes from the Build 29558.1000 announcement blog. I can see that damnable delectable icon there in the posting, but I’ll be darned if I can make it show up on my Canary install. Go figure!

 

 

Facebooklinkedin
Facebooklinkedin
Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11

Understanding UEFICA2023Status=NotStarted

Leave a comment

With the introduction of the Windows UEFI Certificate Authority 2023 (CA‑2023), Microsoft updates the Secure Boot trust chain to enhance platform security. As part of this transition, Windows systems may report a registry value under the key HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing named UEFICA2023Status. This value reports the status of the Secure Boot servicing task that migrates systems to the new CA‑2023 trust model. Understanding UEFICA2023Status= NotStarted is important, because it doesn’t mean CA2023 is not in use in the running Secure Boot environment. Let me explain…

What UEFICA2023Status=NotStarted Means

There are two reasons why UEFICA2023Status can take a value of NotStarted. The obvious one is when the CA-2023 certificate is ready to be added to the Secure Boot value stores, and the Servicing Task hasn’t yet been scheduled or run. The other, as I’m about to describe happens when the Windows PC is already up-to-date. Huh?

The UEFICA2023Status value can take on several states, including NotStarted, PendingReboot, Completed, and Failed. A common misconception is that a NotStarted value signals failure to apply the CA‑2023 update. In reality, this value might also mean that the Secure Boot servicing task has not been triggered. Why? Because the system already meets all necessary criteria for CA‑2023 compliance, and that task need not be run.

Specifically, Windows only initiates this servicing task if all of these three conditions are met:
1. The system firmware does not already trust the Microsoft UEFI CA 2023.
2. The EFI System Partition (ESP) does not contain a bootloader signed by the CA‑2023.
3. A servicing stack update or cumulative update requires the migration to complete.

If the system firmware already includes the CA‑2023 certificate and the ESP contains a CA‑2023‑signed bootloader, Windows deems migration unnecessary. In such cases, the registry value remains NotStarted, which is both normal and acceptable. Even so, it took me aback when I checked this value and saw that status (see lead-in graphic). It spurred me to investigate, and led to this very blog post.

As it happens, the BIOS/UEFI flash I conducted to get the MSI MAG Tomahawk B550 motherboard working updated Secure Boot and included the CA-2023 certificate data as well. And, somewhere along the way the EFI partition got rebuilt to include the CA-2023 signed bootloader. My desktop, Flo6, simply doesn’t need Windows to run the UEFICA2023 update task.

Verifying the EFI Bootloader Signature

It’s easy to confirm that the system is booting with a CA‑2023‑signed bootloader. Indeed, one need only examine the signature of the boot manager located on the ESP. This typically resides at S:\EFI\Microsoft\Boot\bootmgfw.efi (where S: is the mounted ESP). Using PowerShell, execute the following one-liner command:

Get-AuthenticodeSignature "S:\EFI\Microsoft\Boot\bootmgfw.efi" | Format-List *

If it’s current, the output shows the [Issuer] as Windows UEFI CA 2023. (Otherwise it shows as Windows UEFI CA 2011.) Seeing CA 2023 here confirms that the firmware uses a bootloader signed with the updated certificate authority.

Comparing with the OS Copy

Windows also maintains an OS copy of the boot manager at C:\Windows\Boot\EFI\bootmgfw.efi. This file is not used for booting but may be referenced during servicing operations. It is common for this file to remain signed by the older Microsoft Windows Production PCA 2011 certificate. This does not impact Secure Boot functionality, because the firmware uses the ESP copy. We’ve just confirmed the the ESP copy is current and correct for CA-2023.

This Time, NotStarted Is All Good

Appearances to the contrary notwithstanding, a UEFICA2023Status value of “NotStarted” does not always indicate a problem. Instead, it can simply reflect that the system complies with the Secure Boot requirements for CA‑2023 (and got there before MS could). We verified the ESP bootloader is signed by the Windows UEFI CA 2023. We also confirmed that the firmware trust store includes the appropriate (2023) certificate. Passing these checks means that users can be confident that the system is operating within the latest, current Secure Boot regime despite this “interesting” status. No further action is required unless future updates say otherwise.

Facebooklinkedin
Facebooklinkedin
Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11

PS Version Bump WinTerm Oddity

Leave a comment

As is my usual practice, my workday starts off with a cruise over the mini-fleet of PCs here at Chez Tittel. I look for upgrades, updates, changes, and glitches. Today, I ran into something interesting on the Lenovo ThinkPad P16 Gen 1 Mobile Workstation. A PowerShell (PS) upgrade happened — and succeeded — even though its parent WinTerm session shows WinGet reporting “Installation abandoned.” That’s the source of this particular PS version bump WinTerm oddity. Let me explain…

Exploring PS Version Bump WinTerm Oddity

As you can see in the lead-in screencap, the left-hand WinTerm pane is running PowerShell v7.5.5. You can also see that WinGet gets going on a v7.6.0.0 upgrade, but reports “Installation abandoned” at its apparent conclusion. Indeed, most readers might be tempted to conclude from this that the installation failed. Not so!

As you can see in the right-hand pane, opened after the apparent WinGet failure, the PS version there is 7.6.0(.0). The update succeeded but it can’t show itself in the parent pane for a very good reason. PS v7.5.5 is running that pane, and the developers didn’t include logic to halt that process and swap in a new version as part of the way that PowerShell works.

It’s a kind of Catch-22 (“How can you see you have flies in your eyes, if you have flies in your eyes?” as Orr asks in the famous WWII novel). With the older version running, you can’t really get the newer one to report itself right there at that moment. But as the right-hand pane shows, you need only open a new PS Session and presto! the new version is up and running therein.

Self-Update Is a Tricky Thing

This is an age-old gotcha in computer science. When the thing being updated is also running (and indeed, running the update tool in use), certain compromises and workarounds are needed to prevent things from falling over. For PowerShell, that means reporting a cancelled installation even though the installation itself completes and succeeds. The session that did the work simply can’t see and report on that particular change, because it itself would have to change to do that. Start a new session, and a new and changed context lets that happen.

Here in Windows-World, change is a constant. When the changer itself is changing, things get interesting. WinGet’s report of a “cancelled installation” for PowerShell shows how a specific compromise happens at runtime when PowerShell participates in its own update process. Fun!

 

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, PowerShell, Recent Activity, WED Blog

WinGet Versions May Affect Installs

Leave a comment

I just saw something interesting running WinGet on multiple PCs here at Chez Tittel. On my production desktop (Flo6) running production Winget (Version 1.27.470.0) a Teams update just failed with error message “…system cannot find … file specified (0x80070002).” On my Canary test system (X12Hybrid) running preview Winget (Version 1.29.30.0) that very same update succeeded. Inevitable conclusion: WinGet version may affect installs and updates, including success or failure. Who knew? Let’s discuss…

Why WinGet Versions May Affect Installs

Copilot confirms my suspicion that version differences sometimes affect update or install behavior. It says (and I concur) “some WinGet releases and App installer builds handle extraction and temp paths differently; newer/older builds can succeed where others fail.” Isn’t that strange — but typical — for Windows stuff anyway?

Fortunately, the in-app updater in Teams popped up as soon as I opened the app up. It, at least, was able to update itself successfully. So I applied the old principle: if you can’t do it one way, try another, and got past this hurdle anyway.

Is It a Version, or an Instance?

Then I went looking at my other production level PCs here at Chez Tittel. I looked at 4 other machines in my office all running Windows 25H2 Build 26200.8037 (latest production build). None threw the same error, though all are on the same Windows, Winget and Terminal versions. Interesting! My other production machines, however, did post this warning (in yellow) after the Teams update:
“Successfully installed. Restart the application to complete the upgrade.” (That warning does not appear in the lead-in graphic, which comes from a preview WinGet version instead.)

I’m left with no choice to conclude that it’s the configuration of the particular machine (Flo6) that’s somehow suffering or different. Based on what Copilot told me, it’s likely a PATH issue of some kind. As the old Internet adage goes so well for Windows: YMMV. Indeed, it just did!

Facebooklinkedin
Facebooklinkedin
Backup/Restore, Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11

On Windows 11 Restore Points

Leave a comment

In Windows 11, a restore point provides a snapshot of various essential system files, settings, installed programs, and the registry taken at a specific point in time. Restore points can roll back the OS and associated state info should something go sideways. They don’t replace backups (especially image backups) because they don’t contain personal files and documents, nor do they capture other boot disk partitions for full restoration (e.g. EFI, MSR and recovery partitions, if present). I’ve been thinking on Windows 11 restore points because I don’t use them (I use daily image backups instead) and because they can take up lots of room on disk.

Looking further into Windows 11 Restore Points

Before I could share my reflections and observations about Windows 11 Restore Points (let’s condense that to W11RPs) I had to find a machine with them turned on to dig into them a bit. Turns out my newest personal acquisition — the very nice ASUS Zenbook A14 I picked up during Black Friday sales last year — still has them turned on. You can see that the C: drive has W11RPs enabled, and the info about a single restore point that I just generated right under neath.

You can find restore points inside the WizTree app pretty easily, if you’ve got any. They appear within the System Volume Information folder, which lives at the root of the boot/system drive (C:\ usually). It’s the big purple rectangle in this snippet from Wiztree, and corresponds to the shadow copy item shown in the lead-in graphic (output from the vssadmin list shadows command, in fact):

At 2.3 GB in size, one can see why keeping numbers of them around might be something of a storage-sucker. In truth, that’s one big reason I typically don’t keep them around.

Turning W11RPs on and off, and more

The controls for W11RPs live on the Protection tab of the System Properties applet in Control Panel. Settings in Windows 11 kind of interferes with access to this info, so the best way to get there these days is to invoke its executable directly (Into the Windows Run box (Winkey+R), type this string:

C:\Windows\System32\SystemPropertiesProtection.exe

That fires up the item screencapped next, and shows the key controls for W11RPs, to wit:

For any drives available on the target system, you select its entry, click the “Configure” button then enable or disable restore points. As you can see about the C:\ drive has W11RPs enabled, and it came that way from the factory.

Problems with W11RPs?

If you read up on informed sentiment about W11RPs (I get my insights from many sources, but find TenForums.com and ElevenForum.com particularly insightful), you’ll learn that they sometimes work, and sometimes don’t. If you use them, you’ll learn that they take a while to load (on the order of 15-20 minutes on most of my PCs). They also tend to happen once a day by scheduled task, and whenever you make system changes or install apps that include built-in RP capture commands.

You can use them if you like. I don’t like, and I don’t use them. Macrium Reflect can restore a full system image on my PCs in the 2-6 minute range, is easier to use, runs from a rescue disk if needed, and has shown itself to be thoroughly reliable and capable. For me that’s the end of the story.

Now, pardon me while I go off to disable W11RPs on the AsusSnap. I seem to have forgotten this little step in my intake process…

 

Facebooklinkedin
Facebooklinkedin
Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11

Returning Spurious Reclaimables Removed

Leave a comment

For the past couple of years, I’ve watched various Windows updates and upgrades introduce and re-introduce what I call “spurious reclaimables.” These are windows packages that show up in the component store that (a) don’t need to be there and (b) refuse removal using dism /online …. /StartComponentCleanup. Just yesterday, Copilot helped me figure out how to yet again make them go away. That’s because I saw a familiar set of returning spurious reclaimables removed on the ARM-based ThinkPad T14s Gen 6.

Getting Returning Spurious Reclaimables Removed

There are two such packages in this mix, each with characteristic, fairly unique substrings — namely “RollupFix” and “FodMetadata.” So that’s what I used to find that stuff in the package store:

dism /online /get-packages /format:table | findstr /i “RollupFix”
dism /online /get-packages /format:table | findstr /i “FodMetadata”

Those commands let me find the precise package names that I would go on to use to remove the spurious ones from the package store. Indeed, Windows 11 24/25H2 continues to surprise even seasoned Windows hands with its servicing behavior—especially on ARM64 systems. Here’s a short but hopefully illuminating dive into how ARM64 handles staged vs. installed packages, and why some packages appear removable even when they aren’t.

Working Through the Process: RollupFix

Here’s my starting point — namely, two RollupFix Packages. One is staged and the other installed. On the T14s laptopn  DISM /get-packages listed two versions of the RollupFix package:
– A staged version: 26100.1743.1.3
– An installed version: 26100.7674.1.3
Both appeared to be reclaimable. So I started with the older, staged version, and provided a DISM command to remove it:

dism /online /remove-package /packagename:Package_for_
RollupFix~31bf3856ad364e35~arm64~~26100.1743.1.3

(Note I stuck a CRLF into that line to make it lay out better. To cut’n’paste that item, stick into Notepad and turn it into a one-liner.)

DISM happily complied with that command and responded with: “Processing 1 of 1 – Removing package … The operation completed successfully.” So far, so good. But the next step revealed something interesting, as I attempted to remove the newer, installed RollupFix package (same syntax as above, new package name).

This time, DISM responded with an error message, to wit: “Error: 0x800f0825 — the package is permanent or not applicable.” That means once the staged version got removed, the installed version became the baseline and couldn’t be removed. This mirrors AMD64 behavior, though ARM64 expresses things more forcefully. Removing the superseded version effectively locks in the newer one, making it “permanent” and non-removable.

Further into the Process: FodMetadata

The T14s also offered up two versions of the FOD metadata servicing package, one staged, the other installed:
– Staged: 10.0.26100.1743
– Installed: 10.0.26100.7674
Again I started with the staged version. This time DISM responded with Error 0x800F0805 “the staged package is already gone.” ARM64 appears to auto-clean the staged FOD metadata package when the staged RollupFix package is removed.

That’s a subtle but important difference from AMD64, where the FOD metadata package is removed automatically only when the installed RollupFix is removed. Thus, removing the installed version worked as it should, and that operation completed successfully.

Final Check: Clean Component Store

When I ran a followup /analyzecomponent store check in DISM after those various attempted and successful removals, I got clean store billing, as reported in these output lines for that command:

Number of Reclaimable Packages: 0
Component Store Cleanup Recommended: No

That means the component store is clean, and there are no more reclaimable packages, spurious or otherwise, to get rid of. That’s what I like to see! You can see further confirmation in the lead-in graphic which shows only “Installed” versions for the two packages that previouly included older, obsolete staged versions prior to the cleanup moves I described above.

 

 

Facebooklinkedin
Facebooklinkedin
AI, Insider stuff, PowerShell, Recent Activity, Thoughts & concerns, WED Blog, Windows 11

Secure Boot Pursuit Undone

2 Comments

We’ve been (and still are, I kid you not) snowed in here in Central Texas. With Winter Storm Fern bearing down on us, we started hunkering down here last Friday (1/23). On Saturday we had rain, sleet and snow, and woke up to snowy sights Sunday. Figuring I had time on my hands, I decided to see if I could get Secure Boot working on my Asrock B550 Ryzen 7 5800X Flo6 production desktop. Alas, after much wrestling with hardware and software, I saw my Secure Boot pursuit undone early, early this morning. Let me explain…

Why Is My Secure Boot Pursuit Undone?

Through all kinds of contortions (see list below) I couldn’t get the PC to boot with Secure Boot enabled. Let me enumerate some of them so you can appreciate what I tried and failed to get done this weekend:

  • 2 repair  installs of my current running OS
  • 1 “dirty install” (do not format partitions, but run installer which moves old OS into Windows.old and creates a new one: IDKYDT)
  • At least 2 each dism /restorehealth, sfc /scannow & chkdsk
  • Remove boot/sys drive from its M.2 slot to wipe NVMe config data from UEFI (have to remove GPU to access slot, sigh)
  • Swapped out old, soon-to-be obsolete 1070 Ti for 3070 Ti GPU.
  • spent over 30 hours fiddling with UEFI and Windows configs

After the “dirty install” I realized I’d hosed the primary MSA login on my main work machine. Not acceptable!! This morning, I built a new Macrium Reflect X Rescue disk, extracted the drivers from the Flo6, and restored my most recent backup (Friday afternoon, after I’d reorganized the boot/sys drive partitions).

Back in Business, Back to Work!

I learned a bunch about boot configuration data and related commands. I’m definitely completely up on booting the Flo6 into WinRE, Windows installer media, and the Macrium Rescue Disk. I’m much better acquainted with the Asrock UEFI than I’ve ever been before.

I also learned that my old MS Comfort Curve 4000 keyboard can’t (or won’t) send Fn key data to UEFI. Working on the ThinkPad P16 Gen 1 I soon figured out scrolling Copilot output was MUCH easier with an external mouse with scroll wheel than using the touchpad. Who knew?

And finally, I learned that Copilot will lead you all over the place trying to solve problems, heedless of time involved and consequence entailed. Sure, AI will tell you pretty much anything about Windows you want to know, but I wasn’t happy with the circuitous routes it took me on, and the circles it spun me through. Then it occurred to me: the words mendacious, malicious, utopia, and paradise all include AI, as do the phrases folie a deux and waste of time. Here in snowed-in Windows-World this weekend, I saw all those things play out. It was oddly engaging, but I’m glad it’s over.

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

Fixing WinKey+X Menu Change

Leave a comment

The Win+X menu — that little power‑user gem tucked behind the Start button — is a Windows feature you don’t think about much until it breaks. When it does, the symptoms can be maddening: missing entries, wrong icons, dead shortcuts, or menu items that don’t launch. I recently went through a repair of the Win+X system on my production desktop. That process revealed just how many layers contribute to this simple menu. Here’s a recap of how the issue was resolved in fixing WinKey+X menu change.

Getting Started: Fixing WinKey+X Menu Change

The first clue was that the Win+X menu wasn’t launching Windows Terminal correctly. Instead of opening a PowerShell or Terminal instance, it either did nothing or threw an error. That pointed to a problem in the Win+X shortcut groups. These reside beneath the user profile at:
%LOCALAPPDATA%\Microsoft\Windows\WinX

Windows organizes these shortcuts into GroupN folders (N = 1-3). Group3 is where Terminal and PowerShell entries live. When I opened that folder, those shortcuts were either missing or pointing to stale AppX registrations. This can happen after uninstalling or repairing Windows Terminal, or some profile migration wherein AppX package identities change.

Making Shortcuts Happen…

The next step meant rebuilding shortcuts manually. Windows Terminal doesn’t include .lnk files. Hence, I created fresh ones by right‑clicking the desktop and choosing New → Shortcut, and pointing them at the program. It lives under WindowsApps and includes current version info in its actual filename.

Because Windows Terminal’s AppX path changes with every update, hard‑coding its location isn’t smart. Thus, I used the stable execution alias: wt.exe

Once the shortcut was created, I renamed it to match canonical Win+X naming conventions:
Windows Terminal.lnk
Windows Terminal (Admin).lnk

Then I moved them into the Group3 folder. At this point, the shortcuts existed, but they were MIA on the menu. That’s because Win+X system caches entries and doesn’t refresh automatically. I forcibly rebuilt that cache by signing out and back in. After the next login, the menu finally displayed the new Terminal entries — but the icons were wrong.

What About Them Icons?

This led to the next discovery: Windows Terminal’s icon is stored inside its AppX manifest, not in a traditional .ico file. To fix them, I edited each shortcut’s properties and pointed the icon field to the stable Windows Terminal executable under Program Files. That exposed the correct embedded icon. Once updated, Win+X  displayed the proper visuals.

The final step was cleaning up legacy entries. A repaired Microsoft Account caused Windows to resurrect old Win+X shortcuts from a now-defunct installation. Removing stale .lnk files from Group3 eliminated duplicates and restored the menu to a clean state.

By the end of the trail, Win+X worked again: correct icons, correct commands, and a clean set of shortcuts that launch reliably. The repair reinforced something I’ve seen before in Windows troubleshooting . A system often holds onto old paths, old identities, and old assumptions long after underlying components change or go away. Fixing things means understanding where Windows stores its info, and updating each layer one by one.

If your Win+X menu ever starts acting strangely, a careful rebuild of Group3 shortcuts may be exactly what brings it back to life. Here in Windows-World you can always try. It might work. And if it doesn’t, there’s always something else to try instead.

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, PowerShell, Recent Activity, Troubleshooting, WED Blog

WinGet Weirdness Finally Whacked

Leave a comment

Every once in a while, Windows throws you a problem so strange, so deep in the plumbing, that you can’t help but treat it like a spelunking adventure. Over the past week, I’ve worked through one of those rare cases. Copilot ultimately helped diagnose it as a completely broken WinGet (aka Microsoft.AppInstaller) stack. Apparently, it came from corruption inside the WindowsApps directory. That’s the protected, TrustedInstaller‑owned home for all MSIX/AppX packages. I worked through a recovery  process that touched ACLs, reparse points, Safe Mode, user‑level activation, and the PATH environment itself. Ultimately and fortunately, it ended with WinGet weirdness finally whacked.

Getting to WinGet Weirdness Finally Whacked

The symptoms were deceptively simple: WinGet wasn’t recognized, App Installer wouldn’t register, and the user‑level WindowsApps folder lacked key shims. Alas, the root cause was far deeper. The system‑level C:\Program Files\WindowsApps directory had partially corrupted ACLs, preventing enumeration that blocked TrustedInstaller from working. Even elevated tools couldn’t see its innards.

The breakthrough came in Safe Mode, where Windows releases some of its usual locks. Using takeown and icacls, I forcibly reclaimed ownership and permissions long enough to inspect the directory. Hundreds of previously invisible entries suddenly appeared — confirmation that the ACL choke point had finally broken open.

From there, I rebuilt the directory’s security model: restoring SYSTEM and TrustedInstaller with full control, removing inheritance, and returning ownership to TrustedInstaller. With the system-level store healthy, I exited Safe Mode (after discovering that msconfig, not BCD, was trapping the machine there) and rebooted into normal Windows.

Repairing WinGet/Microsoft.AppInstaller

Next came the App Installer repair. The system package was still resident, but user-level registration was MIA. I downloaded the official MSIX bundle, reinstalled it, and then manually re‑registered the package using its AppxManifest. That restored the user‑level WindowsApps directory and recreated the shims — including winget.exe.

But one last puzzle remained: even with the shim present, Windows still didn’t recognize the command. The culprit turned out to be the PATH. During the earlier corruption, Windows had silently dropped this critical entry:
%LOCALAPPDATA%\Microsoft\WindowsApps

Without that, no packaged app alias can resolve. Adding it back with setx, signing out, and signing back in finally brought the entire chain back to life. winget -v lit up instantly.

In the end, the repair touched nearly every layer of the Windows package‑servicing stack: NTFS ACLs, TrustedInstaller ownership, AppX registration, user‑level activation, and environment variables. It was a rare, deep, and oddly satisfying recovery — the kind of fix you document not just for others, but for the story it tells.
And now WinGet is fully operational again.

I’m celebrating the occasional “happy ending” that’s so rare in Windows-World. If you’re lucky you’ll never have cause to do likewise. But if this ever happens to you, here’s a trail of breadcrumbs to lead you out of that forest…

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, PowerShell, Recent Activity, Troubleshooting, WED Blog

Diving Into Recovery Media Rabbithole

Leave a comment

I went down a number of dead ends yesterday, trying to restore WinGet to proper operation on my Flo6 AMD desktop. One of the more interesting and frustrating alleys I banged around in involved building bootable recovery media for Windows 11. At first,  I tried to get Copilot to steer me through, but found myself wandering in circles. So I turned to the built-in RecoveryDrive.exe tool. Diving into recovery media rabbithole took longer than I wanted, but gave me what I needed. I’ll explain…

Diving Into Recovery Media Rabbithole Requires Escape

Copilot had me formatting two partitions (UEFI: 1024MB; NTFS: rest of UFD), copying files, creating boot configuration data, and more. Only problem I had was that creation and management of the runtime environment ramdisk kept falling over sideways.

After my third failed attempt to create such a drive from scratch, I turned to the built-in Recovery Drive facility inside Windows 11 itself. (Visit Settings, search for “recovery drive” and it’ll take you right there.) This took a long-ish while to complete (about 45 minutes, all told). But it did what I needed it to do, and let me attempt AppX provisioning and repairs on a quiescent Windows image. That didn’t work out so well for me, but it did make it possible for me to learn some new PowerShell and Command Prompt tricks. I even got a couple of chances to dig into Safe Mode boot on my production desktop.

File layout for the Recovery Media looks like a typical Windows Setup disk (it can do that, too).

Desktop Fights Alternate Boot-ups: I Fight Back

At first, I was a bit stymied by the unwillingness of the Windows repair boot screen to field function keys (F1 for UEFI, F11 for boot menu, and so forth). But after a while, I learned how to work around those hurdles. Msconfig came in handy for getting into Safe Mode, while various flavors of the shutdown command let me access UEFI, alternate boot options, troubleshooting menus, and more.

The day was not a total loss, but it did throw me behind schedule on some project work. Today, I’m nosing the grindstone as I start to catch up. And isn’t that just the way things too often go, here in Windows-World?

 

Facebooklinkedin
Facebooklinkedin