Category Archives: PowerShell

Cool Tools, Insider stuff, PowerShell, WED Blog, Windows 11

Spiffing Up P3 Ultra WinTerm

Leave a comment

Having just restored the ThinkStation P3 Ultra Gen 2 to a clean, plain-vanilla Windows 11 image, I’m now tweaking things to make them comfortable and right. One of my primary targets for improvement is the command line. In turn, that has me spiffing up P3 Ultra WinTerm to get things the way I like them.

What Spiffing Up P3 Ultra WinTerm Entails

What follows is the four-layer stack I put together on the P3 Ultra to make Windows Terminal customization actually mean something. You can see the results in the lead-in screenshot above: a segmented Oh My Posh prompt, a rendered 7-Zip application icon courtesy of winget sixels, and a gloriously color-coded directory listing from Terminal-Icons. Here’s how it all fits together.

WinTerm Customization: Font Foundation

The very first thing I do after any clean Windows install — before the wallpaper, before the taskbar tweaks, before I remember I’m supposed to be “keeping it minimal” — is set up a proper terminal environment. On the P3 Ultra running 25H2, that meant opening Windows Terminal and immediately confronting the default Cascadia Mono font, which is fine in the way that a gas-station sandwich is fine. It works. You’re not going to brag about it.

The secret to this entire Windows Terminal customization stack is that absolutely everything else — the Oh My Posh prompt glyphs, the Terminal-Icons file badges, the whole visual language — depends entirely on a Nerd Font being the active terminal font. Without one, every single glyph-based feature renders with less pizazz. You get a terminal that looks like it’s having a small crisis. Not the aesthetic I’m going for.

My pick is CaskaydiaCove Nerd Font Mono v3.4.0 — the Nerd Fonts project’s officially patched version of Microsoft’s own Cascadia Code. That lineage matters. indeed, it looks completely native in Windows Terminal because it essentially is Cascadia Code, just supercharged with 10,000+ additional Nerd Font glyphs packed into the private-use Unicode ranges.

I installed it per-user to %LOCALAPPDATA%\Microsoft\Windows\Fonts, then promoted it system-wide since the P3 Ultra session was already running elevated. One JSON edit in Windows Terminal settings (hit Ctrl+Shift+, to open the file directly), setting “face”: “CaskaydiaCove Nerd Font Mono” inside profiles.defaults.font, and that foundation is laid.

OMP Puts Prompts Right

Oh My Posh (OMP) is the tool that turns my drab PS C:\Users\ed> prompt into a segmented, information-dense status bar that actually tells me things I want to know. In my current setup — visible in the screenshot — the left side shows my username (ed), the current directory, a key glyph, the terminal icon, and the last command’s execution time. The right side displays the shell name (pwsh) and a live clock. It looks and feels sharp. Frankly, it’s the main reason I get excited about a new terminal setup.

Speaking of execution time: the screenshot shows a 0ms result for a quick winget list –details 7zip run, which is gratifying. Less gratifying but no unexpected is the 990ms that appears on the subsequent dir command. That’s Terminal-Icons loading its full icon map on first call, not OMP behaving badly. Well. Mostly not OMP behaving badly. The 990ms is the price of a pretty terminal, and I have decided it is worth it in the same way I decided heated seats were worth it when I bought my last car. Once you have the temperature drops below freezing, the idea of going without feels almost uncivilized.

OMP installs cleanly via winget with winget install JanDeDobbeleer.OhMyPosh. Then, getting it running in PowerShell 7.6.4 (the version running on the P3 Ultra, as you can see in the startup banner in the screenshot) takes exactly one line added to your $PROFILE. That’s an oh-my-posh init pwsh call pointing at your chosen theme JSON. That’s it. Minimal friction, maximum visual payoff.

Winget Icons: Sixel Graphics Come to Life

Here’s the one that still makes me do a small double-take every time I see it: that 7-Zip logo in the terminal is not ASCII art. It is not a colored block approximation. It is the actual, rendered 7-Zip application icon, displayed as a real bitmap inside the terminal window, courtesy of sixel graphics support added to winget in Preview build 1.29.50 and later.

Important: Two Different Settings Files

Enabling sixels requires editing winget’s own settings file — opened with winget settings — not Windows Terminal’s settings.json. These are two entirely separate JSON files. Editing the wrong one produces a very confusing non-result, and I say that with the authority of someone who absolutely did exactly that on the first attempt.

