Cool Tools, PowerShell, WED Blog, Windows 11

Some Have Icons, Others Don’t

Leave a comment

Now that the adrenaline rush from getting icons working in WinTerm has subsided, I’ve started looking more closely at which items actually display icons in response to winget list –details. My conclusion from this analysis? Some have icons, others don’t. Indeed, the number of qualifying items is less than I originally thought: exactly 37 of the 143 total packages that winget manages show me something pretty to look at. ‘Sup with that? Here’s my take…

Which Some Have Icons, Others Don’t?

The test machine is a Lenovo ThinkPad X12 Gen 1 Hybrid running Windows 11 — a clean-ish install with the usual factory bloatware and a handful of my own tools layered on top. Running winget list --details produces 143 packages. Of those, exactly 37 display colorful, sixel-rendered icons in the terminal output. The remaining 106 show nothing. No icon, nor placeholder. No ghostly outline. Just… text.

What’s striking is how that output is organized. All 37 icon-bearing packages appear first in the output stream, clustered together like a parade of floats. Then there’s a visual cliff — you scroll past the last colorful logo and drop straight into a desert of monospaced text. It’s like walking from a gallery opening into a DMV waiting room. Same terminal. Same command. Two completely different experiences.

Twenty-six percent. That’s the icon coverage rate. On a machine with 143 packages, barely a quarter of them get the visual treatment. The other 74%? It’s still 1985 out there.

The Installer Category Absolutely Rules

Here’s where things get interesting — and by “interesting” I mean “so clean it almost feels like a prank.” I started looking for the variable that separates the haves from the have-nots. Publisher? Nope — Microsoft shows up on both sides. Source repository? Irrelevant. Architecture? x64 and x86 packages appear in both camps. Update date? No correlation. Then I looked at the Installer Category field, and the mystery evaporated.

The Pattern

Every single package with an icon has Installer Category exe or msi. These are traditional Win32 desktop applications installed via ARP (Add/Remove Programs) entries. Every single package without an icon has Installer Category msix — modern packaged apps from the Microsoft Store or sideloaded MSIX bundles.

There’s a 100% correlation. Not 98%. Not “mostly.” One hundred percent. Win32 equals icons. MSIX equals no icons. The dividing line isn’t publisher, isn’t source, isn’t architecture, isn’t age. It’s installer category, and nothing else.

What Does This Mean?

Why does this make sense architecturally? Because the two package types get their metadata from fundamentally different places:

  • Win32 packages (exe/msi) live in the winget community repository, where their manifest files include IconUrl fields pointing to PNG images. Winget fetches those URLs, converts the images to sixel format, and Terminal renders them inline. Clean pipeline. Works beautifully.
  • MSIX packages get their metadata from the Microsoft Store catalog or from the AppxManifest.xml embedded inside the package itself. Neither of these sources exposes icon URLs in a format that winget’s sixel rendering pipeline can consume. The icons exist — the Store shows them, Dev Home shows them, the Start Menu shows them — but terminal-facing winget can’t reach them through the MSIX metadata path.

Searing Irony: MS Apps Are Holdouts

And here’s where the comedy writes itself. Of the 106 iconless MSIX packages on this PC, 96 are published by Microsoft. Let that sink in. The company that built winget. The same outfit that built Windows Terminal. The company that built the sixel rendering pipeline. The developers who invented the MSIX packaging format… can’t show its own icons in its own tool.

We’re not talking about obscure infrastructure components here. The missing-icon list reads like a “Best of Microsoft” compilation album:

  • Flagship apps: Microsoft Edge, Microsoft Teams, OneDrive, Outlook, Paint, Photos, Calculator, Camera, Notepad
  • Windows itself: Windows Terminal, Microsoft Store, Windows Security, Snipping Tool, Windows Media Player
  • Productivity & lifestyle: To Do, Sticky Notes, Phone Link, Quick Assist, Clipchamp, Power Automate
  • Entertainment & social: Xbox, Solitaire, Dev Home

Then there are the framework and runtime packages — the plumbing that nobody sees but everything depends on. .NET Native Frameworks (versions 1.3, 2.1, 2.2), VCLibs (2012, 2013, 2015), UI.Xaml (2.7, 2.8), WindowsAppRuntime (1.6, 1.7, 1.8) — many appearing twice, once for x64 and once for x86. These make up vital Windows infrastructure. You wouldn’t expect icons on a Visual C++ redistributable. But Teams? Edge? Photos? These are flagship consumer applications with instantly recognizable logos. And in the terminal, they’re anonymous.

