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

Removing Stubborn Acrobat Pin

Leave a comment

I keep learning more and more about hidden wrinkles in WinGet. I guess that’s because I use it every day, and notice when things get hinky. Today, I noticed my pin on Adobe Acrobat got stuck like Schrodinger’s cat: it was there and not-there at the same time. Ultimately, this had me removing stubborn Acrobat pin, as normal methods couldn’t do their job. Let me explain…

What’s Involved When Removing Stubborn Acrobat Pin?

Take a look at the WinTerm screen capture that starts off this blog post. After running winget upgrade ... I got a message “1 package(s) have pins that prevent upgrade.” Flo6 has 2 pins right now and one of them has no internal version number (GNU Backgammon) so I knew the affected package must be Adobe Acrobat. You can see both packages as output to the winget pin list, in fact.

But as you can see in the next two lines, neither winget list --id... nor winget pin remove recognized Adobe.Acrobat.Reader.64-bit as a valid package name. That’s decidedly odd, because that’s the name that shows up in winget pin listoutput shown earlier.

Turns out that’s a thing. It’s a short form versus long, explicit form discrepancy.

Why the Short Form Fails

When you run winget pin remove without explicit flags, winget uses positional argument matching. It tries to match the string Adobe.Acrobat.Reader.64-bit against its installed packages database first. It does not go straight to the pin store.

If WinGet cannot find a recognized installed package entry for that string, it stops. It bails out before it ever reaches the pin database. The pin record sits untouched.

This mismatch happens for a specific reason. Adobe Acrobat was likely removed through Windows Settings or Add/Remove Programs, not through winget uninstall. Winget never got the chance to clean up its own records. So the installed-package record disappeared, but the pin record survived in winget’s separate pinning.db database file.

That gap between the two databases is the root cause of the error. The fix is to route Winget around that gap entirely.

The Fix: Explicit Flags

The solution is to be explicit with WinGet. To do that, add two flags to the command: –id and –source. Together, they change how winget searches. Use this exact command:

winget pin remove --id Adobe.Acrobat.Reader.64-bit --source winget

Here’s how this works: The --id flag forces WinGet to look up the package by its exact manifest identifier. The --source flag tells WinGet to look specifically in the winget source. Together, they bypass the installed-package correlation step and go straight to the pin store.

The output confirms it works. You see “Found Adobe Acrobat Reader (64-bit) [Adobe.Acrobat.Reader.64-bit]” followed immediately by “Pin removed successfully.” Run winget pin list one more time to confirm the pin is gone. It will be.

This is the cleanest way to use winget pin remove whenever a package no longer has a matching installed record. Keep those flags in your back pocket.

Take the Long Way Home

When winget pin remove fails with “No installed package found,” the short form is matching against the wrong database. Adding
--id and --source redirects it straight to the pin store, where it needs to go. Always uninstall packages through WinGet when you can. That keeps its databases in sync and prevents this mismatch from happening in the first place. A little discipline now saves a lot of troubleshooting later, and now you know exactly what to do when things go sideways despite your best efforts. A not unfamiliar sensation to those who, like me, run in the halls of Windows-World.

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

WinGet.Config Drives Developer Config

Leave a comment

As I was reading a Windows Latest article about a “…special Windows 11 for power users…” this morning, I found myself wondering. “Could this be a big, fancy WinGet config file at work?” Indeed, reading further into the story absolutely confirmed my hunch. The file in question, in fact, is named winget.config, in keeping with current naming conventions around desired configuration states. Thus, it’s simple truth that Winget.Config drives “Developer Config” as described in the story (and at MS Learn as well).

WinGet.Config Drives Developer Config from End to End

The MS Learn article‘s intro paragraph is worth quoting in full to put this capability into clear context:

Windows Developer Configurations are a curated, open-source collection of configuration files that take a fresh Windows machine to a ready-to-code state with a single command. Each config is a declarative file that is safe to re-run. It describes the packages, OS settings, and post-install steps for a specific scenario (a full developer workstation, a comfortable WSL shell, or a single language toolchain), so you can rebuild your environment on any machine without clicking through installers or maintaining custom scripts.