Once you’re in the right file, the change is simple: add “visual”: { “enableSixels”: true } to the JSON, do a full restart of Windows Terminal (not just a new tab — a full close and reopen), and then run –winget list -details [packagename] to see the icon appear. Coverage is currently somewhere around 25–30% of installed packages — Win32 (exe/msi) apps show icons reliably. MSIX packages mostly don’t yet. But seeing 7-Zip’s logo materialize in a terminal window never quite gets old.

Terminal-Icons: Color-Coded Dir Listings

The final piece of the stack is Terminal-Icons. This PowerShell module by Brandon Olin transforms your Get-ChildItem output from a monochrome wall of filenames into a color-coded, glyph-annotated directory listing .. Bonus: it’s easier to scan at speed. Folders get folder glyphs in teal. JavaScript files get the JS badge in orange. Binaries, config files, images, and scripts each get their own visual treatment, all driven by the Nerd Font glyph library that CaskaydiaCove Nerd Font Mono v3.4.0 provides.

Installation requires a single PowerShell line: Install-Module -Name Terminal-Icons -Repository PSGallery -Force. Permanent activation requires adding Import-Module Terminal-Icons to your $PROFILE. After that, dir, ls, and Get-ChildItem all pick up the icons and colors automatically — no further configuration needed. It simply works, which in my experience is not always a given with PowerShell modules.

OK, I’m Happy Now…

Installing this stack — CaskaydiaCove Nerd Font Mono, Oh My Posh, winget sixels, and Terminal-Icons — took me about 10 minutes. The result is exactly what you see in that lead-in screenshot: a terminal that looks like it means business, with a prompt that tells me what I need to know, icons that let me spot my packages and files at a glance, and one very satisfying 7-Zip logo that I have already shown to more colleagues than strictly necessary. It is, as I said to myself at the time, a very spiffed-up terminal. Round Rock, TX never looked so good from a command line. Here in Windows-World, I count that as an accomplishment, of sorts…

 

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

PC Manager Browser Space Is Mostly Volatile

Leave a comment

I just ran PC Manager’s Deep Cleanup on my Flo6 desktop. As usual, it cleaned a lot of what it found: 11.4 of 14.6 GB wound up gone. Also, as usual it shows around 3GB remaining for my three browsers — namely, Firefox, Chrome and Edge. So I asked Copilot: why do these programs show up in their numbers? It opines (and I concur) that PC Manager Browser space is mostly volatile. Indeed the figure is kind of illusory. It’s worth understanding before treating browser cache cleanup as a valid way to recover disk space.

Take a look at the final results from my Deep Cleanup just now from the lead-in screencap. Notice that it shows 1 GB for Firefox, 1.6 GB for Chrome and ~277 MB for Edge. Keep those numbers in mind.

Why Say: PC Manager Browser Space Is Mostly Volatile?

Here’s the core issue: browser cache is engineered to be ephemeral. It’s written, read, and purged in a continuous cycle governed by cache-expiry headers, per-origin storage quotas, and the browser’s own self-management routines. The moment you fire up your browser after a cleanup and start clicking around, the cache begins refilling. Within 30 to 60 minutes of ordinary browsing, most browsers will have rebuilt several hundred megabytes of cached content — sometimes more, depending on how media-heavy the sites you visit are.

Chrome and Edge both enforce internal storage quotas and will self-evict stale or low-priority cache entries automatically when those quotas are approached. In other words, the browser is already managing this space on your behalf, without you lifting a finger. Firefox operates similarly under its own quota management framework.

In short: you didn’t “save” 2 GB when you cleared browser cache. You borrowed 2 GB temporarily — until your next browsing session rebuilt most of it. Sort of like the storage equivalent of pushing water uphill.

Check out these numbers: they represent the memory footprint for my three browsers.

Note that those numbers fall near the potential savings that PC Manager reports for each one. That’s no coincidence, it simply represents reclaiming space that the browsers will suck back up as soon as you turn them back on, and open some tabs.

What Real, Valid Savings Look Like

Contrast browser cache with the categories that represent genuinely permanent space recovery. Windows Update cleanup files — the old installer packages and superseded component stores left behind after updates — can run anywhere from 500 MB to 2 GB, and once deleted, they do not return. Windows Error Reporting logs are similarly non-regenerating under normal conditions. The Recycle Bin is obvious. Orphaned app data left behind by software you’ve already uninstalled is another solid target. Thumbnail cache does rebuild, but far more slowly than browser cache, so it offers a more durable short-term gain.