What Else Is Missing?

The remaining ~10 non-Microsoft MSIX packages without icons are third-party apps that happen to ship as MSIX bundles, mostly OEM-related: Intel Graphics Software, Thunderbolt Control Center, Dolby Audio Premium, Lenovo Vantage, Notepad++ (there’s also an installable version, with icon showing), Realtek Audio Control, Synaptics TrackPoint and TouchPad drivers, and — somewhat poetically — Oh My Posh, a tool whose entire reason for existing is making terminals look prettier.

Why DOES MSIX Fall Behind?

To understand the gap, you have to understand the pipeline. Winget’s icon rendering isn’t magic — it’s a four-step relay race, and MSIX packages drop the baton at the starting line.

Here’s how it works for Win32 packages:

  1. Manifest lookup. Winget looks up the package in its community repository and finds the package manifest YAML file.
  2. Icon URL extraction. The manifest includes an IconUrl field pointing to a hosted PNG or SVG image.
  3. Sixel conversion. Winget fetches the image from the URL and converts it to sixel format — an inline graphics encoding standard that dates back to DEC terminals in the 1980s, now reborn in modern terminals.
  4. Terminal rendering. Windows Terminal, with enableSixels: true in its experimental settings, interprets the sixel data and renders the icon inline, right next to the package name.

For MSIX and Store packages, this pipeline breaks at steps 1 and 2. MSIX packages registered through the Store don’t necessarily have community manifests with IconUrl fields. Their metadata comes from the Store catalog API or from the AppxManifest.xml bundled inside the package. Neither of these sources feeds into winget’s sixel rendering path.

It’s not that MSIX packages don’t have icons — they absolutely do. The Microsoft Store displays them beautifully. Dev Home displays them. The Start Menu displays them. Your taskbar displays them. But the specific pipeline that converts an icon reference into sixel terminal output hasn’t been connected to the MSIX metadata source. The icons are there. The rendering engine is there. The wiring between them? Not yet.

What Comes Next? “Under Construction…”

The good news — and it’s genuinely good news — is that this is just an implementation gap, not a fundamental limitation. Every piece of the puzzle belongs to MS:

  • Winget — Microsoft’s package manager
  • Windows Terminal — Microsoft’s terminal application
  • Sixel rendering — implemented by the Terminal team
  • MSIX — Microsoft’s modern packaging format
  • The Store catalog API — Microsoft’s metadata service

There are no third-party dependencies to negotiate. No standards bodies to petition. No licensing hurdles to clear. Connecting the MSIX metadata path — where the icons already live — to the sixel rendering pipeline is a plumbing job. An important one, but a plumbing job nonetheless.

When (not if) Microsoft bridges this gap, the icon coverage on a typical Windows machine should jump dramatically. We’re talking from 26% to potentially 90% or higher, essentially overnight. On this ThinkPad, that would mean going from 37 icons to 130+. The visual cliff in the winget list output would disappear, replaced by a continuous stream of colorful, identifiable package icons.

The winget-cli GitHub repository is the place to watch. Feature requests and pull requests related to MSIX icon rendering or Store catalog icon integration would be the signal that the coverage expansion is inbound. Given that Microsoft went to the trouble of implementing sixel rendering in the first place — a non-trivial engineering effort — it seems unlikely they’d leave 74% of packages iconless.

One in Four Is a Good Start…

So here we are. The sixel icon feature in Windows Terminal works. It works beautifully, in fact — those 37 Win32 packages look fantastic, their colorful logos rendered crisply inline, transforming a wall of text into something you can actually scan visually. The three-step setup is straightforward. The technology is sound.

It’s just that only 37 apps showed up to the party in full regalia, while 96 of Microsoft’s own applications stand in the corner without name tags. Edge — the browser Microsoft preinstalls on every Windows PC on Earth — doesn’t get an icon. Teams — the collaboration hub Microsoft spent billions promoting — doesn’t get an icon. Windows Terminal itself, the application rendering the icons, doesn’t get an icon. You have to admire the irony, even if you wish you didn’t.

The feature is real. The gap is clear. The fix is feasible. And in the meantime, those 37 Win32 apps with their lovingly rendered sixel icons are living proof that the future of terminal-based package management looks a lot more colorful. Now, somebody needs to connect the rest of the plumbing.