Windows Developer Config is built from the ground up on winget configure and a single .winget desired state configuration (DSC) file named dev-config.winget. It is not a new Windows SKU, a custom ISO, nor a registry script. The whole thing is one winget configure call pointing at that file.

The commands necessary to instill this configuration are (mostly) shown in the lead-in graphic. I repeat them here for completeness’ sake (and for easy cut’n’paste, by copying non-comment lines completely):


# Enable WinGet Configuration first
winget configure --enable

# Clone the repo
git clone https://github.com/microsoft/WindowsDeveloperConfig.git
cd WindowsDeveloperConfig

# Apply the config
winget configure -f .\windows-dev-config\dev-config.winget –accept-configuration-agreements –disable-interactivity

More About WinGet.Config

That .winget file is a YAML-based DSC manifest that handles everything in one shot: installing PowerShell 7, Git, GitHub CLI, VS Code, .NET SDK, Python, Node.js, PowerToys, setting up WSL with Ubuntu, tweaking Windows Terminal defaults, enabling Developer Mode and long-path support, and applying a long list of Explorer/Start/Search/Widgets settings to declutter the UI.

Indeed, Project Zenith hardware ships with those same changes baked-in by the OEM. But the underlying mechanism Microsoft used to define and apply that configuration is exactly the same winget configure + .winget file approach. In fact, the .winget config file format is doing real work here. That is, it’s not just installing apps; it’s functioning as full-blown Windows DSC, a notable expansion beyond what most people think winget does.

Here in Windows-World, it’s great to see real innovation put to useful work. Demitrius Nelon, the head of the WinGet team, has told me several times over the past few months that .winget configuration files represent a way to customize Windows seriously in one go. Now, I think I understand what he was getting at. Great work, guys!

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

Long DISM Pause at 63% Range

1 Comment

I’ve been reading online at ElevenForum about people having issues with DISM ... /restorehealth on Build 26100.8972 and 26200.8972. Naturally, I had to check to see if I fell into that same boat. On the plus side, none of my machines at that build level threw an error for the command. On the minus, I observed a long DISM pause at 63% range in completing the sequence that stretched to 70% and a bit more. Copilot tells me this is the stage during which DISM downloads files needed to repair questionable items found in the component store.

Varying Times for Long DISM Pause at 63% Range

The lead-in graphic shows a completion time of 22m 55.301s for the command on my Flo6 desktop (MSI B550 mobo, AMD Ryzen 7 5800X, 64 GB RAM, RTX 3070 Ti). Other intervals I recorded include:

  • 13m 33.008s on AsusSnap (Zenbook A14, SnapDragon X Plus X1P-42-100, 16 GB RAM, Adreno graphics)
  • 8m 36.148s on Lenovo ThinkStation P3 Ultra (Core Ultra 9 285, 64 GB RAM, RTX 4000 SFF)

In this admittedly small sample, I see a strong relationship between CPU speed and completion time. That tells me there’s a lot of thinking going on while the /restorehealth operation is underway. Download volumes were all consistently in the 3-4GB range, as measured by download values from the Network Meter gadget from GadgetPack.

Skip WU, Try ISO

Copilot suggests further that pointing the /restorehealth command at a local ISO could speed things up. But it also says that “the ISO build must match 26200.x [the reference/focus build] closely.” The only way to do that right now is to build an ISO using UUPdump.net to match the 26200.9278 build all 3 PCs are running. That can easily take an hour or longer. My total time for all 3 was under 46 minutes.

Here in Windows-World, if you don’t pay (or spend time) one way, you’ll almost always spend it another. I took the WU route, and was glad all those DISM ... /restorehealth commands completed successfully. That’s good enough for me!

 

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

Examining Nerd Font Glyphs

Leave a comment

Nerd Fonts patch popular programming fonts with thousands of extra icons. These icons live in the Private Use Area (PUA) and other reserved Unicode blocks. Terminals that load Nerd Fonts gain instant access to logos, arrows, file-type icons, weather symbols, and power glyphs. Have you ever wondered exactly which glyphs your installed font contains? The Show-NerdFontGlyphs PowerShell function answers that question fast. It is the key to examining nerd font glyphs, in fact, up close and personal (see lead-in graphic).