A typical monthly cleanup on a moderately used Windows 10 or 11 machine might yield up to a 5 GB of truly permanent, non-regenerating space. That’s a lot less dramatic than the headline figure PC Manager flashes at you — but it’s real. And it stays real.

Do You Need to Clean Browser Cache?

Maybe, but go into that effort with adjusted expectations. Clearing browser cache could deliver a brief responsiveness improvement. Thus, if the cache has grown bloated with stale or corrupt entries, or to make room in storage-intense scenarios, such as recording a long screen capture session, installing a large application, or freeing up breathing room on a drive that’s genuinely running tight. Otherwise, don’t expect much either in the short or long term.

If you’re truly short on disk space, PC Manager’s Large Files finder and the Windows Update Files cleanup row are far more useful targets. The browser cache, left alone, will look after itself. That’s the point!

Here in Windows-World keeping things clean does have its reward. But some things are more worth cleaning up than others. Browser cache is near the end of that list, and best left alone.

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

Jumping WinGet’s Install Technology Hurdle

2 Comments

Wow! It’s hard to believe that WinGet has been around for over 6 years now (it made its debut on 5/19/2020). Over those years I’ve seen the upgrade block shown in the lead-in graphic many times. I’ve also learned to deal with it in more roundabout ways. Let me call this jumping WinGet’s install technology hurdle, so I can explain one particular technique worth investigating.

What Jumping WinGet’s Install Technology Hurdle Means

The text at the head of the screen cap recommends “Uninstall each package, then install the newer version.” This will work if there’s no other way. But if — as you can see is the case with Oh My Posh (OMP) — there’s an internal update mechanism, this often works just fine without requiring wholesale removal (uninstall old version) and replacement (install new one).

Indeed, it just so happens that OMP will happily update itself at the command line using the built-in command

oh-my-posh upgrade --force

So that’s what I did instead of running one WinGet command to remove the old package, and another to install the new one. This situation pops up when WinGet detects that a normal upgrade is not feasible. It blocks upgrades whenever the install technology changes from one release to the next. That’s how it avoids potential problems with the package and its supporting infrastructure that might otherwise occur.

But the teams who develop such packages know their inner workings. They can (and often do) support such upgrades because they understand how to hand off from the older install technology to the newer one. When I run into this situation, I look for a built-in update mechanism in the package (or its related app) itself. It will often jump the hurdle for me, and let me keep using WinGet thereafter. Indeed, I’ve done this myself with Adobe Acrobat too. Furthermore, GitHub documents similar cases with MS Edge, PowerShell 7, Oracle VirtualBox, LocalSend, and other packages as well.

But Wait…There’s More!

Even after I got to the latest version, I found a couple of older versions of OMP also installed. Ultimately, I DID have to uninstall those to make them go away. That’s because OMP lets multiple versions run in parallel. This time, I used msiexec and the GUIDS (for the no-longer-wanted versions) for that purpose

msiexec /x "{97557535-43B6-44EF-BA97-86563C1AC80A}"
msiexec /x "{85B43182-5A11-40E5-9E09-7EF6EB1CFDF7}"

Now, I’ve got just the one (updated) version and a clean Oh-My-Posh setup. Here in Windows-World, it’s always something. Thank goodness that Copilot was able to help me steer through the wreckage, and clean up the older versions properly. Now I see only the latest version when I run winget list, and OMP is working as it should be. AND I solved a problem I didn’t know I had. Good-oh!

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

WinGet Shows More Icons

Leave a comment

Here’s an interesting and welcome observation. Installing updates this morning, I noticed that 7 of 10 packages showed icons as Winget did its upgrade thing. (And this came from the 2018 vintage ThinkPad X380 Yoga!) Anecdotally, that’s way up from when icons first started showing up Windows Terminal in early March of this year. I’m delighted to see that WinGet shows more icons than ever before. Mostly that happens as more developers start including the necessary image references in their package metadata. In my sample screenshot (5 packages) every one has an associated icon. I’m jazzed!

Why WinGet Shows More Icons Nowadays

Lots of popular apps now include icon Url fields in their metadata (that’s where those images come from: e.g. VLC, Chrome, FireFox, NotePad++, MTPW, etc.). Microsoft has definitely upped its support for icons as well (e.g. Edge, PowerToys, Terminal, VStudio, .NET runtimes, and more). Indeed, there seems to be a growing wave of developer support as more and more packages now sport icons as WinGet interacts with them.

