WinGet Iconification Is Ongoing

Yesterday, I had the good fortune to spend an hour on the phone with WinGet team lead Demitrius Nelon. He gave me a “slice of life” view into the many and varied kinds of chicken-and-egg problems his team deals with daily. He also helped me improve my understanding of where and how icons come from inside a sixel-enabled terminal session, including those that WinGet shows. And indeed, WinGet iconification is ongoing and spreading, as I saw this morning when I ran a general upgrade command on the recently clean-installed (and properly enabled) ThinkPad X12 Gen 1 tablet.

Why Say: WinGet Iconification Is Ongoing

Take a look at the output for a winget upgrade –all …  command from the lead-in graphic. Note the first actual upgrade (for OneDrive) shows an icon in that output stream. This is the first visible evidence I’ve seen running WinGet that the tool is including icons outside of the list –details commands. Very interesting!

Doc Info on list –details

Here’s a big snippet from the release notes for WinGet production version v.1.28.190:

New Feature: ‘list –details’

The new feature enables a new option for the list command, --details. When supplied, the output is no longer a table view of the results but is instead a series of show like outputs drawing data from the installed item.

An example output for a single installed package is:

> wingetdev list Microsoft.VisualStudio.2022.Enterprise --details
Visual Studio Enterprise 2022 [Microsoft.VisualStudio.2022.Enterprise]
Version: 17.14.21 (November 2025)
Publisher: Microsoft Corporation
Local Identifier: ARP\Machine\X86\875fed29
Product Code: 875fed29
Installer Category: exe
Installed Scope: Machine
Installed Location: C:\Program Files\Microsoft Visual Studio\2022\Enterprise
Available Upgrades:
  winget [17.14.23]

If sixels are enabled and supported by the terminal, an icon for the installed package will be shown.

I’m glad to see and understand that the stuff I had to figure out more or less on my own through trial and error is now going explicitly into the public record. For the details on how to enable sixel output in your WinTerm sessions, see last Friday’s how-to blog post Light Up WinGet Icons.

Where to from Here?

I expect to see icons popping up all over WinGet in the coming months. I also expect to see more icons popping up in output streams, as the plumbing falls into place. Right now, only about 20% of WinGet’s packages show icons. But that number’s going to jump for sure. Stay tuned, and I’ll tell you all about it.

 

Facebooklinkedin
Facebooklinkedin

How-To: Light Up Winget Icons

Thanks to numerous requests, I’m providing step-by-step instrux in this unusual second blog post for today. It’s based on something that made me unreasonably happy earlier this week. That is:  WinGet can now display colorful package icons right inside Windows Terminal, rendered via sixel graphics. It’s a small visual upgrade that makes winget list –details output dramatically more readable. You get actual application icons inline with package data instead of a wall of monochrome text. But getting there requires a few specific steps. Here’s the complete recipe so you, too, can light up WinGet icons.

Why Must You Light Up WinGet Icons?

The current production version of WinGet is v1.28.220 as I write this post. The latest Preview version is v1.29.70-preview. Production is still catching up, so preview is a must for the moment. I imagine, though, that this will change with the next production version update. As with all moving targets, this one keeps changing along with everything else!

Step 1 — Get a Preview Version of Winget

Sixel icon support requires WinGet version 1.29.50-preview or later. The current stable release doesn’t include it. Check your version with winget -v. If you’re behind, try this first:

winget upgrade Microsoft.AppInstaller –source winget

If that doesn’t pick up the preview build, head to the microsoft/winget-cli releases page on GitHub, download the latest .msixbundle. If a double-click won’t install it, you can install it manually with Add-AppxPackage. Fair warning: on some machines the Microsoft Store installer handles dependencies automatically. On others, you’ll need to sideload VCLibs and Microsoft.UI.Xaml packages yourself.

Step 2 — Enable Sixels in Winget’s Settings (Not Terminal’s!)

This is the gotcha, and it got me for a short while. I confess: I mixed it up myself. The sixel toggle goes in WinGet‘s own settings file, NOT in Windows Terminal’s settings.json. Run winget settings to open the file. Add or merge a visual block so it looks like this:

{
“$schema”: “https://aka.ms/winget-settings.schema.json”,
“visual”: {
“enableSixels”: true,
“progressBar”: “rainbow”
}
}

The enableSixels: true setting tells WinGet to emit sixel graphics in its output. The progressBar key is optional —”rainbow“, “accent”, and “retro” work well (“sixel” works, but is hard to see). Any of these gives you graphical progress bars during installs, as a nice bonus.

Step 3 — Restart Terminal and Run It

Kill Terminal completely — not just close a tab. Right-click the taskbar icon and close the window, or kill the wt process outright. Relaunch. Then run:

winget list –details

Icons should appear for Win32 packages (exe/msi installers). MSIX packages won’t show icons — that’s a known limitation of the current pipeline, not a configuration error on your part. You can filter to a single package to test things quickly (I chose 7Zip, as it’s at the top of my ASCII sort order):

winget list –details 7zip

What to Expect

Not every package gets an icon. In my testing across two ThinkPads, icon coverage ranged from 26% to 31% of total installed packages. The dividing line is 100% correlated with installer category: Win32 packages (exe/msi) get icons, MSIX packages don’t. That’s an architectural gap Microsoft hasn’t bridged yet.

But what works, works beautifully. The icons are crisp, properly sized, and render instantly. It turns a dull text dump into something you can actually scan visually — which matters when you’re staring at 150+ installed packages trying to figure out what needs updating. Once you’ve got it set up, you won’t want to go back to the plain-text version. Cheers!

Facebooklinkedin
Facebooklinkedin

X12 Tablet Gets Clean Install

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

Rolling Back Fingerprint Reader Driver

I have to laugh at myself a little ruefully. In checking over my Canary test platform just now — the snazzy little ThinkPad X12 Detachable Gen 1 hybrid tablet — I found the too-familiar BEX64 error in the mix. To those not already aware, this flags an out-of-bounds memory access, often from a driver or an associated dll. In this case it was the notoriously picky Synaptics Fingerprint reader. After looking over driver dates and versions, I realized my driver was newer than the official Lenovo offering. Thus, rolling back fingerprint reader driver was exactly the right thing to do. But there was a problem, also of my own making…

The Problem with Rolling Back Fingerprint Reader Driver

I’m relentless about using Driver Store Explorer (RAPR.exe) to clean up old drivers. Needless to say, that means the Rollback driver button in the fingerprint reader’s properties sheet was greyed out. Of course, that’s because the older driver had been removed from the Store. So I had to visit Lenovo support and grab the driver from there. Easily done, armed with the unit’s Serial Number thanks to Lenovo Vantage.

Another complication then presented. Because I was replacing a newer driver with an older one, I had to uninstall the new before attempting to install the old. Why? Because Device Manager doesn’t allow older drivers to over-write newer ones as a matter of policy. That is, Windows enforces this to prevent accidental regressions or security downgrades, so it refuses to overwrite a newer driver with an older one unless the newer one is removed first. An uninstall gets the previous driver out of the way, so the new install can proceed successfully.

All’s Well That Ends Well

I’m 100% confident that the driver swap worked. I’m expecting the fingerprint reader to behave well going forward. What makes me so confident? After installing the driver, I logged out and then used the selfsame fingerprint reader to log back in. It worked, and read my right index fingerprint from the already-defined biometric data at its disposal.

If there had been any issues with compatibility or workability, Windows Hello would have forced me to start afresh. That would mean proving my identity with a PIN, password, or other acceptable data. Then, I’d have had to re-scan my fingerprints to give the reader something to work with to establish my identity.

None of this happened. The fingerprint reader worked on the first try. I’m hopeful this will do away with the error documented in this post’s lead-in graphic. But as with so many other things in Windows-World, we’ll just have to wait and see what happens. Stay tuned!

Facebooklinkedin
Facebooklinkedin

OOB KB5086672 Pops Up