In Windows-World, 26% is a start. A visually delightful, architecturally illuminating, slightly ironic start. But MS can do better. Hopefully, sooner rather than later. Let’s see!

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

X12 Tablet Gets Clean Install

Leave a comment

Something cratered the Lenovo ThinkPad X12 Detachable Tablet this weekend. I’d been screwing around with Secure Boot, recent updates, and more. When I sat at my desk Sunday morning, it was refusing to boot, and throwing error code 0xc0000428, which signals a winload.efi signature mismatch with what’s in firmware (see lead-in graphic). I did get the machine booted to recovery media on a UFD. I could’ve repaired and recovered the previous installation. But I decided that X12 Tablet gets clean install instead, so I could check a bunch of things out about a fresh, clean Windows 11 install. Here goes…

After X12 Tablet Gets Clean Install, Some Initial Checks

Having wrestled so much with Secure Boot lately, my first check was on that security layer. Indeed, Garlin’s check script revealed it was present, and more-or-less up-to-date. With minimal effort I was able to bring the X12 into full compliance with modern Secure Boot settings.

Next, I checked Smart App Control in Windows Security. It is currently set to Evaluation mode. I’m supposed to be able to switch between the On and Off states now. I need to finish configuring this PC and get an image backup tool in place, before I start fooling around with things. But the signs are promising. Right now SAC is working, and behaving just the way it’s supposed to work.

More About OOBE

After the post-GUI installation in Windows 11, the Out-of-Box Experience (OOBE) appears to guide users through final steps of the process. This time, I did get to choose the machine name I wanted (kept it at X12Hybrid) where it works properly. The network setup found my WAP right away, and I was off and running right away, too. It was also amusing to see how many, many backups I could’ve used when installing this PC (including an older X12 version dating back to 2022). But since I wanted a clean install experience, I skipped all that stuff.

Now Comes the Rest of the Job…

I’ve got to set up and customize the X12 to my usual liking. That’s probably going to mean an hour or two a day for the next few days. This afternoon I think I’m going to try using WinGet to export most of my app set from Flo6 to X12, and see how that works.

Stay tuned! It’s possible that things in my little corner of Windows-World are about to get interesting. If so, you’ll get more follow-up from  your humble correspondent. So far, so good, though.

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

Magician Internal Updater Lags Behind

Leave a comment

I have to chuckle. In making my morning rounds, I see at TechPowerUp.com that there’s a new version of Samsung Magician out — namely, 9.0.1. So I jump into Magician and check its internal updater, which tells me I’ve got the latest version: 9.0.0. Alas, as Copilot tells me, it’s not unusual for the utility to do this. Indeed, as a matter of observed practice, the Magician internal updater lags behind Samsung’s software release schedule. It’s all laid out in the lead-in graphic. Let’s explore…

Why Magician Internal Updater Lags Behind

Apparently, Samsung waits until a new release has been out for some while before updating its xml-based manifest to make it known to the Magician updater through its update servers. According to Copilot, Samsung has been ill-served during previous release cycles by “buggy Magician releases,” “firmware-pushing issues,” “NVMe driver conflicts,” and so forth.

Thus, the company releases the new software first through public channels such as TechPowerUp, MajorGeeks, SoftPedia and other file-sharing sites. It then watches user responses from early adopters for up to a few days, and sees what the uptake and reactions are like. It’s not unusual for the manifest to lag behind by hours or days.

As you can see from the lead-in graphic, 9.0.1 was released today (3/30/2026). So it could be later today,  tomorrow, or even later this week before the built-in updater catches up. Unless Samsung pulls 9.0.1 back and decides to push out another, hopefully better release later on.

Here in Windows-World, the release paths for software often tell a story. The one for Samsung Magician is pretty interesting, and shows the value of lessons learned from prior history. You might say “Better later than sooner, especially if problems present!”

Note Added 2.5 Hrs Later: It’s Here!

Reading over ElevenForums traffic in the Devices & Drivers forum just now, saw a user report that Magician is offering 9.0.1 now. Just checked here and — there it is! Installing now, and glad to see it was a matter of hours, not days (or a pullback, either).

Works, too! Looks like we get to do things the easy way this time.

Facebooklinkedin
Facebooklinkedin
Insider stuff, Recent Activity, Thoughts & concerns, WED Blog

Sandbox Effect Keeps Spreading

Leave a comment