At the same time, says Copilot, “the WinGet backend now caches and serves icons [more] reliably.” These days icons are cached in the content delivery network (CDN), retrieval is faster and better, and broken URLs are getting fixed. The net-net is that more icons are appearing because there are more of them around, and the mechanisms to show them are working better, too.

Here in Windows-World, that counts as progress. Plus, I love the eye-candy that icons provide within the mostly monochrome Windows Terminal environment. How could you not? Good stuff!

If you’ve not yet turned icons on in your Terminal evironment just yet, never fear. I posted about this on April 10 (2026) in an item entitled How to Light Up Winget Icons. Follow its instrux if you’d like to see them for yourself.

Facebooklinkedin
Facebooklinkedin
Insider stuff, PowerShell, Recent Activity, Updates, WED Blog, Windows 11

WinGet List/Install Orders Seldom Match

Leave a comment

If you run winget upgrade --all --include-unknown regularly, you have probably noticed something odd. The packages listed in the upgrade table rarely install in the order they appear. I hit this recently on my ThinkPad X12 Hybrid Tablet, where six packages needed attention: Google Chrome, Microsoft Teams, MiniTool Partition Wizard Free, Oh My Posh, Patch My PC Home Updater, and Windows App. They were listed in one sequence but installed in a noticeably different one. The explanation stems from WinGet’s dependency resolver. It’s worth understanding, and explains why WinGet list and install orders seldom match each other.

Why Do WinGet List/Install Orders Seldom Match?

As you can see in the lead-in screencap, the upgrade table that WinGet displays before installation is sorted alphabetically by package display name — that is the first (Name) column, not the Id column. It’s purely cosmetic: WinGet queries its source index, collects available updates, and orders the results for human readability. The order in that table carries no weight when determining which package installs first. Think of it as a shopping list arranged by aisle label, not a build sequence.

Install Order Shows a Dependency Graph

Before the first installer touches the PC, WinGet’s dependency resolution engine reads every package manifest in the upgrade set. It constructs a directed acyclic graph (DAG) of declared dependencies. Next, it runs a topological sort namedGetInstallationOrder() on the winget source. That produces an install sequence where no package arrives before its pre-reqs are satisfied. This re-ordered queue need not follow name or ID order.

The X12 Hybrid Tablet Run

In the screencap, you see the raw WinGet output from a recent run on the X12 Hybrid Tablet. Six packages are available, listed in alphabetical order by display name — Chrome, Teams, MiniTool, Oh My Posh, Patch My PC, Windows App. The three declared VCLibs and Windows App Runtime dependencies follwing that list reinforce that notion that other elements than those that appear are in the mix. In the end, the actual install order was MiniTool Partition Wizard, Patch My PC…, Chrome, Teams, Windows App, and finally, Oh-My-Posh.

When List Order and Install Order Do Align

Occasionally the two sequences match — but that is coincidence, not design. It happens when none of the packages in the upgrade set declare inter-package dependencies and WinGet’s internal queue order happens to mirror alphabetical sequence. As soon as one package declares a dependency on another — or on a shared runtime — the topological sort reshuffles the queue and the coincidence evaporates.

A Practical Takeaway

No need to manage this manually. Winget’s dependency resolver handles the sequencing reliably. Indeed, fighting it with flags like --skip-dependencies is rarely worth the risk. Tyring to drive this yourself, you might end up with a package that installs against a runtime version it does not actually support. Trust the DAG, watch the dependency notice block that appears before the first installer fires, and you will get a clear picture of why the WinGet upgrade install order looks the way it does.

Next time you notice that WinGet installs packages out of listing order, check the dependency notice block at the top of the install run. That block is where WinGet “shows its work.” That’s where the topological sort result gets laid out in plain text. It is one of those quiet, well-engineered behaviors that rewards users who take a moment to read the output carefully.

Further proof of my earlier contention (see this June 27 post) that “WinGet knows more than it says.” I think so, but you can make  your own judgement. Here in Windows-World, there’s plenty of room for multiple takes on what’s REALLY going on. This is mine…and I’m sticking to it!

 

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

WinGet Upgrade Knows More Than It Says

Leave a comment

In running through my usual morning Winget Upgrade drill, I noticed that it found 3 upgrades, but applied only 2. As you can see in the lead-in screencap, it concluded its efforts with a line that reads “1 package(s) have upgrades blocked because newer versions use a different install technology…” To me, this means that WinGet Upgrade knows more than it says, because process of elimination reveals that Microsoft Edge is the missing item.

Why Say: WinGet Upgrade Knows More Than It Says

