OK, then. Yesterday I blogged about seeing no upgrade to WinGet until after a PC restart. It turns out that is indeed one way — but not the only way — to ensure that WinGet will upgrade itself from one version to the next. In this case it was moving from Version 1.25.340.0 to 1.25.390.0.  Why did I restart? Because I closed, then re-opened Windows Terminal several (3) times with no intervening change in WinGet versions. Thanks to feedback from WinGet team lead Demitrius Nelon and Senior Software Engineer John McPherson, I now know why restart guarantees WinGet upgrade. I also know why a restart may not be needed, and about possibilities for upgrade hangups. Let me explain…

Here’s Why Restart Guarantees WinGet Upgrade

Thanks to an invitation from the development team, I’m a member of an MS Teams chat called “WinGet Community.” I posted info about my observations and a link to yesterday’s blog there, and got some useful and interesting information from the aforementioned folks that provide a pretty detailed explanation of what I experienced, and why it happened.

First, here’s how Demitrius responded to my report and inquiry:

Hey Ed (Guest), when WinGet is updating “packaged” applications (MSIX Installer), it’s using deferred registration. It may take a few moments for the registration to complete before WinGet is updated (App Installer package) when WinGet is the thing currently running updates . That means WinGet essentially needs to completely finish what it’s doing before the delayed registration happens. A reboot which requires a user to log in (and that triggers the “registration” part of the MSIX lifecycle) will ensure all MSIX packages are up to date. In some cases there may be a few second delay when winget upgrade –all was used to update WinGet itself.

I’ll talk with the team to see if there is a reasonable way to diagnose this a bit better, and if the performance is suffering, we might need to look into some other “special” handling for this specific scenario.

We were hoping to avoid any logic in WinGet like “if package == foo” then do something special.

In some cases, a user may be actively running an MSIX package GUI based application. WinGet could upgrade the package to a newer version, but it wouldn’t be applied until the currently running instance was restarted.

That’s why the message is “Restart the application to complete the upgrade.”. We just don’t know if the application is running or not. In the case of App Installer / WinGet, a user could be in the middle of installing a sideloaded application which also could have it “tied up” from having the latest version registered for the user.

Restart application should not mean “reboot”. Some applications specify a reboot is required, and that’s when WinGet would display “reboot required”.

So essentially, what Demitrius is saying is that WinGet waits until all other pending package updates finish before allowing its own registration to change and its own update to complete. I was probably not waiting long enough for all the pending items to complete. That said, he also explains cases where such completions might not happen until (or rather, after) a restart occurred.

And Then, There’s a COMplication possible…

John McPherson observes further that:

Note that all packaged processes must terminate for the next process launch to then register the new version.  So any outstanding COM objects keeping the server alive will block that.  This could be due to PowerShell cmdlets and the GC not running due to no memory pressure.  Or it could be other services on the machine using COM.

So it appears there could be stuff running in the background that might stymie WinGet’s own auto-upgrade. Thus, it sounds like a restart is a reasonable workaround if and when WinGet attempts to upgrade itself, reports success, but the version number doesn’t increase. Waiting isn’t an unreasonable thing to do, but if the wait gets too long, a restart will force the WinGet upgrade to go through.

Thanks, guys, for the great information and explanations. It’s good to know what’s going on behind the scenes when WinGet handles multiple updates in a single go. In yesterday’s case, 5 items were upgraded, including WinGet itself, but also OhMyPosh, Teams, WinScript, and more. Of that batch, I’m pretty sure WinScript has interesting COM connections. Thus, I can speculate that the old three-fingered-salute (a restart, in this usage) resolved a stuck situation. As the old saw goes: “There’s no school like the old school.”

Whoa! Things are getting pretty esoteric. Via Reliability Monitor, I just got caught in a File Explorer AppHangB1 AppHang81 gotcha. But first, let me explain that following last Fall’s cataract surgery, I can’t see the fine print without my reading glasses anymore. I cheerfully confess I can’t see the difference between the “B1” and the “81” parts of those Problem Event Names in ReliMon unless I put my glasses on. So I have to laugh.

