Category Archives: Cool Tools

Digging Into Massive DISM Delay

If I needed proof that “no good deed goes unpunished,” I got that yesterday. I was revising a story for Tom’s Hardware about fixing an IRQL BSOD. By way of example I ran a pair of DISM commands and the system file checker (shown at the end of this post). The second DISM command took a LONG time to complete and hung up at 62.3% complete. Then, when I jumped to another PC it did the same thing again. That’s why I’m digging into massive DISM delay this morning.

What Digging Into Massive DISM Delay Tells Me

A quick online search tells me I’m not alone. Indeed, there’s a Reddit thread entitled “DISM Restore health stuck on 62.3%.” It  confirms what I’d observed on my own PC — namely, that the delay is NOT a hang, and the command will complete . . . eventually.

Next, I ran down the logs that get written when DISM /RestoreHealth is underway. First, I found a 10-minute gap between one timestamp and the next in the dism.log file. Then I used the same timestamp when that delay hit to look at CBS.log. Sure enough, the repair was mapping Windows Enterprise to the Professional Edition. This was followed by at least 3,371 files opened and examined (some lines open 1, others 2).

Based on a screen’s worth of entries summed and averaged it comes out to 3371 * 1.42 =  ~4829 files in all. Obviously, that can take some time. The end of this activity explains what’s going on: “Repr: CBS Store Check completes.” Then a bunch of missing manifests or catalogs come in, with a large number of update downloads after that. Poof! 10 minutes is gone.

When DISM Gets Going, It’s Busy, Busy, Busy

So even though DISM /CheckHealth found nothing amiss, DISM /Restorehealth found itself with a lot of work to do. And that’s where the “missing 10 minutes” went. Seemed like forever, but it’s apparently a well-worn routine — if the Reddit post is any indication.

And boy howdy, isn’t that exactly how things sometimes go here in Windows-World? And I suppose I should be glad that all the current public Windows 11 release PCs experience the same thing. At least, it’s consistent . . .


X Now Marks the Twitter Spot!

It’s been more than two years since Elon Musk acquired Twitter on April 14, 2022. But only now — as you can see in the lead-in graphic — has started redirecting users to instead. I’ve been logging in via Twitter since I first joined up over a decade ago. But starting today, May 17, X now marks the Twitter spot on the web. The default question shown in the lead-in graphic adds an ironic twist to the whole affair, IMO. I have to chuckle…

If X Now Marks the Twitter Spot, Does It Matter?

I guess this redirect should last some while, so I probably won’t have to train my fingers to type instead of right away. But it’s not inconceivable that the switch should encourage people to shift away from the old domain name to the new one, either.

Out of curiosity I checked the market value of Twitter . . . err X, rather . . . this morning. According to Companies Market Cap, it’s worth $41.09B right now. Elon paid $44B for the company, and valued it at $19B on October 30, 2023. Obviously, it’s recovered quite a bit since then. It may not turn out to be the total disaster many feared after all. Time will tell, right?

X Still Stands. But In the Second Rank

According to Statista, X ranks 15th among all social media platforms worldwide. Its user base is far behind the top 5 (Facebook: 3B+, YouTube: 2B+, Instagram: 1B+, WhatsApp: 1B+, and TikTok: 1B+). But somehow, X keeps going and keeps working. I still find it a valuable source of Windows news and info. Indeed it works better for me than any of the preceding top 5 for my particular interests. Obviously, these interests are more specialized than the teeming billions covered en masse in those services!

Here’s a shout-out to Laurent Giret at, whose X item there this morning alerted me this changeover. Thanks!


WinGet Updates Quiescent Browsers Best

Here’s one to ponder. Just this morning, in going through a gaggle of WinGet updates, I noticed something interesting. WinGet will happily install browser updates on Windows PCs, whether or not the target browser is running. But if that target is not running, it will invariably succeed and leave the program ready to run it’s newest, best self the next time it’s called. When run against running browsers, though, WinGet will often be unable to finish the job completely, despite reporting installation success. Hence, this epigram: WinGet Updates Quiescent Browsers Best.

What WinGet Updates Quiescent Browsers Best Means

Over the past 3 years or so, I’ve gotten pretty darn familiar with WinGet, Windows’ built-in package manager. It’s bundled into Windows 11 and easily available through GitHub (microsoft/winget-cli). I use this tool pretty much every day to check for updates on my fleet of 10-12 Windows PCs here at Chez Tittel. And as I use it, I get the chance to observe and report all kinds of issues and oddities, both large and small.

This is a pretty small one, as it turn out, but worth noting even so. What happens if you don’t exit a browser before using WinGet to upgrade same? It varies. Chrome will sometimes stick stubbornly to its pre-upgrade state, and require an in-app update to catch up. Firefox may require you to “Relaunch” the browser to finish things up completely. Edge does a good job of self-updating but also works well with WinGet (as you’d expect, as they’re both MS software).

Is This Just “Same-old, Same-old”?

Yesterday, I wrote a post entitled When WinGet Balks, Try In-App Updates. In a small way, this post is a further musing on some of the same themes. But because I leave browsers open on the desktop all the time — as do many other users — this one is a more focused and directed play on the same general topic.