Microsoft Edge is deeply embedded into the Windows 11 OS.  Indeed, Windows 11 uses WebView 2 as a system component. That also powers the Settings app, widgets, Copilot, Teams, Outlook (new), the MS Store, and more. That’s why Edge usually updates more easily from within its own UI anyway.

In this particular case, something about the install technology changed moving from Version 149.0.4022.96 to Version 149.0.4022.98. That forces WinGet to keep its mitts off, unless users uninstall the old and then install the new in two separate operations.

I elected to jump into the app, do the upgrade, then returned to Windows Terminal to run WinGet Upgrade –all –include-unknown again. As you can see in the lead-in graphic (if you right-click that image to display it in its own browser tab), with Edge manually updated already beforehand, the next check returns “No installed package found matching input criteria.” In WinGet parlance that means “no items need updating here.”

In Windows-World, what you see can sometimes tell you more than what your app or tool output tells you. This is a definite illustration, and explains why I assert that the Windows package manager (i.e. WinGet) and its upgrade facility knows more than it says. Cheers!

Facebooklinkedin
Facebooklinkedin
Insider stuff, PowerShell, Recent Activity, Updates, WED Blog, Windows 11

WinGet Copilot CLI Update Gets Interesting

Leave a comment

By design, the WinGet package manager is pretty conservative about working on apps that are running. With Copilot now active on my desktop most of the time, and even accessible in Windows Terminal (or rather, Intelligent Terminal) this goes double. Yesterday, in fact, my attempt at a WinGet Copilot CLI upgrade gets interesting when it fails with an “access denied” error message. Let’s figure this out, and apply a dead-easy fix.

What to Do When WinGet Copilot CLI Update Gets Interesting

You can see the first Winget failure, the fix, and a successful upgrade in series in the lead-in screencap. That fix provides a way to get Copilot out of the way so WinGet can do its thing without the possibility of messing anything up. Figure that Copilot is nearly always on my systems these days into your consideration and the runtime context.

That fix is:

Stop-Process -Name Copilot -Force -ErrorAction SilentlyContinue

Now, let me explain what’s going on, and this fix does the trick.

Why the First WinGet Upgrade Failed

The root cause is straightforward Windows behavior. The operating system won’t let any process overwrite a running executable. If you had an active terminal session that loaded the Copilot CLI — or any background shell or process that previously invoked it — the old copilot.exe is locked. The installer cannot swap in the new binary, so it fails, and reports explanatory error info.

This is not a WinGet bug. But WinGet could arguably handle it more gracefully. It could detect running processes before the upgrade begins and warn the user. Instead, it downloads everything, then fails at the last step. That may be disconcerting, or perhaps even frustrating, but it’s easily fixed.

The Fix: Kill All Copilot Processes, Then Retry

The fix is a two-step sequence. First, kill any running Copilot processes. Then retry the WinGet upgrade. In PowerShell, do that by running these two commands in sequence:

Stop-Process -Name copilot -Force -ErrorAction SilentlyContinue
winget upgrade GitHub.Copilot

[Note the first two lines are actually a one-liner with a spillover resulting from local formatting; run as a single command.] That’s what the screenshot at the top of this post illustrates. The first command runs cleanly even if no matching process exists. The
-ErrorAction SilentlyContinue flag does that by design and intent.

The second winget upgrade command then finds the package again, verifies the hash, extracts the archive, and this time completes successfully. You will see two confirmations appear: “Overwriting existing file” for the WinGet Links path, and “Command line alias added: ‘copilot’.” Then, finally: “Successfully installed.”

Noteworthy Postscript

A couple of additional observations from this experience deserve mention. First, note that Copilot CLI lists Microsoft.PowerShell (version 7.0.0 or later) as a required dependency. If you have not yet upgraded to PowerShell 7.x, WinGet may attempt to pull that in first. In this case, PowerShell 7.6.2.0 was already current, so that dependency check passed instantly.

Second, if you run WinGet from within VS Code’s integrated terminal, Windows Terminal, or any shell that has previously invoked gh copilot, (gh = GitHub, and is the target for copilot requests in a shell environment) you may hit this exact error. Opening a completely fresh PowerShell window before running the upgrade is often enough to sidestep the issue entirely. In that case, no Stop-Process is needed.

Third, this pattern is not unique to Copilot CLI. Any WinGet-managed package that ships as a standalone executable can run into this same locked-file problem during upgrades. Ditto for Web browsers (e.g. Chrome, Edge, Firefox, etc.) which many users, including your humble correspondent, tend to leave running all the time. For browsers the update may fail, it may not run at all, or you may need to “Relaunch” the browser so the updater applies that change file.

