Category Archives: PowerShell

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

Leave a comment

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
Insider stuff, PowerShell, Recent Activity, Troubleshooting, WED Blog, Windows 11

Primary Desktop: Something Profoundly Wrong

Leave a comment

I’ve been fighting dragons here at Chez Tittel all day long. On my primary desktop, something profoundly wrong is dogging my steps, and docking my productivity. I can’t boot to a recovery drive to fix a relatively simple problem with application package provisioning. Behind the scenes, something is amazingly weird, and blocking my every move to try to get things fixed. Let me explain…

More About Primary Desktop: Something Profoundly Wrong

It all started with WinGet. It (Microsoft.AppInstaller) wouldn’t update  properly . I went through a lengthy and trying series of misadventures (that took the best part of a full day). I only slowly determined the ed@edtittel.com account profile was thoroughly messed up.

First, I went through three iterations building a WinRE (Windows Recovery Environment) bootable USB flash drive. I realized something fundamental and serious was broken. Copilot says it’s not because of any of these:

  • Not a bad install.
  • Not a missing EXE.
  • Not a PATH issue.
  • Not a system‑wide problem.

Rather, it’s a borked reparse point. It’s coupled with missing shims inside user-level WindowsApps and Winget folders.

A Wilderness of Errors

Here are some of errors I’ve fought today:

  • “The system cannot find the path specified”
  • Winget working in one account but not another
  • App Installer reinstall not fixing anything
  • PATH looking correct but still failing
  • Winget.exe present but nonfunctional
  • Commands failing instantly with no useful error text
  • Ephemeral pop‑ups and disappearing error dialogs

TLDR: I couldn’t build a bootable WinRE UFD that worked. I’ve switched to another PC. Now, it’s the Lenovo ThinkStation P16 Gen1. It’s frustrating… But at last a bootable UFD via the Windows 11 Download page and msconfig to get into “Safe Mode” worked. That said, I never got WinGet working on my primary MSA.

An Alexandrine Solution

I’ve now been up and down, and back and forth, over the same ground. I can’t make WinGet work in my primary login. It works fine in an alternate MSA. After spending a long, long day trying to fix this, I am throwing in the towel. I can run WinGet from the old MSA, and for now, that’s good enough for me.

Sigh. Another wasted day (at least 8 hours) here in Windows-World. Sometimes, all the effort just doesn’t produce the desired outcome. It’s a real pickle!

 

Facebooklinkedin
Facebooklinkedin
Insider stuff, PowerShell, Recent Activity, Tips, Tricks and Tweaks, WED Blog

Copilot Assisted RAPR Analysis

1 Comment

Yesterday, I found myself revising a story for ComputerWorld. The topic: cleaning up Windows driver bloat using DriverStore Explorer, aka RAPR.exe. Along the way I found myself wanting to count the drivers in that store, and to identify duplicates for possible removal. Performing what I’m calling Copilot assisted RAPR analysis, I had it craft some Powershell for me. Came in really handy, so I’ll explain and illustrate what I used…

Enumerating Copilot Assisted RAPR Analysis Items

I used two one-liner PowerShell commands, plus one script, to do the following:

  • Provide a count for the number of drivers in the store (found in C:\Windows\System32\DriverStore\FileRepository)
  • Display the total file size of the store’s contents (same place)
  • Enumerate and identify the duplicates in the store (script)

These items are helpful because running the first two one-liners let me quickly count items and obtain their overall file size. Handy for before and after comparisons. The script was useful because it let me identify duplicates in the store, which RAPR does not always remove when you use the “Select (Old Drivers)” and “Delete Driver(s)” buttons for clean-up purposes.

If you look at the lead-in screenshot it shows the one-liners for making a count and getting size verbatim, and calls a script named dupdrv.ps1. The results also appear as well. These all represent post-cleanup results, FWIW.

PowerShell Details: One-Liners and Script

To obtain the count, PowerShell runs through all instances of signed PnP drivers in the store, and tots them up:

(Get-CimInstance Win32_PnPSignedDriver).Count

To get the size of the overall DriverStore, PowerShell examines each file, gets its size, adds it to a growing sum, then shows it in GB units:

(Get-ChildItem "C:\Windows\System32\DriverStore\FileRepository" -Recurse -File | Measure-Object -Property Length -Sum).Sum / 1GB

The script is longer and a little more complicated. Basically, it iterates through all files in the DriverStore, builds a table of unique entries by name, and counts all instances it finds. It reports only on instances that have counts of 2 or more (indicating duplicates).


pnputil /enum-drivers |
Select-String "Published Name","Original Name","Provider Name","Driver Version" |
ForEach-Object {
if ($_.ToString() -match "Published Name\s*:\s*(.*)") { $pub = $matches[1] }
if ($_.ToString() -match "Original Name\s*:\s*(.*)") { $inf = $matches[1] }
if ($_.ToString() -match "Driver Version\s*:\s*(.*)") { $ver = $matches[1] }
if ($pub -and $inf -and $ver) {
[PSCustomObject]@{
PublishedName = $pub
InfName = $inf
Version = $ver
}
$pub = $inf = $ver = $null
}
} |
Group-Object InfName |
Where-Object { $_.Count -gt 1 } |
Select-Object Name, Count, @{n="Versions";e={$_.Group.Version}}

These tools come in nice and handy when using RAPR to clean up a driver store. Indeed, they even extend its capabilities beyond finding old and obsolete drivers. They also identify duplicates as well. Sometimes, those too can be cleaned up. Good thing that trying to delete a driver in actual use in RAPR won’t succeed unless the “Force Deletion” option is checked. I don’t recommend using that unless you know you must for some good reason. I certainly didn’t need that here.

Benefiting from Copilot Assist

