Category Archives: Cool Tools

Using WinLogo Glyph in FastFetch

FastFetch is a lightning-fast system information tool that runs in the terminal and displays your OS, CPU, GPU, memory, and disk details in a clean two-column layout. It ships with built-in text-art logos for major OSes. Alas, the default Windows logo in FastFetch is a modest ASCII rendering using the letter “l”. This post shows you how to replace it with the Windows 11 Nerd Font glyph. I call it the WinLogo glyph myself. And indeed, using the winlogo glyph in FastFetch is easy thanks to two short PowerShell scripts.

How Easy Is Using WinLogo Glyph in FastFetch?

Nerd Fonts are patched programming fonts that include hundreds of extra icons in their Private Use Area. The Windows 11 logo lives at Unicode code point U+E62A. When your terminal uses a Nerd Font such as CaskaydiaCove Nerd Font or JetBrainsMono Nerd Font, that code point renders as the familiar four-pane Windows 11 logo.

However, each U+E62A glyph is double-width. In other words, it occupies two terminal columns rather than one. That behavior matters when you configure FastFetch’s width parameter, as I’ll show later on. Knowing this upfront saves you trial and error later.

How FastFetch Reads a Custom Logo File

FastFetch supports a logo type called file. With this type, FastFetch reads a plain-text file and renders its contents to the left of your system information panel. Inside that file, color tokens such as $1 map to ANSI colors you define in config.jsonc. FastFetch re-applies the color at the start of each logo line, so any segment that needs consistent coloring must carry its own $1 re-arm token.

The design I used is a 2×2 arrangement of four 8×8 glyph blocks. Together, they form a large Windows logo built from smaller Windows logos. Each row contains two groups of eight glyphs separated by four spaces, with a single space between individual glyphs inside each group. A single blank line divides the top two blocks from the bottom two, giving the overall shape a clean four-pane look.

The key trick: after the left block and the four-space gap, FastFetch can silently drop the active color. Adding a second $1 token directly before the right block re-arms the color and keeps both sides uniformly blue across all 17 lines of the file. I figured this out by experiment, but I’m happy to share this “secret” openly.

Example 1: Writing the 8×8 Logo File

Run the following script in PowerShell 7. It writes the logo file with UTF-8 no-BOM encoding, which FastFetch requires to interpret this glyph correctly.

Example 1: win11logo.txt generator

$g = [char]0xE62A
$b = "$g $g $g $g $g $g $g $g"
$r = '$1 ' + $b + ' $1' + $b + ' '
$gap = '$1 ' + (' ' * 28)
$logo = ($r,$r,$r,$r,$r,$r,$r,$r,$gap,$r,$r,$r,$r,$r,$r,$r,$r) -join [char]10
[System.IO.File]::WriteAllText(
"$env:USERPROFILE\.config\fastfetch\win11logo.txt",
$logo,
[System.Text.UTF8Encoding]::new($false)
)

Note: the foregoing text is formatted for cut’n’paste use. Parsing it for human readability doesn’t work well in WordPress. Sorry! If you don’t have a fastfetch directory set up, start with this ahead of the previous commands: New-Item -ItemType Directory -Force "$env:USERPROFILE\.config\fastfetch" | Out-Null.

The [char]0xE62A expression converts the Unicode code point to an actual glyph character at runtime. The backtick before each $1 token tells PowerShell to treat the dollar sign as a literal character rather than the start of a variable name. The $gap variable fills the blank middle row with enough spaces so that FastFetch won’t collapse it.

Example 2: Write the FastFetch Config File

With the logo file in place, the next step is updating config.jsonc. The width value tells FastFetch how many columns to reserve for the logo panel. FastFetch counts each glyph as one character, not two display columns. Therefore, set width to the character count of the longest line in the logo file, not to the visual column count. For this 8×8 layout, that value is 38.

The height value is 17, matching the total line count of the logo file: eight rows, one blank gap row, and eight more rows. The color key maps $1 to Windows blue via the 24-bit ANSI code 38;2;0;120;212. A trailing space at the end of each logo row ensures the rightmost glyph renders in blue rather than in the terminal’s default foreground color.

Example 2: config.json generator
$lp = ("$env:USERPROFILE\.config\fastfetch\win11logo.txt") -replace '\\','/'
('{"logo":{"source":"' + $lp + '","type":"file","color":{"1":"38;2;0;120;212"},"width":38,"height":17,"padding":{"top":0,"left":1,"right":1}},"modules":["title","separator","os","host","kernel","uptime","packages","shell","display","cpu","gpu","memory","disk","battery"]}') | Set-Content "$env:USERPROFILE\.config\fastfetch\config.jsonc" -Encoding utf8NoBOM