Overcoming Explorer AppHangB1 AppHang81 Gotcha

I looked up the error code — which I initially read with the “81” suffix — using Copilot. I immediately wondered why it had two paragraphs about the same topic (see below). Then it hit me: I needed better visual acuity to see and understand what Relimon and Copilot were trying to tell me.

Upon closer examination “8” and “B” are close, but NOT the same!

Once IDed, It’s Neither Scary nor Well-Lit

Further research into these AppHangB1 and AppHang81 errors isn’t terribly helpful. From what I can tell, this happens sometimes and may or may not be fixable using standard troubleshooting techniques:

• Apply pending updates
• Run System File Checker (sfc/scannow)
• Disable Third-Party extensions (NirSoft ShellExView is a common culprit)
• Try a clean boot
• Check Event Viewer for more details

If the error kept recurring, I might be inclined to go to such lengths. But over the entire ReliMon window (30 days) it’s happened exactly once, 10 days ago. I’ll keep an eye out. If it happens again, or starts to repeat, I work my way through that standard sequence. Right now, I’ll treat it as a one-off and scratch my head.

Looks like I need to remember to don the old reading glasses when trying to decode fine-print info like ReliMon’s error details. I’ve got the screen jacked up to 125% magnification but sometimes, that’s not enough. Is this the OS’s way of telling me that Windows 10/11 is “no country for old men?” I hope not…

As you may know I just resumed work after a 9-day hiatus over the weekend. As part of my catch-up process I’ve been using WU, WinGet, PatchMyPC Home Updater, Intel DSA, Snappy SDIO and some other odds’n’ends to make sure all 10 of my available Windows PCs (and an equal number of VMs) are all caught up and current. Call a 2025 fleet preparations maneuver, as I expect to return to mondo crazy work levels next week.

What’s Involved in 2025 Fleet Preparations?

Basically, this involves running various update checks to make sure what’s running is at current release levels. Here’s what I observed for the aforementioned tools while working through that process on my decade of physical PCs:

WU: no major pending updates, routine Defender stuff, one restart
WinGet: it found anywhere from 4 (low) to 11 (high) pending updates in need of handling
PatchMyPC: Managed the 8GadgetPack to GadgetPack switchover, also updated FileZilla on some PCs
Intel DSA: Found pending Wi-Fi, Bluetooth and Intel graphics updates for most machines
Snappy SDIO: did the trick to upgrade Bluetooth on one PC where DSA kept trying and failing to complete. Go figure!

I also found some new updates via Lenovo Vantage, primarily for newer PCs (2022 or after). Surprisingly the Lenovo ThinkPad X1 Extreme Gen8 (2018 vintage) also got some unexpected updates as well.

The whole thing took me the best part of a day to work through. But now, I feel Windows-Ready for 2025.

What’s Next?

On those PCs that don’t get backed up automatically, I’ll make sure there’s a final Windows image for 2024 before we slip into 2025 at midnight tonite. Happy New Year, everybody!

Now that I’ve used the “oh-my-posh enable upgrade” command to enable auto-upgrades on my various production and test PCs, I need to know how to check which version I’m running. Indeed, I’m conducting what I call an “OhMyPosh version check plus” on those machines, to make sure everything is up to snuff. Along the way, I’ve learned a few things…

Conducting OhMyPosh Version Check Plus

The — version parameter shows which version of OMP is currently running, as you can see in the lead-in graphic. This confirms that the “enable upgrade”  command is working and that I’m running the most current version. You can always double-check by visiting the OMP GitHub repository and matching up with its latest release info.

You can see that the “Latest” version value matches what’s installed.

I really, really appreciate all the great work that developer Jan DeDobbeleer has done to make this environment attractive, stable, and easy to use. All I can say is keep up the good work!

Holiday Check-Out Starts Tomorrow

I’m taking some time away from blogging and work to enjoy the end-of-year holidays with my family. That starts tomorrow. I’ll be back on December 28, ready to bag and describe Windows issues and answers as they strike me. Let me wish you and yours the best of times, ample relaxation, and lots of good eats as we go off to do our own things until then. Cheers!