And isn’t that just the way things sometimes (or even often) go, here in Windows-World? At least for me, anyway…


When WinGet Balks, Try In-App Updates

OK then, I’m still working my way back into the groove after 8 days of vakay. Yesterday, I started running WinGet upgrade … on the whole fleet, to get things caught back up. I quickly noticed that WinGet wanted to update a slew of stuff, including MS Teams and MS PC Manager. But on at least a couple of test PCs, WinGet wasn’t up to those tasks. I quickly remembered that when WinGet balks, try in-app updates often works. And indeed, it did the trick for both those items.

Remember: When WinGet Balks Try In-App Updates

Most often when I see a WinGet upgrade fail to update an app, it’s because the app is running and something inside its runtime environment won’t let go of some resource necessary to bring the update to a successful finish. Apparently, that was the case for both Teams and PC Manager yesterday, where I could see a valid version mismatch between what was running and what WinGet wanted to install.

You can see what I wound up with in the lead-in graphic after I ran the in-app update function for both programs. They show the “latest and greatest” versions for Teams (left) and Microsoft PC Manager (right) up and running. It took me a minute to recollect the right approach, but it was dead easy to implement once those neurons had fired.

If this technique works for me, it can work for you, too. Enjoy!


Dev Home Environments Missing Local ISO Access

As far as I can tell the ability to create and manage Hyper-V VMs using the latest release of Dev Home (Preview) is nothing short of terrific. Whereas Hyper-V Manager makes it difficult or blocks use of RDP during VM set-up and install, Dev Home is completely friendly to this oh-so-common way to get stuff done on Windows networks. I have 8 PCs (1 desktop, 7 laptops) in  my office right now. I work on the desktop and RDP into the other machines as a matter of course. Alas, I suffer with Dev Home Environments missing local ISO. Let me explain…

Why Say: Dev Home Environments Missing Local ISO Access

I could be wrong, but I don’t see any way to access a local image source on the “Choose an image to use*” pane when setting up a Hyper-V VM inside Dev Home. If you look at the lead-in graphic you’ll see dev options for Windows 10 (top) and 11 (bottom) with three Ubuntu items inbetween. That’s it!

Given Dev Home’s focus on developers and developer environments, this may make sense. But given that Dev Home works seamlessly and properly in an RDP session, and Hyper-V does not, it makes me want more. Specifically, it makes me want the ability to use a local ISO file of my choosing as the basis for a Hyper-V VM when I click the Create Environment button in Dev Home.

Why? Because it “just works” in setting things up and getting them running. Working with Hyper-V Manager to create VMs through RDP is tricky and frustrating. Working with Dev Home to create VMs is an absolute breeze.

A Different Alternative: Fix Hyper-V Manager

If MS doesn’t want to add a local filesystem link to this aspect of Dev Home, that’s OK. But if so, they should fix Hyper-V Manager so that it works properly with Windows 11 (default to TPM support, turn off Windows hello login that doesn’t work on RDP). Is that too much to ask? Gosh, I hope not!


Hope MS Makes Good on Classic Teams Uninstall

I’ve got to admit: I’ve lost count. I’ve seen oodles of updates and versions of Teams come and go on my various Windows 10 and 11 PCs lately. Take a look at Monday’s MS Teams article “End of availability for classic Teams client.”  Among much other stuff it says “This rollout involves installing the new Teams client for users who still have the classic Teams client, with Microsoft attempting to uninstall the classic Teams client 14 days after the installation of new Teams.” Gosh, I hope MS makes good on Classic Teams uninstall promises.

Why I Hope MS Makes Good on Classic Teams Uninstall

I’ve tried uninstalling Classic Teams on Windows 10 PCs and VMs. (Note: I do NOT have this issue on Windows 11 PCs of any build or version, stable or Insider Preview channels.) But it often returns to those Windows desktops on its own, through means mysterious and marvelous. In short: it’s attaining zombie-like status except it doesn’t relentlessly chant “Brains! Brains! Brains!”

Better (or worse) still, when I try to use Teams on Windows 10 (it’s still my production work environment), Classic tends to come up by default. I know why — it’s because I use MSAs that aren’t part of an AD/Entra domain — but it’s still irksome.

Gosh! I’ll be glad when July 1 comes and goes and I get to see if the zombie that is Classic Teams will finally get exorcized — err, uninstalled — from my Windows 10 PCs and VMs. Stay tuned! I’ll keep you posted. Fingers crossed, in the meantime. . .

Results from Remove/Replace Operation

Just for grins, I used Revo Uninstaller to get rid of all Teams traces on my production PC. Then I went to the MS Store to download and install its latest version. When I launched for the first time, it asked me if I wanted Teams (New) or Teams (Classic). I chose (New) and now it comes up in the Start menu with no Classic companion. I’ll keep an eye out and let you know if Classic lurches back to life!


IPRI Hits Production Windows 11