Script for Examining Nerd Font Glyphs

The script defines one function: Show-NerdFontGlyphs. It loops through 13 named glyph ranges and renders each glyph alongside its hex code point. It also arranges the output in a configurable column grid. The default is eight columns wide. That width fits comfortably in most terminal windows. Run it, and in seconds you have a full visual catalog of every icon your font supports.

Each section prints a cyan header, making it easy to scan. Each row shows the rendered glyph followed by its four-digit hex address. That pairing is the key feature. Specifically, if you spot an icon you want, note its hex value. Then, reference it in PowerShell with [char]0xXXXX. For code points above U+FFFF, use [System.Char]::ConvertFromUtf32(0xXXXX) instead.

Unicode Ranges Covered

The script covers 13 glyph families. Here’s a quick guide to each one.

  • Pomicons (U+E000 to U+E00A): This set holds 11 miscellaneous icons from legacy Powerline themes.
  • Powerline (U+E0A0 to U+E0B3): These glyphs power the core Powerline separators and branch symbols used in prompt themes worldwide.
  • Powerline Extra (U+E0A3 to U+E0D4, scattered): This range adds rounded, flame, and diagonal separator variants to extend the Powerline set.
  • Symbols (U+E5FA to U+E6B2): These general-purpose glyphs include file-type icons and folder symbols.
  • Devicons (U+E700 to U+E7C5): This section covers programming language and framework logos including Python, JavaScript, Git, and Docker.
  • Font Awesome (U+F000 to U+F2E0): This classic set delivers social, UI, and media icons from Font Awesome 4.
  • Font Awesome Extension (U+E200 to U+E2A9): These icons extend Font Awesome with additional symbols.
  • Octicons (U+F400 to U+F4A8): GitHub Octicons cover pull requests, issues, branches, and repository actions.
  • Font Logos (U+F300 to U+F372): This range holds OS and distribution logos including Linux distros, BSD variants, and Apple.
  • Power Symbols (U+23FB to U+2B58): These glyphs represent standby, power-on, sleep, and toggle functions from the Miscellaneous Technical block.
  • Weather Icons (U+E300 to U+E3EB): This section delivers sun, cloud, rain, snow, wind, and forecast glyphs.
  • Material Design (U+F0000 to U+F0200, first 512 only): These icons come from Supplementary Private Use Area-A and represent a subset of the Material Design set.
  • Codicons (U+EA60 to U+EBEB): Visual Studio Code uses these icons for debugging, source control, and editor UI elements.

Spotlight on U+E62A: Win11 Logo

One glyph deserves special attention: U+E62A. It sits inside the Symbols range (U+E5FA to U+E6B2) and renders as the four-pane Windows 11 logo. Furthermore, it behaves as a double-width glyph. In other words, it occupies two terminal columns rather than one. That property makes it ideal for building large logo art in FastFetch or other terminal info tools.

You reference it in PowerShell with [char]0xE62A. In a Nerd Font terminal, that expression produces the Windows logo glyph directly. Yesterday’s post on this site shows how to build a custom 8×8 FastFetch logo grid in Windows blue using this glyph.

Running the Script

Save the function to showglyphs.ps1. Next, dot-source it in your PowerShell 7 session and call it:

.\showglyphs.ps1
Show-NerdFontGlyphs

You can also adjust -Columns to fit your terminal width. Narrower windows work better with -Columns 4 or -Columns 6. The function handles code points above U+FFFF using [System.Char]::ConvertFromUtf32. As a result, it does not throw errors on supplementary characters.

Download the Script

Download the complete showglyphs.ps1 script directly from this post. Save it to your PowerShell scripts folder and dot-source it in your profile or on demand. Finally, pair it with a Nerd Font in Windows Terminal for the best results. CaskaydiaCove Nerd Font and JetBrainsMono Nerd Font are both excellent choices.

I wouldn’t have found the Win11 logo without this nifty little tool. Try it yourself, and be amazed at all the icon-like images that nerd fonts can offer. They’re amazing!

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

Using WinLogo Glyph in FastFetch

1 Comment

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

WinGet Misses ARM Browser Updates

Leave a comment

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

Version 26H2 Coming Soon Via eKB

Leave a comment