If you look over my blog posts for the past few days, you’ll see I was trying to get the Lenovo ThinkPad X1 Extreme (2018 8th-Gen i7, etc.) from 23H2 to 24H2. I provide a list of links and capsule summaries to those item below. But the reason I’m puzzled is that manually applying KB5046633 took me from Build 22635.4460 (23H2 Beta) after which using the Installation Assistant took me to Build 26100.1742 (24H2 GA/Production). That’s supposed to be impossible. Thus, it’s got me pondering apparent Windows 11 build fork jump that somehow occurred.

Installer Oddity Has Me Pondering Apparent Windows 11 Build Fork Jump

I didn’t think the installer let one jump from Insider Preview versions (Beta Channel, in this case) to GA/Production images. But something I did — I think it’s the manual application of KB5046633 — let that happen. Once I got there, though, I was stuck. I couldn’t repair install my way to either the current GA Build (26100.2314) or its Beta Channel counterpart (22635.4510).

I can only surmise that I somehow slipped a version check. It might have happened when using the afore-linked KB item. Or, it could’ve happened when running the Windows 11 installation assistant after that. Truth to tell, I was relieved when my final repair operation hit a dead end, and the Windows Installer basically forced me to clean install Windows 11 from scratch.

Factor 1: Multi-Version Manual KB Installs

Indeed, KB54046633 works on both 23H2 and 24H2 based Beta Channel versions. The upgrade path from one to the other doesn’t necessarily need the full-blow installer (including the Installation Assistant). Indeed, Copilot tells me that when I applied KB5046633 it could’ve upgraded me from 23H2 to 24H2. But it did not.

Factor 2: Using the Windows 11 Installation Assistant

When I ran the assistant, that’s when the fork jump actually occurred. And again: I didn’t think it was supposed to work at all, let alone the way that it did. That’ s how I found the X1 Extreme enrolled in the Beta Channel but showing a GA/Production Build number.

The moral of this story is to limit yourself to the kinds of upgrade techniques you elect to use. Thank goodness these were all well-backed-up, non-essential machines. This could turn into a real snake pit for those not aware of such potential pitfalls. Me: I enjoy fallling into them, and then figuring out how to get to a better place. Thus, I hope you can learn from my mistakes … errrrr … adventures here in Windows-World.

Here are links to my previous blogs in this series with capsule summaries:

• Nov 12 X1 Extreme Still Gets No 24H2 Offer: explains that this 2019 vintage laptop is still on some kind of update hold
• Nov 13 X1 Extreme 24H2 Beta Pickle: Explains the sequence of updates that got me from a 23H2 Beta Build to a 24H2 GA Build
• Nov 14 MSA Switch Brings Standard 24H2 Aboard: Explains how changing to a non-registered MSA produces only clean install option for 24H2.

Gosh this has been interesting and educational, too.

I knew it remains a possibility. And I’ve seen it myself, from time to time. But this morning, I got slapped in the face with it: Copilot still hallucinates occasionally. I’m assembling parts to migrate my production desktop over from a 2016 vintage i7 Skylake desktop rig. I’m moving to a snappy 32-core Lenovo ThinkStation P3 Ultra. I need a lot of storage for that setup, so I asked Copilot the question in the lead-in graphic: “What’s the highest-capacity 2.5″ hard disk available right now?” I was stunned by the answer at at first, then…

Showing Copilot Still Hallucinates Occasionally

I’ve got a couple of Seagate 5TB HDDs here at Chez Tittel. I purchased them 3 years ago. At the time, they were the biggest 2.5″ drives available. And as it happens 5TB Seagates are STILL the biggest 2.5″ models for sale today.

Follow the link to the Tom’s story cited in the Copilot response. Then jump to Amazon for that Seagate IronWolf Pro 20TB item. Guess what? It clearly says “CMR 3.5 inch SATA 6 Gb/s, 7,200 RPM, 256 MB Cache” in laying out that drive’s specifications. It’s not a 2.5″ drive, period.