A Predictable Bump in the Road

WinGet is a solid package manager. It delivers smooth, hands-off upgrades nearly all the time. When it stumbles — as it did here — its error messages are descriptive enough for a quick diagnosis and fix.

One command to kill the offending process, a second WinGet command to retry, and you’re done. It is a minor contortion, but now you know that two-step. Here in Windows World, it’s good to keep tools current. To that end, don’t let a transient file lock slow you down. Fixed!

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

Troubleshooting Flo6 S3 Sleep Oddities

Leave a comment

Now that I’m back to a normal work pattern, I couldn’t help but notice that the power button on my Flo6/MSI B550 Tomahawk PC was blinking this morning. That means it’s sleeping and needs a touch to wake itself back  up. Indeed, that blinking power button is the unmistakable signature of S3 sleep — Suspend to RAM — where the system cuts power to everything except memory. Nobody asked it to do that. Time to find out why it thought that was a good idea. Hence, I found myself troubleshooting Flo6 S3 sleep oddities.

Troubleshooting Flo6 S3 Sleep Oddities: Step 1

My first move with any uninvited sleep behavior is to open an elevated command prompt and run powercfg /a. This dumps a plain-English summary of every sleep state the OS currently considers available — and, crucially, tells you which ones are actually enabled. The lead-in graphic shows what Flo6 reported.

That told me everything I needed to know at a glance. S3 was alive and well. Hibernate was also active. Windows had a full menu of power-down options available to it, and apparently it was helping itself. The next question was: what power plan setting was pulling the trigger?

Step 2: Drilling deeper

To see exactly what the current power scheme was telling Windows to do with sleep, I queried the sleep sub-group directly with powercfg /query SCHEME_CURRENT SUB_SLEEP. The output is verbose, so here’s the relevant section I was hunting for:

0x00004650 is 18,000 decimal — 5 hours on AC power. So Windows was faithfully sleeping Flo6 after 5 hours of perceived inactivity, exactly as I’d told it to in recovering from a recent, ill-advised troubleshooting test that reset all my sleep options. Nothing malicious, nothing mysterious. Just a setting I’d explicitly configured sitting where I’d put it, also wrong. Time to kill it.

Pulling the Plug on the Sleep/Wake Timers

I wanted three things gone: the Sleep After timer, Hybrid Sleep, and Wake Timers. Setting any timeout value to 0 disables it. I ran the following commands, covering both AC and DC (battery) power states for completeness, even though Flo6 is a desktop that will never run on battery:

As a belt-and-suspenders measure, I also went into Device Manager, expanded the Universal Serial Bus controllers node, and for each USB Root Hub, opened Properties > Power Management and unchecked Allow the computer to turn off this device to save power. USB Selective Suspend has a well-documented history of nudging systems toward sleep states in ways that aren’t immediately obvious from power plan settings alone. Worth the two minutes it takes to disable it across the board.

The EC Reset: Clearing the Firmware’s Memory

OS-level changes are necessary, but they don’t always flush stale power-state data that’s been cached at the firmware level. The MAG B550 Tomahawk MAX has an Embedded Controller that can hold onto a previous power state even after you’ve changed every relevant Windows setting. The fix is straightforward: shut Flo6 down cleanly, flip the PSU switch off, unplug the AC cord, then hold the case power button for 15 to 30 seconds. This drains the residual charge and forces the EC to reinitialize from scratch. Reconnect everything, power on, and let the board POST fresh. It’s a small step, but it closes a gap that software alone can’t address.

Verdict: Flo6 Should Stay Awake

Hopefully, Flo6 makes it through the night — and several nights after that — without a single uninvited nap. No blinking power button at 6 AM, no dead monitors, no manual wake required. For extra confidence, I’ve got a scheduled Task Scheduler job logging system uptime to a text file every hour overnight. If S3 ever comes back uninvited, I’ll have a timestamp trail to work from. IMO, one week’s worth of clean logs is good enough for me to call this one closed.

If I’ve missed anything, the blinking power button will be back. I hope not, but here in Windows-World anything is possible. If it’s not “case closed” I’ll report back with an addendum here. Fingers crossed that won’t be needed…

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

WinGet Iconification Is Ongoing

Leave a comment

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
Cool Tools, Insider stuff, PowerShell, Recent Activity, WED Blog, Windows 11

How-To: Light Up Winget Icons

Leave a comment

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