OK, I admit it. I run Adblocking software inside my web browsers. To see web pages nowadays, that means I bump them up to 150% so I can read the text. That leaves less room for other stuff, especially ads. But I’ve noticed that an increasing number of websites simply won’t let viewers visit unless those visitors permit the ads to show. So I open those sites inside Windows Sandbox because it works as a no-filters and no-blocks-applied environment. Alas, this “Sandbox effect” keeps spreading as more and more sites make me do this.

Why Say: Sandbox Effect Keeps Spreading

I got a particularly rude wake-up call about this on Wednesday. In fact, I didn’t even figure it out until this morning. Two days ago, I noticed that WinAero was coming up in Firefox (where it’s in my favorites) as an all-back page. I even asked Copilot what might be wrong and it speculated that something with the CDN (Content Distribution Network — e.g. Akamai, etc.) might be wonky.

Wrong. This morning, it dawned on me that this “black screen” might be a particularly draconian implementation of a “no ad blocking” policy. And indeed, that’s what it appears to be (lead-in graphic, left). When I open the same site in Windows Sandbox (lead-in graphic, right) it comes up in readable form right away. Wowie-Zowie.

The Sandbox List Is Growing

Minutes ago, I had a similar experience at Thurrott.com. I suppose I should be grateful, because that site operator at least had the courtesy to tell me what was going on. Here’s what it showed me after a click-through from a “problem loading the page” error message:

Life is interesting when one is inclined to appreciate being informed that they must watch ads on a website, or skedaddle. Here in Windows-World, gratitude often takes unusual forms. This one, methinks, is more unusual than most. Happy Friday!

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

Reverse DNS Lookup Reveals Router Change

2 Comments

I’m pretty fond of the free network scanning tool named Advanced IP Scanner. It’s much more predictable and reliable than the Network facility built into File Explorer. It also makes it easy to do stuff to and over the network. I’ve been noticing on my LAN recently that an increasing number of PCs (and other devices) get DHCP names that end in “.lan” (see the lead-in graphic for more info). So I used a PowerShell script to do a reverse DNS lookup to double-check this. And indeed, this reverse DNS lookup reveals router change in my SAC2V1A Spectrum-supplied router. Looks like it got a recent firmware upgrade that changed its DNS/DHCP behaviors.

How Reverse DNS Lookup Reveals Router Change

I created a PowerShell script to talk to the router and give me DHCP names for all of the nodes it handles, using the ARP (address resolution protocol) as my foundation. If you look at this WinTerm screencap, the pattern is unmistakable:

I forcibly used ARP to drive reverse DNS lookups (from IP address to name from the router’s name table) for all active IP addresses. Notice that every single name here ends with the “.lan” suffix. That tells me Spectrum pushed a firmware update to the box, because it didn’t used to do that consistently for all items.

Why Advanced IP Scanner Shows Some Unadorned Names?

Advanced IP Scanner uses multiple techniques to resolve IP addresses to names. Among this is the NetBIOS Name Service (NBNS), Link-Local Multicast Name Resolution (LLMNR), Multicast DNS (mDNS), SMB/NetBIOS over TCP, and Reverse DNS (PTR lookup). Some or all of these return bare machine names, lacking the .lan suffix. As far as I can, whichever of these lookups responds first is the one that makes it to the name table. And that’s why Advanced IP Scanner shows different name strings than does my script.

Weird and wonderful are the ways of Windows-World. And few are anywhere near as weird, or as wonderful, as the ones that make name resolution work on Windows networks. QED!

Facebooklinkedin
Facebooklinkedin
Insider stuff, Recent Activity, Troubleshooting, WED Blog

Device Zombies Roam Among Us

Leave a comment

Every so often, Windows throws you a curveball that feels less like a bug and more like a ghost story. One of the stranger ones I’ve run into lately is what I’ve started calling “device zombies.” This is a state where Windows believes a device is still alive, or the Microsoft Store insists it’s still alive and kicking. Here at Chez Tittel, I know I sent these devices back to Lenovo, Dynabook or Panasonic up to 5 months ago. That’s why I declaim, in shock and horror: “Device zombies roam among us!” Let me explain…

Proving Device Zombies Roam Among Us