Tips and Gotchas

A few points are worth keeping in mind before you run these scripts.

First, the default font must be a Nerd Font. The U+E62A glyph renders as a plain box or question mark in any non-patched font. CaskaydiaCove Nerd Font, JetBrainsMono Nerd Font, and FiraCode Nerd Font are all reliable choices that include the Windows logo glyph.

Second, width tuning requires some trial and error. If the right-side block renders in white instead of blue, increase width by two or three. If the gap between the logo and the info panel is too wide, decrease width by the same amount. The trailing space in each logo row prevents the rightmost glyph from getting clipped by the color boundary.

Third, always use Set-Content with -Encoding utf8NoBOM for the config file and [System.IO.File]::WriteAllText with an explicit UTF8Encoding $false object for the logo file. PowerShell’s default encoding on Windows adds a byte-order mark that FastFetch does not handle gracefully when reading Nerd Font glyphs. I learned this the hard way, so you don’t have to!

Enjoying the Fruits of Your Labor

After both scripts run, type fastfetch at the prompt. You should see a bold, blue 4×4 Windows logo grid on the left, assembled from 256 individual Windows 11 glyphs, flanking a full system information panel on the right. The result is a visually striking terminal greeting that is entirely Windows-native in spirit and thoroughly custom in execution.

The WinLogo glyph in FastFetch is a small but satisfying way to put your personal stamp on your PowerShell environment. If you tweak the grid size or colors, the same two-script approach scales to any N x N layout you prefer.

Here in Windows-World, I get my jollies where I can find them. Today, I found them using a Windows 11 logo glyph for my OS logo in FastFetch. Where will my jollies come tomorrow?

Facebooklinkedin
Facebooklinkedin

WinGet Misses ARM Browser Updates

If you run winget upgrade --all on an ARM-based Windows 11 PC (e.g. an Asus Zenbook A14), you may notice something odd: Chrome and Firefox don’t show in the upgrade list, even when they’re out of date. On an x64 desktop, winget catches them without fail. So what gives? Briefly put, and for various reasons, WinGet misses ARM browser updates for certain implementations.

It turns out there are four overlapping bugs and design gaps at play. All of them affect ARM64 PCs. None of them are your fault, either. But together they form a perfect storm that makes WinGet effectively blind to certain browsers. For now, anyway.