I’m not sure exactly how long this has been true but Copilot agrees with me that it first appeared in 23H2 Build 22631.3447. Release date for that build: April 9, 2024. It had been available in Insider Previews since earlier this year, but this is when in-place repair install (IPRI) first showed in a production release. Now that IPRI hits production Windows 11, it’s ever so much easier to let WU provide the files to make that happen. Good stuff.

What IPRI Hits Production Windows 11 Means

Before this facility appeared in various Windows 11 versions, the only way to conduct such a repair was to use to build an ISO that matched the current installed Windows version, then mount same, and run setup.exe from its root-level folder (see red-boxed item in the screencap following):

IPRI Hits Production Windows 11.setup.exe

The old-school IPRI method requires an ISO for the same that’s running, then launching setup.exe from its root-level folder.

Now, with this change you need only navigate to Settings > System > Recovery, then click the “Reinstall now” button as shown in the lead-in graphic. Windows Update does the rest. It does take a while (50-60 minutes in recent test runs for a ComputerWorld story) but that’s because it has to download all the component files, then build and update an ISO. Adding install time to the time takes to create the ISO, it’s pretty much a wash.

And again: it’s ever so much more convenient and automated. Big win for Windows users everywhere. Thanks, MS!


Busy Week Brings 9 WinGet Updates

It’s been a busy week, so I’ve been doing stuff more, and playing less with Windows. How do I know? I just ran WinGet on my production desktop and it tossed up a new personal high. That’s right: my busy week brings 9 WinGet updates to my Windows Terminal PowerShell session. You can see the intro part in the lead-in graphic. Wow!

When Busy Week Brings 9 WinGet Updates, Install Them

So that’s what I’m doing right now, as I write this blog post. The whole 9 items took about 2 minutes to complete. It brought 8 successes and one failure. Because I have numerous M365 components open right now, the M365 Apps for Enterprise install failed. That’s probably because I’m using a different subscription version tied to a different MSA. The one I’m using cheerfully reports itself all caught up.

It’s the one I’m NOT using that reports itself out-of-date (which is perfectly OK, because I’m not using it. Maybe I should remove it?) Isn’t it funny how using multiple MSAs in a Windows PC can occasionally make life interesting when you login with one such account, and use assets tied to another such account?

It’s All Part of Windows’ Inestimable Charms…

Learning where the eccentricities reside or potholes lie, and steering around them, gives me countless opportunities for learning and enjoyment when it comes to working with Windows. But less so than usual this week: I’m busy. In fact, I need to go do some paying work as soon as I’m done here. Cheers!


PowerShell Install Goes Cancelled to Abandoned

Here’s a good one. Take a look near the bottom of the lead-in graphic. It shows what happens at the end of a WinGet upgrade sequence with the PowerShell installer. But whereas that installer used to say “Installation cancelled” it now says “Installation abandoned.” Hence my assertion: PowerShell Install Goes Cancelled to Abandoned. In truth, this simply means the Windows Terminal window must be closed and re-opened for a new PowerShell version to take effect.

What PowerShell Install Goes Cancelled to Abandoned Means

Things get interesting when a program that’s currently running gets updated. Generally, for the code to take over from the old, the old must first stop. Then, the new must start up and run, so it can use all of its newly-minted capabilities and capacities. The “cancelled” and “abandoned” stuff is text for an error message that indicates the installer itself had to terminate in some kind of unexpected, unusual, or surprising way.

Look at what comes up when I close Windows Terminal, and then re-open it. Just for grins, I add WinGet list microsoft.PowerShell and another WinGet upgrade … check. The former shows the new version is present (as does the lead-in prompt above it). The latter shows that a new WinGet check no longer reports that PowerShell needs an upgrade. Case closed!

PowerShell Install Goes Cancelled to Abandoned.follow-up

The new PowerShell version is running so it no longer generates an update notification. [Click image full full-size view.]


PowerToys Puzzle Locks Together

Last week I blogged about how two quick back-to-back Powertoys releases seemed  to have left WinGet one release behind. No more! What I described as an “interesting PowerToys Puzzle” was indeed a function of lagging manifest updates. This morning,that former PowerToys puzzle locks together as you see WinGet update it from v0.80.0 to the current v0.80.1 in the lead-in graphic.

After PowerToys Puzzle Locks Together, WinGet Gets It Right

If you look at the top block of text in the lead graphic, you’ll see WinGet  recognizes the PowerToys version 0.80.0 needs an update to version 0.80.1. And indeed, that’s exactly what WinGet does in the center block of text just below the list of possible/pending updates that WinGet finds.

I did get a reply to the afore-linked April 11 blog tweet from WinGet team lead Demitirus Nelon. As I had guessed there was a lag between the second release and the WinGet manifest definitions. And it was apparently a completely routine fix, too.

So now, when the “What’s new” document shows v0.80.1 in its lead paragraph that actually agrees with the version that’s running on the target PC. Ain’t it great when things work the way they should? Three cheers for the PowerToys and WinGet teams for working quickly and accurately to fix this sooner rather than later.

I continue to be impressed with the dispatch and dedication of these folks. All I can say is “Keep up the good work!” I’m enjoying being part of the process.