I just got back from my morning constitutional. Windows prompted me for a PIN upon login. Then, the “Welcome” screen took 30-plus seconds to spin before I got to the desktop. “Hmmm,” I said to myself, “whaddya bet an update’s been applied to Flo6?” And indeed, upon inspection of the Update History, out-of-band (OOB) KB5086673 pops up at the head of the Quality Updates list.

Why Say: OOB KB5086672 Pops Up?

Flo6 is set up for maximum stability. Thus, it doesn’t sleep. So, for it to prompt me for system entry, I was pretty sure the PC had rebooted. So I asked Copilot to write me a PowerShell check. And sure enough, the results of running said script (see lead-in graphic) show two quick reboots back-to-back just after 1:30 this morning.

The boot type for both shows up as “0x0” which indicates a cold boot that otherwise proceeded and concluded normally. And indeed certain updates — including this one, as shown — do require a pair of reboots to successfully complete their efforts. Copilot says “That 95-second gap is textbook CU finalization timing” and “the reboot…was Windows completing the update you saw in Update History.” Good stuff!

How the Pop-Up Happened

I’ve got the toggle for “Get the latest updates as soon as they’re available” turned on. I’ve also got active hours set from 7AM to 6PM. So when the update triggered last night nothing stopped it from getting downloaded, applied, and rebooting on its own schedule. That’s how the pop-up happened, and why I saw a login prompt when I sat down in front of Flo6 this morning.

Here in Windows-World, things work the way they’re supposed to quite often behind the scenes and (mostly) unnoticed. The login prompt drew my notice, and I’m happy to say “nothing more to see here.” Let’s get back to work, shall we?

Facebooklinkedin
Facebooklinkedin

Dude, Where’s My Icons?

I just spent a couple of frustrating but informative hours trying to get icons to show up with WinGet on the latest Canary build (29558.1000). What started out as a minor visual quirk turned into a deep dive into the innards for App Installer, feature flags, and system-level packages. I’ll provide a step-by-step list of what I did, what I learned, and what others running Canary builds should know. At this point I’m still asking “Dude, where’s my icons?” for WinGet output. But I now know I won’t see them any time soon. I’ll explain…

Steps in Resolving “Dude, Where’s My Icons?”

The first step was to verify the WinGet version and its capabilities. Running winget –info revealed I was on version 1.29.50-preview. Notably, that output lacked usual capability lines including VT Support or Rich Output. That was my first clue that something wasn’t quite right.

Next, I visited the Microsoft Store. I navigated directly to the App Installer product page using the canonical link. The Store offered an Install button. When I clicked same, I expected it to overwrite the preview build with the stable version. After installation, the Store indeed reported the app as Installed. It lied!

I then closed all terminal sessions and opened a fresh CMD tab to recheck winget –info. Unfortunately, the version remained 1.29.50-preview. Worse still, the missing icon issue persisted. To investigate further, I ran PowerShell as Administrator and executed Get-AppxPackage Microsoft.DesktopAppInstaller -AllUsers. The output showed only one package: version 1.29.50.0, marked as NonRemovable. Was I stuck?

Yes, I Was Stuck…

The crux of the matter rests on how Canary builds handle App Installer. On these builds, the preview version of App Installer is baked into the OS image. Indeed, it’s registered as a system-level package. Because it is marked NonRemovable, neither the Microsoft Store nor PowerShell can uninstall or override it. That explains why even though the Store shows the stable App Installer as Installed, Windows continues to use the preview version.

Yep, sez right at bottom: NonRemovable: True

This locked-in preview build lacks support for feature flags like Visual Icons and Rich Output. Alas, their lack also explains the missing icon column in WinGet output. No attempts at reinstalling, resetting, or tweaking settings.json can override this limitation. Stuck indeed.

Note: the lead-in graphic for this story comes from the Build 29558.1000 announcement blog. I can see that damnable delectable icon there in the posting, but I’ll be darned if I can make it show up on my Canary install. Go figure!

 

 

Facebooklinkedin
Facebooklinkedin

Magician Internal Updater Lags Behind

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

Sandbox Effect Keeps Spreading

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

Reverse DNS Lookup Reveals Router Change

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

Device Zombies Roam Among Us

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

Author, Editor, Expert Witness