Here’s a nifty little gotcha. After upgrading my two Dev Channel test PCs earlier this week, I noticed something missing. As you can see in the lead-in graphic for this story, despite Insider membership in good standing beforehand, things were different afterward. Hence my warning: Build 25174 may drop Insider MSA info, as shown in the graphic. Both of test machines were likewise affected.

If Build 25174 May Drop Insider MSA, Then What?

If you click on the “Please link…” entry shown in the graphic, it will automatically open the “Sign-in” page that lets you choose the MSA (Microsoft Account) you wish to associate with the Insider build on the target PC. I simply picked the one I had already associated with the PCs before applying the upgrade. It took all of 15 seconds to fix.

So why am I telling you this? I can’t extrapolate from 2 machines to the entire Dev Channel population. But I can guess that if both my machines were so affected, other Insiders running Dev Channel builds may find the same thing when they check their Insider status after the upgrade.

Nothing ventured, nothing gained, right? This reminds me of other oddities I’ve seen post-upgrade for earlier versions of Windows 10 and 11. For a long time, in fact, I had to check “Private” vs “Public” network status after such upgrades, and routinely reset them to my desired states. This strikes me as just another case in point.

Nothing in the 25174 announcement…

I just checked the 25174 announcement, and it makes no mention of this particular gotcha. I’m reporting this to feedback hub as I write this item and I see no similar reports amidst that collection. Perhaps this is idiosyncratic and only applies to my PCs. But I bet it’s not, so check yours, too, please. Cheers!

Interesting! As is my usual practice, I just installed KB5015882, the upcoming CU preview. It targets production Windows 11, and takes it to Build 22000.832. After that update and restart, I noticed two things. First, this PC was still running the old Windows Terminal version. Second, Windows Store offered me an upgrade for same, but it got stuck during the process. After forcibly closing Store, and returning to the same page, a Store reinstall solves stuck Terminal once and for all. Deets follow, and a general approach to app repair.

Praise Be! Store Reinstall Solves Stuck Terminal

To begin with, when I ran Windows Terminal, I noticed it was still running an old version (no access to Settings, nor various supported command line environments). When I visited the Store, and searched on “Windows Terminal” its app page hung while trying to upgrade that very tool. So I terminated the whole shebang by clicking the close button at upper right.

Just for grins, I ran winget upgrade --all. It did not upgrade my Windows Terminal install, though it found and updated numerous other items successfully. Go figure!

Then, I opened the Microsoft Store again. I repeated my search on “Windows Terminal.” Lo and behold, it offered an Install button this time. When I clicked that option, it downloaded and installed the latest version. As you can see from the lead-in graphic above, the result was a current version of Windows Terminal, which runs PowerShell version 7.2.5 by default. Fixed!

When Windows Apps Get Wonky…

When apps start going sideways, I go through a drill to clean them up. This drill consists of the following steps:

1. 1. Visit the Store, look up the app and see what it offers. Apply any resulting upgrades or installs. If this doesn’t work, go on to
   2. Use PowerShell and Winget to find the name of the package for the app in question. Here,  winget list terminal reports that name is Microsoft.WindowsTerminal.
   3. You can use winget to uninstall, then reinstall the package as follows:
      winget uninstall Microsoft.WindowsTerminal. Then,
      winget install Microsoft.WindowsTerminal
      will install the current version.

Most of the time — as in this instance — if the Store offers options, they will usually suffice to fix app issues. Steps 2 and 3 are only needed when the app itself is somehow damaged or corrupt.

Put this in your bag of Windows 10 and 11 tricks. It could come in handy someday!

Last week, I recited my adventures in reworking my LAN to improve stability in the wake of a line of thunderstorms. This weekend, I’m off to Waco on a legal project. The boss — my wife, Dina — asked me to provide instructions on how to bring the Internet back up should it go down while I’m away. Here, then, is the Chez Tittel Internet restore recipe. I hope other readers find the various contortions involved interesting, if not amusing.

Steps in the Chez Tittel Internet Restore Recipe

Basically, the first step is to unplug and restart all of the key devices in the Internet chain here at the house. I usually check (and if necessary, reset) items in this order:

1. The main link to the Internet is the Spectrum boundary device: A Spectrum Wave 2 RAC2V1A router/WAP/4-port switch device. It obligingly shows a red light when its Internet link is down. That’s my signal to unplug power from the device. The device, with an “A-OK” blue light is shown as the lead-in graphic for this story.

2. I’ve got a second such device on the LAN in my office. It’s an ASUS AX6000 router (AKA RT-AX88U model number) that I use purely as a WAP for 802.11ax (and lower) Wi-Fi access in the house. I show a rear-end view, because resetting the device involves unplugging the power brick from the port at the far right.

3. I’ve got two Netgear unmanaged GS108 8-port switches in my office, too. One sits on the baker’s racks to the left of my desk, the other on the windowsill at the right of my desk. Here again, the quick’n’easy reset technique is to unplug the barrel connector for the incoming DC power from its brick. Once again, my guiding image includes a rear view of the device, where the barrel connector for power plugs in at the far right.

Putting the Recipe to Work

I always check the color of the light on the Spectrum device first. If it’s red, I know I need to unplug and wait for it to come back up to see if that helps. If it stays red after two full power cycles, it’s time to call Spectrum to ask for help on their end. This pretty much demonstrates the problem is theirs.

If the Spectrum device is blue, but the in-house Internet isn’t working, this can be on of two things:

1. The Wi-Fi from the ASUS device isn’t functioning. This manifests as networks that start with an Arb… name string lacking Internet access (“No internet”). When this happens, I unpower the AX6000, wait a minute or two, then power it up again. That has always worked so far.

2. The local Ethernet isn’t functioning. That’s definitely a switch problem. If this happens, I disconnect power first from the switch on the baker’s racks, wait a minute and try again. Most of the time that does the trick. But if not, I do likewise for the switch on the windowsill. So far when the former hasn’t worked to restore the wired LAN, the latter has always done so.

And that’s how the network gets brought back up here at Chez Tittel most of the time. Especially after power glitches occur. Over the years I’ve only had to bring Spectrum in for tech support a handful of times (and the phone app now obligingly reports outages, often before I notice them if they occur after hours). Cheers!

I’m still finding my way into the “new regime” for the Dev Channel in Windows 11. A couple of days ago, MS dropped Build 25120 (here’s that announcement). I’ve been playing catch-up ever since, with a number of interesting issues popping up. In true Whack-a-Mole style, I’ve been able to fix everything so far. But no sooner do I whack one than another pops up, which is why I assert that Build 25120 Shenanigans continue. Let me explain…

Which Build 25120 Shenanigans Continue?

Yesterday, I described issues with the Thunderbolt dock and its attached peripherals (unplug/re-plug fixed that one). I also described how 8GadgetPack disappeared, and required a re-install AND a repair for a successful resuscitation.

Later that afternoon, I ran into an interesting gotcha, described in this Twitter thread “Dude! Where’s my Control Panel?” Suffice it to say that I couldn’t search inside the start menu, which proved hugely frustrating. A DISM restorehealth operation and a File Explorer restart set things back to rights for that one. FWIW, I also ran SFC /scannow but it found nothing in need of repair.

I can now say with confidence, based on recent, painful personal experience, that typing program names into the Start Menu search box beats the pants off figuring out and using command line equivalents! Until I fixed that glitch, I was NOT a happy camper.

What’s Next?

I can’t say for sure, but I’m pretty sure I’ll keep finding and fixing stuff as the series of Dev Channel releases find their way onto my test PCs and VMs. I’m getting a good education on minor glitches and gotchas and their associated fixes, that’s for sure. All I can say to MS and the WindowsInsiders team is: “Keep them moles a’comin.” I’ll keep whackin’ ’em as they pop up, for sure!

OK, then. Life has just gotten a little more interesting here at Chez Tittel. Briefly: I had trouble remoting into the X12 Hybrid yesterday. Ditto this morning, when I decided to troubleshoot the PC. Turns out the initial attempt at installing Build 25120 failed, with a familiar and possibly driver-related error code. And while the second upgrade attempt succeeded, that Dev Channel PC shows potential Thunderbolt issues. Let me explain…