For updating this story, Copilot made it faster, easier and more convenient for me to do what I needed to anyway. That’s good. But it also let me step beyond what I’d been able to do by way of driver debloating in the past, and tackle duplicate elements as well. That’s about as good as things ever get, here in Windows-World. I’m jazzed!

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

ARM PC Throws Oh-My-Posh Curve

Leave a comment

There are lots of interesting wrinkles that distinguish ARM-based PCs running Windows 11 from their Intel- or AMD-based counterparts. Nothing huge or deal-breaking. Just interesting and sometimes, mildy vexing. In setting up Windows Terminal and PowerShell “the way I like it,” I encountered just such a wrinkle. Indeed, my new ASUS Zenbook A14 AMR throws oh-my-posh curve that took some research to work around. The lead-in graphic shows where I started out.

How ARM PC Throws Oh-My-Posh Curve Ball

I used the OneDrive connection through my common MSA (Microsoft Account) to inherit a lot of my local set-up and preferences. So it is with Windows Terminal and PowerShell, for which I like to use Jan DeDobbeleer’s excellent Oh My Posh (OMP) customization tool. Note the end of the prompt that shows up on the A14 in the preceding screencap: “CONFIG ERROR.” Not good!

In figuring out what causes this, I learned that the way ARM PCs handle some errors differs from AMD and Intel X64 CPUs. Indeed, the issue seems to come from a slight change in folder structures, where OMP expects x64 and doesn’t accommodate ARM automatically.

Fixing the CONFIG ERROR

Fixing CONFIG ERROR, in this case, is as easy as reassingning the folder from whence Oh-My-Posh reads its configuration file. This comes from changing where OMP gets its theme — namely:

oh-my-posh init pwsh --config "C:\Program Files\WindowsApps\ohmyposh.cli_
28.0.0.0_arm64__96v55e8n804z4\themes\jandedobbeleer.omp.json" | Invoke-Expression

Note: I broke this command across multiple lines for improved rendering. Be sure to suck it into a text editor and remove the line-break in the middle before trying this yourself.

To make this change permanent, one must run notepad $PROFILE at the PowerShell prompt, and replace the current path specification for the startup-theme.  That means the path specification in the OMP invocation line must match the one shown in the preceding command string. Save the edited profielss and thereafter, when Windows Terminal boots into PowerShell, it will use the right version of the theme file to avoid CONFIG ERROR.

As you can see, after making that config change, I ran winfetch in a new PowerShell/Windows Terminal session (for something to see). OMP no longer throws a CONFIG ERROR. Problem solved!

 

wing

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

Bringing OhMyPosh to Flo6

Leave a comment

Flo6 is what I call my new production desktop. Today, I finally got around to installing and turning on the OhMyPosh shell prompt tool on said desktop. I’ve done this before, and it’s always interesting to see how things work now, as opposed to the way they did the last time I did this. Indeed I hit some changes: nothing insuperable, but enough to make me stop and think about what I was doing, and how best to do it. In bringing OhMyPosh to Flo6, I had to overcome bogus Copilot guidance, re-read my own 2024 OhMyPosh article, and visit the OhMyPosh website to grab my preferred theme.

After Bringing OhMyPosh to Flo6, A Snazzy Look

If you examine the lead-in graphic you can see what adding OhMyPosh to the mix does for PowerShell inside Windows Terminal. It definitely adds to the visual appeal of the command prompt, and lets you see more info right away.

Here’s brief summary of the steps involved (all the deets are covered in the afore-linked OhMyPosh article, which I will henceforth abbreviate as OMP):

1. Install a nerd font (necessary for OMP to show its colorful symbols and glyphs)
2. Change the default profile in WinTerm to invoke that nerd font
3. Change PowerShell startup to call OMP and its theme on startup
4. Reload the startup info ($Profile variable) to invoke the new setup

In theory, this is dead easy. In practice, it requires a fair amount of command line jiggery pokery. The whole operation took half an hour or so, mostly because I had to remember (and read about) those steps and their details. OMP also no longer downloads its themes when it’s installed, so I had to visit the themes page and download the one I wanted (it’s named JanDeDobbeleer.omp.json) and put it in the OMP default folder (C:\users\<acct>\ohmyposh) to match the configuration in the associated profile info.

Eminently doable, if a bit more time consuming than I remembered. But shoot: that’s just another normal day here in Windows-World!

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

Winget Update Re-Raises Restart Requirement

Leave a comment

Late last April, I wrestled with getting winget updates (aka Microsoft.AppInstaller) to “take.” That is, figuring out how to follow the advice to “restart the application” so the new version could take over. Turns out that nothing short of a restart seemed to guarantee that the update would run in PowerShell/Windows Terminal. Other techniques — killing all active processes, open/close WinTerm, and so forth — did not always suffice. A recent Winget update re-raises restart requirement, as I tried to move from version 1.26.430.0 to 1.26.510.0. It was the same darn thing all over again!

Why Winget Update Re-Raises Restart Requirement

If you read into my April blog post that offered explanations from two winget mavens, you’ll see that the winget upgrade waits until dangling APIs and runtime modules, plus pending package updates, all get resolved before completing its own upward move. For the chronically impatient — including yours truly — that makes a restart/reboot a surefire way to FORCE the changes through as a consequence of shutting down, then starting back up.

It worked last April, and it still works now. But a restart on my production PC with its numerous peripherals and 6 drives showing in File Explorer, is no small thing. It takes over a minute to shut down, and another 2-3 minutes to get through restart and to the desktop. So while it does the job, it also makes me wait rather longer than I’d really like to.

But hey: that’s the way things go in Windows-World sometimes. When things change, waiting for “out with the old, in with the new” can take some time. Maybe I should go get another cup of coffee…

Facebooklinkedin
Facebooklinkedin