If you’re running Windows 11 24H2 or 25H2, the next annual upgrade aka Windows 11 26H2 is almost here. For many users, the upgrade experience should be pretty low-key. Microsoft pushed Build 26300.9278 into the Release Preview Channel on August 27, 2026. That signals general availability (GA) is on track for September or October. Hence my proclamation about Version 26H2 coming soon via eKB. What’s that?

Qualifying devices won’t sit through a multi-gigabyte download or a lengthy offline install. Instead, they’ll receive a tiny enablement package (eKB) that flips the version number after a single restart.

TLDR: Windows 11 26H2 (Build 26300.9278) is in Release Preview now and coming this fall. It lands as a ~174 KB enablement package (KB5121794) for 24H2 and 25H2 users. Windows 11 23H2 and older face a full ~6.5 GB feature update. Windows 10 users, of course, need a full OS upgrade. And 26H1 (the Arm-only branch) has no standard eKB path to 26H2 at all. For them, a clean install is the only way to go forward.

What Is an Enablement Package?

An enablement package (eKB) works because 24H2, 25H2, and 26H2 share the same underlying servicing branch and codebase. Most of what defines 26H2 has already been delivered to your PC through monthly cumulative updates. Indeed, the eKB simply activates it, changes the build string to the 26300 series, and reboots. The download for KB5121794 weighs in at around 174 KB, and is smaller than most web images. One prerequisite: your system must already have KB5120998 (Builds 26200.9278 or 26100.9278) installed before the enablement package can run. A quick visit to Settings > Windows Update confirms if you’re current (or not).

As Paul Thurrott reported on Thurrott.com, for the first time, Microsoft is releasing a new Windows version to the Insider Release Preview ahead of general availability. That’s a sign that the company wants broader validation before the full rollout. The official announcement comes from Stephen Lines via the Windows Insider Blog.

Upgrade Paths: Know Where You Stand

Your path to 26H2 depends entirely on which version you’re running today. This table lays things out:

Current Version Upgrade Method Download Size Restarts
Windows 11 25H2 Enablement Package (KB5121794) ~174 KB 1
Windows 11 24H2 Enablement Package (KB5121794) ~174 KB 1
Windows 11 23H2 Full feature update (different servicing branch) ~6.5 GB Multiple
Windows 11 26H1 (Arm) Separate core branch — no standard eKB path N/A N/A
Windows 10 Full OS upgrade or clean install ~6.5 GB+ Multiple

As TechPowerUp’s AleksandarK noted, devices on 23H2 and older sit on a different servicing branch. Thus, there’s no eKB shortcut for them. And 26H1, built specifically for new Arm silicon such as Snapdragon X2 Elite devices, runs a separate Windows core and won’t roll forward via the standard enablement path. Microsoft has said those devices will eventually receive a path to a future Windows release. Those who wish to jump that gun must, as I said earlier, do a clean install.

What 26H2 Actually Delivers

Let’s be blunt: 26H2 is a stability and lifecycle-reset release, not a features spectacular. Thanks to Microsoft’s continuous innovation model, most of what carries the 26H2 label has already landed on your device via monthly updates. That said, commercial customers do get a handful of features enabled by default for the first time: Windows Settings Backup, app-specific Taskbar actions, and several File Explorer enhancements.

The bigger prize is the support lifecycle reset. That is, 24H2 Home and Pro reach end of updates on October 13, 2026. Thus, upgrading keeps you beneath the security update umbrella.

How to Get It Now

Windows Insiders in the Release Preview Channel can grab 26H2 today via Settings > Windows Update using the seeker experience (enable “Get the latest updates as soon as they’re available”). For everyone else, wait for GA. At that time, Microsoft will offer 26H2 as an optional install first, then push it automatically as 24H2 nears its support deadline. If you’re still on 23H2 or older, the smartest move right now is upgrading to 24H2 or 25H2, so that when 26H2 arrives, it costs you 174 KB and one reboot instead of a 6.5 GB weekend project.

Here in Windows-World, it’s wise to get ahead of the curve when the opportunity presents. This is one such opportunity. I plan to jump on it as soon as I can!

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, Recent Activity, Secure Boot, Thoughts & concerns, WED Blog, Windows 11, Windows tools