The good news is: if I want to use a 5TB 2.5″ HDD in this rig, I’ve already go two of them. The bad news is they’re pretty slow, as old-fashioned mechanical storage media can’t help but be. But there’s another hope!

Given the 5TB Limit, I consider 4 TB NVMe

Gosh, there’s not much capacity difference (25% figuring up, and 20% figuring down) between a 5 TB HDD and a 4 TB NVMe SSD. I’m coming around to the idea that I should buy a 4 TB NVMe for my second storage slot in the P3 Ultra. Decent models are available for around US$300, while the 5TB Seagate HDD costs US$233 or so. This provides roughly 10X the speed for 130% of the price. That’s a good trade-off. I’m still thinking but now I know how I’m leaning.

In the meantime, keep checking those blithe and speedy Copilot answers carefully. You wouldn’t want to be misled. Here in Windows-World it’s smart to stay skeptical, and double check what AI tells you.

When is a Windows app not really a fully standalone piece of software? When it runs as an extension of the Edge environment. To be more specific: when it’s the Windows 10 version of the MS Store Copilot app. I found myself in login lockout because Copilot was using my base-level work MSA as its login account, and it only works with so-called “personal MSAs.” Only after a fair bit of searching did I discover I needed to change my default Edge profile to get Copilot to run. With apologies to Milan Kundera, I see this as a case of unbearable Windows 10 weirdness: Copilot + Edge, when the latter comes as a kind of unexpected surprise.

Deciphering Unbearable Windows 10 Weirdness: Copilot + Edge

My real issue was that I suddenly couldn’t log into Copilot. It said I was using a work MSA (it’s the base of my current production login account, in fact). It offered a “Switch account” option, too. But try as I might, I got exactly nowhere working through the MSA interface via Copilot. It kept looping back to the same place, and I remained stuck.

Naturally, I turned to Google using “can’t login to Copilot” as my starting point. Only after some serious rooting around in MS Answers and other similar online communities did I find a fix. It showed up in this MS Community thread Windows Copilot Is Not Working. Therein a self-professed “IT technician” observed that “you have to delete your Edge profile and then it works fine.”

That’s not exactly true. But it is an important pointer in the right direction. If you define or switch away from a work or school MSA to a personal MSA it works that way, too. I had to set up a personal MSA profile for the account shown in the lead-in graphic, then switch to same. After that, no more problems circling around my work MSA with no traction. To be more direct: after the switch, the Copilot app resumed working.

When they say “The Devil is in the details,” I am pretty sure the MSA stuff falls under that rubric. And for what it’s worth, so also does the MSA vis-a-vis MS Teams logins. Just another day in the paradisaical paradoxes of Windows-World.

Having finally round the “round tuit” needed to check, I came to a stunning realization this weekend. As this blog post’s title reads: Copilot+ PC backup options are scarce. “How scarce?” is the next and inevitable question. Scarce enough that my fave tool — Macrium Reflect — throws an error when I attempted to install it. But it gets worse…

It’s True: Copilot+ PC Backup Options Are Scarce

Here’s a test to ponder: Tim Fisher’s November 2023 Lifewire story 32 Best Free Backup Software Tools gives us a lot of options for free Windows backup tools. Of those 32, take a guess as to how many can back up an ARM-based Copilot+ PC?

I didn’t want to guess so I asked Copilot to check for me with this query: “Of the Windows backup packages cited in this article <URL>, which ones will run on a Copilot+ PC with ARM Snapdragon X CPU?” Of all 32 items mentioned in the story, none qualified. Instead, Copilot recommended Fullback Pro and the old. long-deprecated Control Panel item: Backup and Restore (Windows 7). Indeed it cites an ElevenForum thread to explain how to do this. Approaches also include using DISM to capture (and then restore) the ARM64 Windows 11 image at the command line. Sheesh!

Google Does Better Than Copilot…

With the search string “ARM64-compatible Windows backup software” Google produces more and arguably better results than Copilot does. Most properly-endowed packages cost money. Indeed, I predict it’ll be a while before the freeware/donationware items mention in Fisher’s Lifewire story catch up. Indeed here’s further detail from the Macrium Support team about why MR8 does not support ARM systems:

ARM systems are not supported in reflect for the following reasons:

1) Can’t create snapshots
2) Can’t create a working rescue environment
3) Install CBT and your computer will BSOD on boot

With this, we have decided to block installs on ARM systems to prevent the software from bricking your machine

I suspect many other backup software vendors are up against the same kinds of things. I detect a “wait and see” stance that seeks to determine if the Snapdragon X Copilot PCs represent something real and enduring, before committing resources to supporting them.

What IS Out There?

Here’s a short list of packages that assert out-and-out ARM64 support:

• Zinstall FullBack (Copilot was right about this, as it turns out, though it’s under new ownership). It’s also a monthly service that starts at US$14.90 per PC.
• Veeam Agent 6.0 (backs up files on an ARM64 CPU, but only an AMD64 PC can initiate and drive a restore). Cost: ~US$130/year per deployed production agent.

At present, that’s all I can find. There’s nothing mentioned at the ver (Windows ARM Software) aggregration page. It seems pretty bleak at the moment, in fact.

But Wait: There’s More (or Less)!!

The same situation also applies to disk partition/disk management tools and for many of the same reasons: a lack of low-level drivers to interact with the Volume Shadow Service (VSS) on ARM64 systems running Windows 11 (or 10, for that matter). This is turning out to be more interesting and potentially vexing than I thought. Stay tuned! I’ll keep digging.  And it looks like ComputerWorld wants a short news item about this situation as well. Stay tuned!

As of October 8, Macrium Reflect X Goes Public

My favorite imaging backup, restore and repair utility — Macrium Reflect — dropped its latest version (X, as in the Roman numeral) on October 8. Among its many new capabilities, it supports ARM CPUs (and is running on my lone Copilot+ PC with Snapdragon X processor right now). It also runs noticeably faster than version 8 and has a few other new tricks up its sleeve as well. Visit the Reflect X is here! page for all the deets…

As for myself I’ve been using the beta version since late August/early September with great enjoyment and success. Although the company has transitioned from a perpetual license plus maintenance to an annual subscription approach, I just happily paid US$200 to get onto the Reflect X bus for the period through August 2024.

I have to laugh. There’s a new version of PowerShell (7.4.3) in town, and WinGet is now picking up that update. As has been typical for some while, the upgrade goes A-OK until the last steps. Then, as you can see in the lead-in graphic, it says “Installation abandoned.” Skip a line, then it says “Cancelled” before the prompt returns. With tongue in cheek, I see this as a PowerShell auto-upgrade abandonment issue. The upgrade actually works: the text updates in Terminal don’t match up with reality.

Refuting PowerShell Auto-Upgrade Abandonment Issue

Here’s another, more colorful screencap from a different test PC. Up top it shows the same info as in the preceding screencap. But because I used the magic keyboard shortcut ALT+SHIFT+- (minus key), the Terminal window is split horizontally. Notice the PS self-ID at the top of the lower pane: PowerShell 7.4.3.

After the install, if I open another pane below, it shows version 7.4.3. Update success! [Click image for full-size view.]

Clearly the new install has neither been abandoned, nor has it been cancelled. The old 7.4.2 session simply can’t report successful completion of the upgrade because it’s running the older version, not the newer one. The fix is easy: close the old pane/session. All new panes or sessions will show the new version. But until that pane is closed, the old version keeps running.

It’s just one of those interesting things when a running program seeks to update itself (or to have the package manager inside its embrace do likewise). Pay no attention to the man behind the curtain. The update works!

The GitHub Alternative

It takes a day or two after a new PS comes out before WinGet picks it up. For those who wish to jump sooner, a visit to the GitHub PS page — where you’d follow the Latest release link to get an .msi download (or whatever version your PC or VM requires) — makes sense. It also avoids the reported self-update shenanigans entirely.

But hey! Those shenanigans are exactly what I like to observe and try to understand. It’s just another one of the little things that makes life in Windows-World such a hoot.