TLDR: On ARM64 Windows PCs, WinGet fails to detect and upgrade Chrome and Firefox due to four compounding issues: a name-normalization bug (winget-cli #6490), a registry hive mismatch, a broken ARM64 manifest entry for Chrome, and an architecture-selection bug (winget-pkgs #424881). Until Microsoft patches these, a handful of workarounds fill the gap. Here goes…

Diving in: Why WinGet Misses ARM Browser Updates

On x64 machines, the registry is simple: one hive, one architecture tag, and manifests that have been battle-tested for years. WinGet’s upgrade logic originates from that x64 worldview. Alas, things on ARM64 aren’t quite so simple, and all four failure modes described next come out of various diversions from the x64 situation.

Four Root Causes

  1. The ARP Name-Normalization Bug (winget-cli #6490)

Winget matches installed apps to its catalog by reading Add/Remove Programs (ARP) registry entries and normalizing display names. It strips “x86” and “x64” — but has no handling for “arm64” or “ARM64.” When Chrome or Firefox registers with an ARM64 architecture suffix on a Snapdragon device, winget cannot correlate it to the catalog entry and silently drops it. The app becomes invisible to winget upgrade.

  1. The Registry Hive Mismatch

ARM64 Windows splits app registrations across 3 registry hives:

 

Hive Contents Who Writes There
SOFTWARE\…\Uninstall Native ARM64 apps ARM64 installers
SOFTWARE\WOW6432Node\…\Uninstall x64-emulated apps x64 installers (Chrome, Firefox legacy)
HKCU\SOFTWARE\…\Uninstall Per-user installs Either architecture

 

If Chrome or Firefox were installed via an x64 installer — the only option before both browsers shipped native ARM64 builds — it lives in WOW6432Node. Winget, running as a native ARM64 process, reads the native hive first and, when name normalization is also broken, frequently misses those emulated entries entirely.

  1. The Broken Chrome ARM64 Manifest

Even when winget finds Chrome, the Google.Chrome manifest in the community repository lists an arm64 installer entry with a blank SHA256 hash. Winget requires a valid hash to verify any upgrade — blank means the ARM64 path is present on paper but non-functional. The Google.Chrome.EXE package ID does carry a properly populated hash, which explains why some users get inconsistent results depending on which package ID is in play.

  1. The Architecture Selection Bug (winget-pkgs #424881)

Even with a complete, valid manifest, winget’s upgrade logic has a documented bug where it selects the x64 installer over arm64 on Windows on ARM machines. Best case: you get the slower, emulated build pushed onto your ARM device. Worst case: the upgrade fails outright.

Viable WinGet Workarounds

Until Microsoft ships fixes, here are some WinGet options — from most precise to most blunt:

  1. Force the architecture explicitly: Use winget upgrade Google.Chrome --architecture arm64 and winget upgrade Mozilla.Firefox --architecture arm64. This bypasses both  correlation and selection bugs in one go.
  2. Use the Chrome EXE package ID: winget upgrade Google.Chrome.EXE --architecture arm64 hits the manifest entry that actually has a valid SHA256 hash for ARM64.
  3. Let the browsers self-update: Both Chrome (Google Update/Omaha) and Firefox (Mozilla Maintenance Service) are fully architecture-aware. Help → About in either browser triggers an immediate, correct ARM64 update — no winget involved, no ARM64 drama.
  4. Add --include-unknown as a catch-all: winget upgrade --all --include-unknown is a blunt instrument, but it sometimes remcatches apps that fail normal ARP correlation.

The real, true fix requires Microsoft to patch name-normalization and upgrade architecture-selection logic in winget-cli. Two of the four bug reports were filed in the last few days, so movement could come soon. Until then, –architecture arm64 is the cleanest workaround on your Zenbook A14 — or any other Snapdragon-powered Windows machine. In Windows-World, knowing where the bodies are buried is half the battle.

Facebooklinkedin
Facebooklinkedin

FAT32 UFD Nixes “Repair My PC”

Here’s an interesting one. I tried out the latest Garlin scripts this morning (dated 8/24). The boot media check turned up something new. It reported that a new Windows 11 facility wouldn’t run from my MCT-based Windows installer UFD. And indeed, upon investigation, it turns out that using a FAT32 UFD nixes “Repair my PC” capabilities in WinPE. But that’s for a good and understandable reason, as I’ll explain.

TLDR version: Boot an MCT-generated Windows 11 setup USB and click “Repair your computer.” On many FAT32-formatted drives, including these, nothing happens. That option is simply broken. Here is why, and what you can do about it.

Why FAT32 UFD Nixes “Repair My PC”

Windows 11 setup media built with the Media Creation Tool on a FAT32 drive hits a hard wall. FAT32 caps individual file sizes at 4 GB. A Windows 11 install image blows past that ceiling.

Microsoft’s solution is to split the image into two files named install.swm and install2.swm(swm is, of course, a “split WIM file” ICYDK). On the drive I examined, that pair totaled about 5.6 GB compressed. Setup.exe handles this format just fine during installation. The problem surfaces elsewhere.

WinPE Can’t Find (or Handle) the Source

Clicking “Repair your computer” in the Setup UI triggers a search. The WinPE environment in boot.wim looks for install.wim or install.esd in the sources folder. Neither file exists on a FAT32 UFD.

Only install.swm and install2.swm are present. WinPE recovery tools cannot enumerate split WIM files for repair operations. They expect a single, monolithic image file. Without it, the repair chain fails before it starts.

Please note that this is neither a certificate nor a Secure Boot issue. Garlin confirmed that all signing credentials in boot.wim were valid. Strictly speaking, the “broken” label emerges from a missing monolithic image, nothing more.

NTFS Can Fix What’s Broken, But…

The root cause is FAT32. The cure is straightforward: rebuild the drive using NTFS.

Rufus handles this cleanly. Point it at a Windows 11 25H2 ISO, choose NTFS as the file system, and let it run. NTFS has no 4 GB per-file ceiling. A Rufus NTFS build produces a single install.wim that WinPE can locate and read without complaint.

Rufus also ships a current, properly signed bootloader. That quietly resolves a secondary Garlin finding as well: a BANNED bootx64.efi signed by the deprecated Production PCA 2011 certificate. On an NTFS Rufus build, that file is replaced automatically.

Practicing Proper WinRE/WinPE Repairs

A FAT32 Windows 11 setup USB remains fully functional for clean installs. The split WIM has no effect on setup.exe. However, the “Repair your computer” path is dead on arrival.

On a machine that refuses to boot, that missing option could matter a great deal. Building setup media on NTFS costs nothing extra. Rufus is free, and a rebuild takes only a few minutes.

For a USB you may need under pressure, a working repair option is worth the small extra effort. That said, I have observed that some PCs (notably, various Lenovo and Toughbook laptops in my custody) simply won’t boot to an NTFS-formatted UFD. That takes “Repair my PC” off those particular tables, for good or ill.

Check It for Yourself

Run Garlin’s check-bootmedia script against your Windows 11 setup drives. If you see ‘Repair My PC’ is broken in WinPE, you now know why that shows up. If you rebuild on NTFS using Rufus with a current ISO, that repair option will be there when you actually need it. But only if your target PC will boot from an NTFS-formatted UFD. That’s why you have to check! Here in Windows-World, it’s best to know such things beforehand.

Note to Microsoft: Maybe you guys should buy or license Rufus so you can quickly jump MCT and “Create a recovery drive” into a completely modern, Secure Boot aware (and friendly) stance. IMO, that’s a good idea, so please give it some thought.

Oho! There’s ANOTHER Garlin Script for That…

Turns out you can download and apply yet another Garlin script to fix this very issue. It’s called Repair_My_BootWIM.ps1. Run it against your offending boot media and the problem gets fixed automagically. It just worked on my test G: drive created from MCT last week. No Rufus needed. Go figure!

Notice the text that reads “‘Repair My PC’ is broken in WinPE.”  no longer appears. Fixed!

Facebooklinkedin
Facebooklinkedin

Windows Neofetch Alternatives

If you’re ever seen Neofetch, you’re likely to want something like it for Windows. It’s a command-line tool that displays a quick system snapshot. It shows OS version, CPU, GPU, RAM, uptime, shell, storage and more, alongside a rendering of the OS logo as “ASCII art.” But Neofetch is mostly a Linux/Unix thing that requires a Bash shell to run. It was also archived in April 24. It still works, but there are better choices for Windows. For those seeking Windows Neofetch alternatives, the best options are fastfetch and winfetch.

Windows Neofetch Alternatives Are Helpful, or Necessary

Again: Neofetch is a Bash script. That explains most of the friction inherent in running Neofetch on Windows. That is, it requires Git Bash or WSL — neither of which is a native Windows tool. The script itself froze at v7.1.0 when the repository was archived. Worse, going forward Neofetch is dead in the water: no updates, no bug fixes, no future-forward functionality.

Think about what Neofetch actually does: it reads your OS version, CPU, RAM, and a handful of other system facts, then prints them alongside an ASCII logo. Running an outdated Bash script through a compatibility layer to accomplish that feels like overkill. Native tools handle this job more cleanly, more quickly, and without the extra dependencies.

2 Strong Alternatives: Fastfetch and Winfetch

Both of these facilities are actively maintained, and update regularly. Either one can take over for Neofetch without skipping a beat.

Fastfetch

Fastfetch is written in C and installs as a native binary. Speed is its calling card — it fetches and renders system info noticeably faster than Neofetch ever did. Cross-platform support (Windows, Linux, macOS) makes it useful across mixed environments. Install it with any of the major Windows package managers:

winget install fastfetch

Once installed, launch it by typing fastfetch at any prompt. Configuration lives in a JSONC file, so customization is straightforward and version-control friendly. Here’s what it looks like on my AMD-based Flo6 desktop (click image to enlarge):

Winfetch

Winfetch is a pure PowerShell script — Windows-only, and deliberately so. It installs directly from the PowerShell Gallery:

Install-Script winfetch -Scope CurrentUser

For anyone already running Windows Terminal with an Oh My Posh prompt and Nerd Fonts, winfetch slots right in. The output renders cleanly alongside a styled prompt, and the whole setup feels native rather than bolted on. You can see it in the lead-in screencap.

The Winfetch Path Gotcha

What the lead-in graphic shows is me getting past the requirement that the winfetch script must be somewhere in $PATH to work. In fact, after I installed it, I got this error when I tried to run it:

Error

winfetch : The term ‘winfetch’ is not recognized as the name of a cmdlet, function, script file, or operable program.

This happens because the installer drops the script into a specific, pre-assigned folder:
C:\Users\Documents\Powershell\Scripts\
Powershell does not, however, automatically add that folder to the $PATH environment variable. So even though the script is installed, it doesn’t run from the command line. Easily fixed, however, as also shown in the lead-in graphic, through a series of simple steps.

Fixing Winfetch, Step-by-Step

Step 1: Confirm the install location

Run this to verify exactly where the script landed:

Get-InstalledScript winfetch | Select-Object Name, InstalledLocation

Step 2: Run it directly as a workaround

Before touching PATH, you can invoke winfetch immediately using its full location:

& "$((Get-InstalledScript winfetch).InstalledLocation)\winfetch.ps1"

That works, but typing it every time is obviously impractical. The permanent fix takes about ten seconds.

Step 3: Add the Scripts folder to PATH permanently

Open PowerShell and run the following command to append the Scripts folder to your PATH inside your profile:

Add-Content $PROFILE "`n`$env:PATH += `";`$([System.Environment]::GetFolderPath('MyDocuments'))\PowerShell\Scripts`""

Then reload your profile in the current session:

. $PROFILE

After that, typing winfetch works cleanly from any new PowerShell session. No more “not recognized” errors, no manual path juggling.

Tip: Execution Policy

If PowerShell refuses to run the script at all, check your execution policy first: Get-ExecutionPolicy. A setting of Restricted blocks all scripts. Set it to RemoteSigned with: Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

Which to Use: Winfetch or Fastfetch?

The choice comes down to how you work, not which tool is objectively better.

Tool Best For Install Method Config Format
Fastfetch Speed, cross-platform use, binary simplicity winget install fastfetch JSONC file
Winfetch PowerShell-native feel, Windows Terminal + Oh My Posh setups Install-Script winfetch -Scope CurrentUser PowerShell config script

Reach for fastfetch when you want something fast, dependency-free, and portable across platforms. Winfetch makes more sense if you live inside PowerShell and want the output to feel like it belongs there — especially alongside Windows Terminal and a styled prompt. Both tools beat neofetch on Windows in 2026. Pick one and move on. Either way, you get a clean, colorful system info display — and you leave a frozen Bash script behind where it belongs. That’s about as good as tradeoffs get here in Windows-World. Cheers!

Facebooklinkedin
Facebooklinkedin

Open Apps Maximized Is Nice

With the release of Beta Build 26220.9223 last Friday (Aug 21), MS now includes an “Open apps maximized.” It shows up in Settings > Accessibility > Visual effects, shown in the lead-in screencap. The feature is pretty handy, even for those who don’t work around visual impairment. Indeed, Open apps maximized is nice for all kinds of users, including your humble author. Indeed, I usually work with key tools (e.g. Office apps, text editors, WinTerm, networking tools, and so forth) maximized anyway.

If Open Apps Maximized Is Nice, Do You Use It?

It’s a matter of working style. If you regularly use apps maximized, it can be a small time-saver, that’s for sure. Interestingly, for apps with restricted max window sizes (e.g. PC Manager, CPU-Z, Core Temp, and so forth), the windows still open at their normal sizes. So it doesn’t ALWAYS fill a display with the app windows you open. That only happens for apps that allow themselves to cover that whole space already.

Even better, if you open an app in full-screen mode courtesy of this new Settings option, you can still click the “Restore down” button to return the window to whatever size you had it set at beforehand. At that point, you can still re-size the app window however you like it. Windows remembers this setting, so with “Open apps maximized” toggled on, it will return to the current sizing when you click the middle button in the top right trio (Minimize/Maximize (up) or Restore Down/Close).

Who Needs “Open Apps Maximized?”

Anybody who wants it. It’s a simple and easy UI behavior option. Personally, I like it in concept. I need to live with it for a while to see how I like it in practice. My intuition, such as it is, tells me MS might benefit from refining this further into a per-app control (e.g. Apps > Default apps or Apps> Startup do this already).

Here in Windows-World, setting default behaviors can be good or bad. You must decide what works best for you, and act accordingly. I’m still deciding if the new “Open Apps Maximixed” works for me or not. When I make that decision toggling this setting on could become part of my standard Windows set-up actions, or not. We’ll see. But it’s cool and potentially helpful nevertheless.

Facebooklinkedin
Facebooklinkedin

Managing Macrium Reflect Keys

Right now, I’m paying for 8 keys’ worth of Macrium Reflect X Home. I just conducted a survey of all the machines here at Chez Tittel and observed that only 2 currently run Reflect X, 2 run Reflect 8, and the rest run something else. Since I’m paying for 8 and currently have 8 machines at hand, I could use them all. As I’ve been managing Macrium Reflect keys, I have to compliment the company’s web interface  at manage.macrium.com/. It now works lots better than it did the last time I messed with it.

You can see part of the License info page as the lead-in graphic. Quite naturally, it doesn’t show any license keys. But it does show which ones are available, when they come up for renewal, and more. It also offers controls to add more info or revoke the license for some current installation. Nice!

Better Use from Managing Macrium Reflect Keys

Indeed, the key list now shows status, and provides controls to give each one a ‘friendly name.’ For those of mine in actual use right now, I assigned the associated machine name. That lets me know exactly which PC has which license, which is just what I want. The other licenses show “Available” which tells me I can use them if I want to.

When I tried to free up one license, however, instead of allowing the “Reset License” operation to proceed (that’s what Macrium calls it), it asked me to submit a support ticket. So that’s what I did. I’ll be interested to see what kind of response that engenders, and how soon it appears.

The Round Tuit Has Arrived!

I’ve been meaning to do this for 6 months or more. But I’m glad I’ve gotten my licenses organized. I’m even gladder to use the ‘Friendly Name’ feature to show me which PC is using which license. I plan to stay in that habit going forward. I also plan to install another copy on AsusSnap (my lone Snapdragon X based laptop right now) because Reflect X is unusally adept and speedy at backup on such CPUs.

Here in Windows-World, it’s not always about solving problems and fixing things. Sometimes, it’s about making the time to keep things neat and orderly. I’m glad I got the backup act together here. I’m sure I’ll find other, similar tasks to tackle, when I have time. Stay tuned: I’ll tell you all about it.

That Was QUICK! Note Added 1 Hr Later

The response from Macrium was as quick as such things get. It’s already fixed. They didn’t tell me why I couldn’t reset the key myself, but they did reset it for me. Now that’s what I call great service. And now, I’ve got six (count ’em: 6) Macrium Reflect X licenses to play with. A truly happy ending: thanks Francisco (name of service agent who handled my request)!

 

Facebooklinkedin
Facebooklinkedin

Oh My Posh Shows Real ARM vs x64 Differences

Following the Oh My Posh documentation, I recently ran oh-my-posh font list on my ASUS Zenbook A14 . It’s a Qualcomm Snapdragon X Elite ARM64 machine running Windows 11. The result? Nothing. No output, no error, no interactive list, just a blinking cursor that eventually handed the prompt back to me. That same command works beautifully on all my x64 PCs and laptops. Thus, Oh My Posh  shows real ARM vs x64 differences. Indeed, this sent me down a rabbit hole to figure out what OMP’s font subsystem does under the hood.

How Oh My Posh Shows Real ARM vs x64 Differences

When you run oh-my-posh font list on a working x64 machine, you get a list of available Nerd Fonts pulled live from GitHub. You can scroll that list, select a font, and it copies the name into the paste buffer for subsequent re-use. It’s helpful.

On my ARM64 Zenbook, none of that renders. The command exits silently. No crash, no error code, no partial output. That silence is itself a clue.

Inside the Oh-My-Posh Font Subsystem

OMP is written entirely in Go, and its font subsystem layers several platform-specific APIs and third-party frameworks. Understanding what those are and how they work explains why ARM64 falls short.

The first dependency is Bubble Tea a terminal oriented display and interaction UI. OMP’s font commands use Bubble Tea’s program model to launch, render, and manage the font list. Bubble Tea drives the terminal via ANSI/VT escape sequences and calls into Go’s golang.org/x/term package to manipulate terminal raw mode. On x64 Windows, Windows Terminal’s VT rendering pipeline handles these sequences without issue. On ARM64, subtle gaps in how the ARM64 console host processes certain VT sequences — particularly around alternate screen buffers and raw-mode toggling — can cause Bubble Tea’s rendering loop to fail before it draws a single line.

The second dependency is a live HTTPS call to the Nerd Fonts GitHub Releases API, which is how OMP fetches the current font list. This call goes out over Go’s standard net/http TLS stack. On ARM64, Go’s TLS implementation compiles natively, but the ARM64 binary links against a slightly different set of system crypto libraries. If that HTTP call fails silently, owing to a timeout, a TLS handshake hiccup, or a missing response, Bubble Tea never receives the data it needs to populate the list, and the program exits with nothing to show.

The third set of dependencies covers font installation: GDI32’s AddFontResourceW function (called via Go’s syscall and unsafe packages), Windows Registry writes through golang.org/x/sys/windows/registry, and a PostMessageW broadcast carrying WM_FONTCHANGE to notify the shell that new fonts are registered. These are the plumbing that oh-my-posh font install uses after the list is displayed. They are less relevant to the silent-exit problem, but they represent additional surfaces where ARM64’s native API behavior diverges from x64.

Where ARM Falls Down (or Out)

The core issue is that OMP’s font tooling was developed and battle-tested on x64 Windows. The Bubble Tea TUI path, the live GitHub fetch, and the GDI32 font registration flow all work reliably there. ARM64 Windows is a native platform now — not emulation — but the console host, terminal rendering, and system library behavior still carry edge cases that x64 does not.

Bubble Tea’s dependency on terminal raw mode and VT escape handling is especially fragile on ARM64 because Windows Terminal’s ARM64 build has historically lagged behind x64 in VT conformance. A Bubble Tea program that initializes correctly on x64 can silently short-circuit on ARM64 if golang.org/x/term‘s raw-mode call returns an unexpected result, causing the event loop to spin zero times and exit.

The irony is that OMP itself — the prompt rendering engine — works great on ARM64. The font management tooling sits on a different, more complex stack, and that stack exposes the seam between x64-matured tooling and an ARM64 Windows environment that is still catching up.

Takeaways for ARM Users

If you hit silent output from oh-my-posh font list on an ARM64 Windows machine, you now know it is not user error. It’s a real platform gap rooted in Bubble Tea TUI compatibility, live HTTP fetching, and ARM64 console API edge cases. The workaround for the moment is to install Nerd Fonts the old-fashioned way: grab the zip directly from the Nerd Fonts GitHub releases page and drop the TTF files into your user fonts folder manually. It’s not as elegant as OMP’s interactive installer, but it gets the job done.

This kind of difference is exactly why I find ARM Windows fascinating. The platform is capable, but it still surfaces small, instructive wrinkles like this one. Though I’ve seen nothing to make me question my investment in ARM hardware, oh-my-posh font list returning nothing is about as vivid a demonstration as I have seen of possible impacts of platform differences. That’s a thing worth watching out for, here in Windows-World.

Note: Only newer OMP versions (30.X.X) and higher support the font list capability. If you’re run the bog standard version on x64 (v29.0.2) you won’t see it, either. Winget should get the latest version (30.6.5) into its pipeline soon, after which you can see it, too. On the right kind of PC, anyway…

Facebooklinkedin
Facebooklinkedin

Lenovo Recovery UFD Works, But…

I’ve been documenting the path away from a stuck (and incorrect) Dev Channel build to a clean install of production 25H2 on my ThinkStation P3 Ultra for nearly two weeks now. Today’s episode is a simple one. After problems getting the device to boot to any UFD, I ordered a Lenovo factory recovery USB directly from Lenovo (see my “It’s the Layout, Stupid” post for more info). Last night, it arrived in a plain padded envelope, and I inventoried it. That’s the whole story. Except, of course, there’s more to it than that. I’ll explain…

Why Say: Lenovo Recovery UFD Works, But…

The first thing I noticed when the envelope hit the desk was the lack of any Lenovo branding on the drive itself. What I pulled out was an ADATA UVI128 32 GB USB 3.2 Gen 1 flash drive (available for about US$8 online; old enough to be unavailable from big US e-tailers). No ThinkStation logo, nor Lenovo red trade dress. No embossed branding of any kind. For a machine that runs somewhere in the neighborhood of four grand, I appreciate the transparency. It’s just a recovery drive, nothing more.

What’s On That UFD, Anyway?

I plugged it into Flo6  (my main Windows 11 PC here at Chez Tittel) and ran a quick PowerShell inventory. That let me see what I had in hand. These numbers came back: 26.41 GB used on a ~29.3 GB drive, with 2.86 GB free. Every major payload file was timestamped August 3, 2026, which tells me this was a fresh burn, not a dusty warehouse pull. That’s genuinely good to know.

7 Folders With Lots of History

The folder structure is straightforward once you know what you’re looking at. At the root you get seven directories: \boot, \EFI, \mfg, \preboot, \RECOVERY, \SWWORK, and \tvtos.

\boot and \EFI handle dual-mode booting — Legacy BIOS and UEFI respectively, with \boot packing 30-plus MUI language files for good measure. \mfg carries manufacturing metadata and a document called W11_RUSB_TEMPLATE_64_DEV.docx that makes absolutely explicit what this thing is: a Windows 11 recovery set. It’s just manufacturing boilerplate, but as internal tells go, it’s a nice one — you can see exactly which template Lenovo’s recovery build team signed off on. \SWWORK is a staging scratch area, and it’s essentially empty.

The real substance lives in \RECOVERY and \tvtos. The \RECOVERY folder holds the actual image payloads — the largest being LCAFKQ2BA0.IMZ at 957 MB, which is the core Windows 11 OS image, plus fifteen or more companion .IMZ bundles covering P3 Ultra-specific drivers and Lenovo’s software suite. Familiar utilities ride along for the restore process: imagex.exe, bootsect.exe, bcdboot.exe, 7z.exe, and a few Lenovo-proprietary tools including hddcln.exe and rcadm.exe. \tvtos is where the bulk of the 26 GB lives. That’s home to the WinPE-based ThinkVantage OS environment, which is the preboot shell that actually orchestrates the whole restore operation.

Python 2.6 Drives the Lenovo Recovery Engine

Here’s where the archaeology gets interesting. The recovery orchestration engine living in \preboot runs on Python 2.6. Python 2.6 reached end-of-life on October 29, 2013 — nearly thirteen years ago. It has not received a security patch since Barack Obama’s first term. I resisted the urge to feel old about this. Mostly unsuccessfully.

The image format is equally vintage. Those .IMZ files are Lenovo’s proprietary compressed image format. Indeed, there’s no public tooling to mount, extract, or meaningfully modify them. They travel with .CRI catalog companions and are handled entirely by Lenovo’s own restore .exe files. You are explicitly not intended to poke around. You are meant to click Restore and walk away while the progress bar does its thing.

ThinkVantage itself tells a similar story. Lenovo quietly retired the brand years ago, replacing it with Lenovo Vantage on the consumer side and Lenovo Commercial Vantage for enterprise. The preboot environment on this Lenovo factory recovery USB is frozen legacy infrastructure now past its expiration date. It’s functional, tested against this specific hardware configuration, and going absolutely nowhere. It works. It just works using technology that’s old enough to have its own nostalgic Reddit threads.

I Meant What I Said, and I Said What I Meant

All that said: it does the job. Boot it using F12 at the Lenovo splash screen, then select the USB from the boot menu. Bam! The ThinkVantage preboot environment launches and walks you through a factory restore of the P3 Ultra to its original Windows 11 configuration, complete with all Lenovo drivers and software. No internet connection required. MSA prompts, nada. No drama, either. On a machine this complex, that’s pretty cool.

The dual-mode boot support, confirmed by both \boot and \EFI folder trees, means the drive works whether the firmware is set to Legacy or UEFI mode. Coverage is thorough: Windows 11, P3 Ultra-specific drivers, the full Lenovo software bundle. All available on one generic flash drive in one plain envelope.

My verdict: label it clearly, drop it in the P3 Ultra’s machine folder with the rest of the hardware documentation. Then, treat this Lenovo factory recovery USB exactly as the break-glass emergency media it is. I wouldn’t try to explore the ThinkVantage environment for entertainment. Why not? Because it’s a straight-up restore wizard, not a sandbox, and it doesn’t reward curiosity. And don’t get any ideas about cracking open those .IMZ files, either. You’ll need AI or serious programming chops in Python 2.6 to get anywhere.

That’s not my thing. Here in Windows-World, I’m OK with treating a black box as such. Shoot! I’m just surprised it came on a USB-A UFD. After my local success only with the USB-C Data Traveler to bring the P3 Ultra back to life, I’d expected the same kind of UFD to show up from Lenovo. I was wrong…

Facebooklinkedin
Facebooklinkedin

Spiffing Up P3 Ultra WinTerm

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

Understanding Windows Hardware Error Service

This morning, I ran across an item on the TechPowerUp news forum entitled “Microsoft Denies New Tracking Service in Windows 11.” I was intrigued to learn about Whesvc (the corresponding abbrevation and the name of a folder for storing telemetry data beneath C:\Windows\Temp). Its job, says Copilot is to handle “WHEA (Windows Hardware Error Architecture) events [such as] machine check exceptions, PCIe AER, CPU internal errors, bus timeouts,…” and more. The lead-in graphic shows what voidtools Everything found in that folder.

Surprisingly, Whesvc stuff eats nearly 1GB of storage space.

Why Understanding Windows Hardware Error Service Matters

This folder provides a place where WHESVC keeps information about various related events, including when:

  • a hardware error is raised
  • the system is preparing a WHEA telemetry bundle
  • the OS is about to submit a hardware error report
  • a WHEA LiveKernelEvent is generated
  • a PCIe or CPU error needs additional context

Yes, you can indeed report this stuff to Feedback Hub, but I find no documentation to indicate that the OS does this automatically. But it seems like uploads to report stuff would be at least a good idea, if not a given. My best guess it is gets folded into normal Windows telemetry and phone home that way…

PowerShell to the Rescue

Using PowerShell gets you over this particular hurdle. If you want to see what’s in the folder, try this one-liner:

Get-ChildItem -Force -Recurse "C:\Windows\Temp\Whesvc" | Select-Object FullName, Length, LastWriteTime

This produces list of event trace logs (.etl files) you can share with Feedback hub if you’d care to. The following PowerShell will zip it up for you into a file named Whesvc-Diagnostics.zip:


$src = "C:\Windows\Temp\Whesvc"
$dst = "$env:USERPROFILE\Desktop\Whesvc-Diagnostics.zip"
Compress-Archive -Path $src -DestinationPath $dst -Force

I’d be inclined to label the collection as something like “Whesvc output for dd/mm/yy” when you turn it over to MS for inspection. And indeed some of the object names are pretty interesting, as they include strings like “slow app launch,” “long delay,” “app hang,” and so forth. Sounds like potentially useful stuff!

Given that this is transient info, you need not worry about keeping folder contents around. Once you share it with Feedback Hub (or not), it’s safe to delete. As Copilot says “These are scratch files not persistent logs.” ‘Nuff said.

Facebooklinkedin
Facebooklinkedin