FAT32 UFD Nixes “Repair My PC”

1 Comment

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

Flo6 Recovery Partition Cleanup

Leave a comment

One of the quieter but genuinely useful maintenance tasks for any Windows 11 machine is verifying the WinRE recovery partition. When necessary, you can refresh bits and pieces. On my desktop (production) rig Flo6, that job came due recently when I discovered a one-version gap between the OS and the recovery environment. Here’s exactly what I did to perform Flo6 recovery partition cleanup.

Why Do Flo6 Recovery Partition Cleanup?

Flo6 was running Windows 11 25H2 (build 26200.9168). It’s current and fully patched. A quick reagentc /info at an elevated command prompt, however, told a different story about the recovery environment: Windows RE Version 10.0.26100.9168. That’s 24H2 — one full major version behind the OS.

This kind of mismatch is typical after an in-place upgrade. Windows Update doesn’t always push a matching WinRE update alongside the OS upgrade. The recovery environment still works, but keeping it in sync with the running OS is simply good hygiene.

Finding the Right Source Media

Fortunately, I had a Windows 11 25H2 bootable UFD on hand. It is ESD-USB labeled, FAT32 formatted, carries seven editions in a split WIM (install.swm + install2.swm, totaling ~5.6 GB compressed). A quick DISM query confirmed the match:

dism /get-wiminfo /wimfile:G:\sources\install.swm /index:6

Output showed Version: 10.0.26200 / ServicePack Build: 9168 — an exact build-for-build match with Flo6’s OS. The source media was confirmed.

DISM Workflow: Four Clean Steps

Split WIMs add a wrinkle:the/swmfile parameter won’t work with /mount-wim. The workaround is to export first, then mount the resulting single WIM. Here’s the sequence I ran from an elevated command prompt:

Step 1 — Export the Pro edition to a single WIM:

dism /export-image /sourceimagefile:G:\sources\install.swm /swmfile:”G:\sources\install*.swm” /sourceindex:6 /destinationimagefile:C:\temp_pro.wim

Step 2 — Mount read-only to C:\BootMount (a pre-existing empty directory):

dism /mount-wim /wimfile:C:\temp_pro.wim /index:1 /mountdir:C:\BootMount /readonly

Step 3 — Extract winre.wim to a temp location:

copy C:\BootMount\Windows\System32\Recovery\Winre.wim D:\Temp\Winre25H2.wim

Step 4 — Unmount and delete the temp WIM:

dism /unmount-wim /mountdir:C:\BootMount /discard
del C:\temp_pro.wim

Swapping the WinRE Recovery Partition Image

With the new Winre.wim extracted, swapping it into the recovery partition takes just a few commands using reagentc (note: the copy command runs into a second line here, but should be a one-liner when run at the command line):

reagentc /disable
copy /y d:\temp\winre25h2.wim r:\recovery\windowsre\winre.wim
reagentc /enable
reagentc /info

The leading screenshot above shows this exact sequence — disable, copy, enable, and the final /info verification — all completing successfully. Note that R:is the recovery partition, temporarily assigned a drive letter for this operation.

A Nuance Worth Noting

The final reagentc /info reported Windows RE Version: 10.0.26100.9168 , and still shows 24H2. This isn’t a failure. The winre.wim packaged inside a 25H2 OS install image is itself built on the 24H2 WinPE base.

Microsoft maintains WinRE on its own separate servicing track. The embedded winre.wim version doesn’t automatically match the OS build number. The WinRE is fully functional and properly enabled — the version stamp reflects WinPE infrastructure, not a gap in recovery coverage.

Bottom Line

The Flo6 WinRE recovery partition is now refreshed, re-enabled, and confirmed healthy: Status Enabled, location correct, BCD identifier registered, and local reinstall available. Total active time at the command prompt: under ten minutes.

If you haven’t checked your own WinRE status lately, reagentc /info is a fast, zero-risk first step — and now you know exactly what to do if the version number looks off. Here in Windows-World, checking is good, and verifying is better. Today, I’m in a good place. How about you?

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

Windows Neofetch Alternatives

Leave a comment

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

Author, Editor, Expert Witness