Dev Channel PC Shows Potential Thunderbolt Issues: More Info

The lack of a network connection clued me into the seeming culprit. When I visited the X12 hands-on, I saw I was connected to the LAN via Wi-Fi. Not necessarily bad, but the machine has a Thunderbolt dock with a (previously working) GbE wired connection. It wasn’t working. Nor were other peripherals plugged into the dock.

So I unplugged the dock, then plugged it back in after a half-minute wait. Presto! Everything was working as normal once again, including my wired RDP connection. I can only presume that the driver issue reported in the first failed upgrade attempt was Thunderbolt related. I’m also  starting to wonder if my dock isn’t having power or connectivity issues, because this is not the first time this has happened — the dock going bye-bye — recently.

Promised Dev Channel Instability Is Manifesting, Too…

When the Insider releases for Dev and Beta Channels forked earlier this month, MS warned of potential or increased instability in the Dev Channel. I’m not complaining, but I am seeing same now on Build 25120.

8GadgetPack is definitely hosed on the X12 (but works perfectly on the X380 Yoga — go figure!). I’m making my bug reports and trying various fixes. As I’ve said before, I’m getting a feeling that this venerable software’s days on Windows 11 may be numbered. I’ll keep you posted about that.

Otherwise, I’m just feeling my way into the latest OS release. I’m hopeful that such kinks as I discover will be worked out. But yea or nay, I’ll let you know. Stay tuned!

Note Added 15 minutes later: Another reinstall of 8GadgetPack, and another manual repair does the trick on my X12 PC. GadgetPack appears to be working again. Having now had trouble on one of each of my two Dev Channels PCs after the past two upgrades I’m wondering if this will become a recurring theme in post-upgrade processing. More to come on this subject, I’m sure!

I had an “Oh no!” moment yesterday. After upgrading my Lenovo X12 tablet to Dev Channel Build 25115, I went through the usual post-upgrade drill. Because the installer always kills fave tool 8GadgetPack, developer Helmut Buhler has created a run-once repair tool that restores gadgets to working order afterward. It shows up as Restore Gadgets on the desktop, and must be double-clicked to run. For the first time ever, I experienced an 8GadgetPack repair fail yesterday. Ouch!

[NOTE] The Restore Gadgets script shows up in Recycle Bin in the lead-in graphic because it’s smart enough to delete itself once it runs.

What made it an “Oh no!” moment was that I feared it meant the demise of Gadgets from Dev Channel desktops once  and for all. Gadgets were obsoleted back in the Windows 7 days, ostensibly for security reasons (though I’ve never run  into, nor heard of, actual Gadget-related exploits). And for a time after the upgrade, all of my attempted repairs didn’t work.

How I Got 8GadgetPack Repair Fail Fixed

This only affected one of my two Dev Channel PCs, as it turns out. Once I realized the repair was bollixed on the X12, I tried it on the Lenovo X380 Yoga. Worked like a charm! That was comforting, because I knew it was something with the X12 itself, and not a general failure.

Here’s what I tried before coming up with the actual fix itself:

1. Re-ran the repair tool (no go).
2. Re-ran the repair tool with elevated privileges (didn’t do it)
3. Downloaded and ran the 8gadgetpack.msi file from 8gadgetpack.net (no luck there, either)

But when I tried #3, I got an error message that said to go to Control Panel → Programs and Features and attempt repairs from there. When the right-click menu for 8GadgetPack popped up, it included a “Repair” option. And when I ran the repair that way, it worked. Go figure!

Upon Closer Inspection…

In trying to figure out what happened, I opened up Reliability Monitor and looked at the day’s error and event reports. Sure enough, 8GadgetPack appeared in the form of a couple of Warning messages.

Something about running the repair tool from the desktop led to what ReliMon reports as an “unsuccessful application reconfiguration.” Apparently, the same problem does not apply to running it within a Control Panel item. Thus, I learned a new workaround and brought my beloved 8GadgetPack back from unnecessary oblivion. Other fans of ever-handy Windows Gadgets should be cheered thereby as well. Good stuff!