In my case, I often get and return as many as a dozen computers a year on loan from their makers. You’ve read my unboxing, intake, and other stories about them. Right now, through the lens of https://account.microsoft.com/devices (that’s where you login to check devices registered to some specific MSA) I can see four Zombies plain as day:

  • T14Snap: A ThinkPad T14s Snapdragon based laptop I returned to Lenovo in November, 2025.
  • X13G6: A ThinkPad X13 Gen 6 intel based laptop I returned to Lenovo in January, 2026.
  • Flo6: The previous incarnation of my current production desktop based on the flaky and frustrating ASRock B550 Extreme4 mobo. I just decommissioned this over the weekend.
  • X40M2: A Dynabook (formerly Toshiba) Portege X40-M laptop that I returned to Dynabook in January, 2026

When I first checked this out over the weekend, I had 3 more such items showing, but I used the “Remove your device” pane shown for the X40M2 in the lead-in graphic to drive another stake in their hearts. Some of these appear to have caused them to shuffle off the device list, if not the mortal plane.

Sames Goes For Store, But…

The same page in the account. microsoft.com hierarchy has an entry for Microsoft Store device management. It purports to show a list of devices linked to that online asset. But mine keeps coming up empty, even though right now some attempts to install new software tell me I’ve exceeded my device limit. Note the text at lower left in the screencap that reads “Device limit 0 of 10” (no more new ones will be accepted).

It’s even harder to kill zombies when you can’t point an interface at them to order their removal. Thus, these might be considered zombie ghosts because they’re there, but you can’t seem ’em.

Time Cures All Ills, Even Zombies

Turns out that the Store and the MSA Device Log use telemetry to maintain the list of supposedly live items. Thus, when I sent the units back to their makers, they reset their “life timers” by up to 90 days when they fired them up (and opened my MSA login, even if they didn’t use it) before resetting and reimaging them for their next reviewer. At some as-yet-unknown future point in time, though, these machines should vanish from the device list for my MSA. I can only hope the MS Store will treat them the same way…

In the future, here’s what I need to do to prevent Zombies from remaining in my lists:

    1. Remove them from the list while they’re still under my control
    2. Reset the Microsoft Store (wsreset -i) to kill lingering cache associations
    3. Reset the PC so it can’t generate another login to my MSA

As with so much else in Windows-World, the best way to stay out of “Zombie trouble” is never to get into it in the first place. Going forward, I’ll be sure to keep that in mind.

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

Flo6 Mobo Switchover Succeeds

Leave a comment

On Thursday and Friday of last week, I continued to fight with warm boot issues on my primary Flo6 desktop. The ASRock UEFI stubbornly refused to synch up the MS updates for Secure Boot with its own internal, stored values. Net result: I couldn’t restart Flo6. I could only traverse the shutdown/startup cycle through a deep, cold boot that sometimes required a CMOS reset. After lunch Friday, I took the plunge and tore the PC apart to switch out the ASRock B550 Extreme4 for an MSI Mag Tomahawk B550 WiFi Max. To my great relief and delight, that Flo6 mobo switchover succeeds admirably. That said, I started after lunch Friday and finished after 9M Saturday nite. Phew!

Lessons Learned, as Flo6 Mobo Switchover Succeeds

I made a couple of interesting mis-steps along the way that slowed things down, but the overall process was pretty straightforward. The teardown was easy, but it reminded me how much I now depend on reading glasses for close-up work, since last fall’s cataract surgery.

In putting the new build together, I saw that I’d failed to remove the clear plastic sticker on the CPU cooler during the previous build. Have to laugh, but the results are amazing: no sticker plus a fresh coat of thermal paste took CPU temps down from mid-50s to low-60s to a steady 31°C (Source: Speccy; HWiNFO shows various temps ranging from 32 to 42°C). All show serious improvements over the old build!

Putting the old parts onto the MSI Tomahawk board is where things got interesting. That board offers only LEDs for CPU. DRAM. VGA and BOOT.  I missed the two-digit POST code display on the ASRock mobo, which was more intelligible and easier to read. My first mis-step was mispositioning the 5800x CPU. I was 180 degrees off on the first try. Easily fixed, but took time.

My second mis-step was to put the GPU in the secondary PCIe slot. For some reason I was scared of the metal clad primary. But the PC wouldn’t POST that way, so eventually got that straightened out (the VGA LED did its job). The third stumbling block wasn’t a mis-step, it was more of a design flaw in the MSI board. It wouldn’t start up with more than 2 of the 4 orignal RAM modules (32 GB each) in place. That was a pure trial-and-error exercise.

All the Stops along the Way…

I also had to flash the UEFI (though they still call it BIOS flashing) before I could get past recognizing the CPU. This works with neither CPU nor GPU installed, from a specially formatted USB 2 flash drive. It’s like magic that the board can DIY this process, but it worked like a champ. From that point on, I moved from one proper set-up step to the next. CPU first, GPU second, and proper RAM configuration last.

Note: getting the RGB connector to seat properly on the mobo pins was the most physically challenging part of the build. Close second was working with RAM modules right up against the massive ThermalWright Assassin CPU cooler. But it all got sorted, by guess and by gosh.

Eventually (around 6:30 PM Saturday), I got the setup to boot and it took me straight into Windows, running the same image I’d been using on the old ASRock mobo. Boy, was I relieved to see that happen. And now, for some clean-up notes and good news. Read on…

Booting into Windows, and Beyond…

Once I got into Windows, I had to adjust for the mobo change. To activate Windows 11 Pro, I had to re-enter the same MAK it had already been running on (who knew?). To switchover from the old ASRock to the new MSI drivers, the system loaded an MSI Center app. It cheerfully offered to load “all” necessary drivers, but gave me control over which ones I chose. Needless to say, I skipped the fluff and stuck to device drivers and useful utilities only.

Then I ran Settings > Windows Update, which caught up other key drivers. A fresh run of the Logi app brought back my wireless mouse (I’d been forced to plug in a wired mouse during set-up because I mistakenly grabbed an MS wireless mouse instead of the Logi model, LOL).

Checking Secure Boot and CA-2023

The following image triumphantly confirms that with the current UEFI and recent MS updates in place, Secure Boot and certificates took care of themselves. I didn’t have to do anything!!!

The first PowerShell (PS) command [confirm-SecureBootUEFI] shows it’s in place and working. The second PS command tells me that CA-2023 is in place and in use. That was really the whole reason for the mobo switch, so I’m tickled to death it worked like it was supposed. Added bonus: I can restart, shutdown, and even use “shift+(Settings > Power Button > Restart) to get into the Windows Recovery (WinRE) environment. In short, Windows boot now works just like it should, and Secure Boot is properly doing its thing.

It was a long time coming, and cost me US$150 for the MSI mobo. But God: it was worth it. Case finally, finally closed. I’m thrilled!!!

Facebooklinkedin
Facebooklinkedin
Uncategorized

Alexandrine Solution Fixes ThinkStation Diagnostics

Leave a comment

In reviewing Reliability Monitor for my peppy and capable ThinkStation P3 Ultra Gen 2, I saw recent repeated APPCRASH errors. If you could drill down into the lead-in graphic — as I did — you’d see 3  between March 11 and 14. So I asked Copilot to tell me more about this error. I learned that this utility is recommended, not required. I also learned that what’s blowing up reflects some kind of telemetry error when the app tried to phone home. So I uninstalled it. This Alexandrine solution fixes ThinkStation Diagnostics (think: Gordian knot) and smooths out my reliability ratings.

How the Alexandrine Solution Fixes ThinkStation Diagnostics

In this context I’m reminded of the well-known DCOM Event 10016 error, which pops up dozens to hundreds of times a day in Windows 10 and 11. It’s not really an error, it’s the result of a design choice that tries a series of component object model (COM) and distributed COM (DCOM) components as it performs routine tasks such as running shell components, search indexing, UWP apps and background services. It appears as an error, even though the actual work to which such errors are tied actually succeeds. Noise, in other words.

In the same vein, the ThinkStation Diagnostics (TD) software is:

1. Recommended, not required
2. The “critical error” relates to the software’s operation, not the system it monitors
3. Copilot reports that Lenovo documents numerous cases where TD fails this way owing to external device voltage issues, unsupported cables or dongles, power state transitions (sleep/resume)

Indeed the error is something on the back end, not in the system itself, and doesn’t really signal an actual problem. Ironically, it’s the system for reporting problems that’s itself causing problems.

Noise, Not Signal Makes Alexander Right

Nobody could untie the Gordian knot, so they couldn’t get in the door, either. Alexander cut it off, and got the door open right afterward. I’m taking the same approach with this tool. It’s not because I don’t want it to tell me useful stuff; it’s because I don’t want it to crash for uninformative reasons.

Here in Windows-World, there’s always a certain amount of noise to go along with valid signals. When I feel like the noise is swamping the signals, I’m glad to remove a source of such noise. There are plenty of ways for me to find out what’s going on, using other means. Basta!

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

Author, Editor, Expert Witness