Category Archives: Cool Tools

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

MediaMonkey Version Info Fools WinGet

Leave a comment

MediaMonkey recently taught me another lesson about package managers: version information has to agree at both ends. Otherwise, automation can outstrip itself. Indeed, I’ve just witnessed how truncated MediaMonkey version info fools winget into a looping update.

I had already run a broad WinGet update using winget upgrade –all –include-unknown. MediaMonkey was included and its update completed successfully. Later, though, WinGet proffered MediaMonkey again. That follow-on install also completed successfully, leaving me wondering why an already updated application looked stale.

How Truncated MediaMonkey Version Info Fools WinGet

The lead-in screenshot makes a mismatch plain. WinGet identifies the package as VentisMedia.MediaMonkey.2024. Its list output reports the installed Version as “2024,” but Available is “2024.2.2.3222.” From WinGet’s perspective, those strings do not match.

A PowerShell registry query settles the question from the installed-software side. MediaMonkey 2024 records DisplayVersion simply as “2024.” The same entry identifies Ventis Media Inc. as Publisher and points to the 32-bit Program Files installation location.

Get-ItemProperty `
HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*,
HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*, `
HKCU:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* `
-ErrorAction SilentlyContinue | `
Where-Object DisplayName -Like '*MediaMonkey*' | `
Select-Object DisplayName, DisplayVersion, Publisher, InstallLocation, PSPath

That is the crux of the problem. The installed application advertises “2024.” The WinGet package advertises “2024.2.2.3222.” Thus, WinGet continues to find the need to upgrade even after installing the latest package.

A Blocking Pin Breaks the Loop

Rather than let routine upgrade runs keep revisiting MediaMonkey, I added a blocking pin against the package ID:

winget pin add --id VentisMedia.MediaMonkey.2024 --blocking

The next winget pin list confirms the result. MediaMonkey 2024 appears with version 2024, source winget, and pin type Blocking.

That choice is deliberately stronger than an ordinary pin. Microsoft documents a blocking pin as preventing upgrades through both “winget upgrade –all” and a direct package upgrade. The package must be unpinned before a normal WinGet upgrade can proceed, although the force option can override this specific pin behavior.

Watch, Wait, Then Unpin When It’s Time

For now, blocking is exactly what I want. The installed MediaMonkey is current based on the package I just installed, while its reported version remains too broad and unspecific for WinGet to compare cleanly.

The next move is patience. I will periodically check MediaMonkey and the WinGet package metadata. When a genuine new release appears, I can remove the block, run the upgrade, and see whether the installed DisplayVersion finally reports a fully qualified build number.

If that happens, WinGet should again have comparable version strings to work with. If not, the blocking pin can go right back on.

Version Metadata Makes the Difference

Yesterday’s episode is a useful reminder that WinGet can only act on available version information. A successful install does not guarantee the application and package catalog describe the result identically.

Here, two command-line checks tell the whole story. First, winget list exposes the disagreement. Second, PowerShell confirms what Windows knows about MediaMonkey. Until those values line up, a blocking pin turns an annoying repeat upgrade into a controlled watch-and-wait problem. Case closed, at least for now. Here in Windows-World it’s been added to the list of things I must watch and remember. It’s a big and pretty active one, as Windows pros already know…

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

F10 Toggles A14 Camera

2 Comments

At some point in the recent past, I must’ve struck the F10 key on my Asus Zenbook A14. How do I know that? Because the Fn keys on the top row of that laptop serve dual purposes. As I’ve now learned, F10 toggles the A14 camera on and off. That explains why Windows Hello facial recognition quit working on that PC: I had turned off the camera!

If you look at the camera symbol in Windows Hello setup (lead-in graphic), the left-to-right slash means “no camera!” Indeed, seeing that symbol sent me down the “turn it back on” path.

Tiny Orange LED sez: F10 Toggles A14 Camera

Now that I know what to look for, I also see a teeny-tiny orange LED at the left of the half-height F10 key. In fact, the glowing LED tells me that the camera is inactive. Good to know.

Better still, once I turn the camera back on, the machine amazes me with how quickly Windows Hello recognizes me and logs me in when I sit down in front of it.

To steer clear of other potholes, I had Copilot build me a table of Fn/hotkeys for my further education and enlightenment. So, here goes:

ASUS Zenbook A14 UX3407QA function keys

Key Secondary function
F1 Speaker mute/unmute
F2 Volume down
F3 Volume up
F4 Display brightness down
F5 Display brightness up
F6 Touchpad on/off
F7 Keyboard backlight brightness
F8 Display/output mode
F9 Microphone mute/unmute
F10 Camera on/off
F11 Screen capture / Snipping Tool
F12 MyASUS

Here in Windows-World, it pays to know and use the controls for one’s hardware. Admittedly, I’ve been remiss in not learning these controls sooner. However, now I know, and I consider myself better qualified to drive this thing.

Of course, let’s see what kind of upcoming accident propels my understanding further. After all, that’s often how I learn things best: try it and see what happens! Or, sometimes, try it by accident and learn what I just did.

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

Production Switchover Produces Unexpected Speed-up

2 Comments

Over the past week, I’ve switched two older PCs from Insider Preview to Production builds. For the record, the X380 is a 2018 vintage Lenovo ThinkPad X380 Yoga, while the X12 is a 2021 vintage Lenovo ThinkPad X12 Convertible Tablet Gen 1. Happily, this production switchover produces unexpected speed-up for both machines across the board. Let me tell  you more…

Why Production Switchover Produces Unexpected Speed-up

MS has been on a bit of a tear lately, trying to repair its user credibility and brand image for Windows 11. Industry observers have noticed and published stories like these:

My usual response to such coverage is “Yeah, right, sure…” (delivered with an eye roll and a skeptical tone of voice). But this time, it’s possible that the coverage is both apt and accurate.

What Improvements Might One Find in 26H2?

After the switchover from Beta (X380) and Insider Preview (X12) builds on those PCs to mainline 26H2 (Build 26300.9711 as I write this). I’ve noticed snappier response and quicker completions across the board on both machines. Some of this, says Copilot (and I agree) is simply a natural outcome of switching from a more heavily instrumented and closely monitored Insider release to a more streamlined and less tarted-up production release.

But there’s more. I am seeing noticeably faster performance on both PCs including:

  • Improved system responsiveness
  • Faster app launch times
  • Faster File Explorer
  • Lower RAM usage
  • Reduced latency in UI interactions

Case in point: I just ran winget upgrade -all --include-unknown on both PCs and they ran updates on CrystalDiskInfo, WinScript, CoreTemp and (as shown) MS.Gameinput. All did their work — checking the manifest, showing the update list, then performing the individual updates — enough faster than their previous usual that I noticed an improvement.

Same thing goes for app launches, installs and uninstalls outside of WinTerm. As old as these two machines are, I feel like they’ve gained a new lease on life. Here in Windows-World, that’s a win! Maybe I didn’t shoot myself quite as badly in the foot with the “Let’s try Installation Assistant and see what happens” experiment on these PCs as I had originally feared. Woo-hoo!

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

PowerToys Gets Double Upgrade

Leave a comment

Here’s something I’ve not seen  before. As is my usual practice, I ran winget upgrade --all --include-unknown this morning. Upon returning to WinTerm after it was done I noticed something odd. The version number in the release notes for PowerToy (open automatically after any release) was higher than the target version in the Winget uprade info. Upon closer examination, I determined this is a case where PowerToys gets “double upgrade”. Let me explain…

How PowerToys Gets Double Upgrade

Indeed, winget took PowerToys to the targeted version (0.102.2862.0). But in the meantime, the PowerToys (PT) team released a higher-numbered version (0.102.2883.0). And because I have PT configured to auto-update upon launch, once the winget driven update finished, the program itself took care of the second one on its own.

For a split second, I wondered about possible pixies — or gremlins, maybe. Then  I realized it’s all baked into the way the app itself behaves. Here in Windows-World what looks like a mystery can just be the way things look odd sometimes, even as they do what they’re supposed to.

That’s what passes for entertainment these days here at Chez Tittel. And I admit, I’m both entertained and bemused.

Edge Rears Its Install Technology Head

Speed reader that I am I also initially conflated the message from Edge — entirely in character and seen many times before, BTW — with what PowerToys was doing. Not so. I just had to run the updater inside Edge itself and this momentary hiccup also cleared.

Keeping things updated is as much about remembering edge cases and exceptions as it is about following the channel in the river of new packages continuously showing up via winget. I do have to remind myself about that occasionally. But again: it’s all in good fun here in Windows-World.

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

UniGetUI Handles Discord Updates

Leave a comment

In my September 16 post, “WinGet Mistakenly Reports Discord as Pinned,” I covered a quirk in how winget labels certain packages. I was reminded of same, as I observed that UniGetUI hanldes Discord updates easily and directly. If winget marks Discord as pinned and skips it, how can UniGetUI update it anyway? Let me ‘splain it to you.

How UniGetUI Handles Discord Update, While WinGet Fails

It is a handling difference that distinguishes the two package managers. Actually, WinGet itself stumbles only when using update --all. WinGet actually CAN handle a Discord update but it has to be commanded correctly and directly. UniGetUI uses WinGet to get (at least some of) its work done (also works with Chocolatey, Scoop, etc.). The trick turns out to hinge on how WinGet is told to upgrade Discord. The blanket approach just described fails because of a manifest flag (see 9/16 post for deets). Winget simply skips over that upgrade.

UniGetUI does things differently. Under the hood, it calls winget using an explicit package ID for each app that needs an update. For Discord it works just as if it had entered

winget upgrade --id Discord.Discord --include-pinned

at a command line (cmd.exe or PowerShell). In fact, WinGet will update Discord if you use similar syntax, to wit:

winget upgrade --id Discord.Discord --force

Manual Override Is a One-Off Avventura

Please note: the preceding command string is a one-time override. The RequireExplicitUpgrade: true flag that causes WinGet to skip over Discord for WinGet upgrade --all stays in place. Future winget upgrade –all runs will still skip Discord, so you would need to repeat the command each time you wanted to force that update manually.

UniGetUI’s approach turns this winget blind spot into a non-issue for anyone who prefers a GUI workflow. I’m actually coming to like this program more and more because of its consistent, user-friendly package handling. But WinGet remains number one in my heart because it’s command-line native, and readily susceptible to scripting and automation.

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

Powershell Update Goes Sideways

Leave a comment

Interesting doings in the Windows Terminal PowerShell world. Running WinGet in that environment just now, I updated PS. Not only did that activity produce an “Installation abandoned” error msg, it initially threw up cmd prompt instead of PS when I clicked the plus sign to launch a new WinTerm session. Alas, it looks like this PowerShell update goes sideways (and more so on some PCs).

Ways PowerShell Update Goes Sideways

First, let’s survey the landscape. Windows PowerShell 5.1 is built into Windows and goes nowhere. It is a system component, not something you update through a package manager. PowerShell 7.x is a completely separate, side-by-side install. It lives in its own directory and uses its own executable, pwsh.exe.

The standard command for updating PowerShell 7.x is clean and simple. You open a terminal and run winget upgrade --id Microsoft.PowerShell. However, what looks simple on the surface can hide a lot of failure modes underneath.

Updates can stall mid-stream, roll back without a clear explanation, or appear to succeed while doing nothing at all. That last scenario is especially maddening. You see a success message, then run pwsh --version and get the old build number staring back at you. Something broke during the install, and winget did not catch it.

Oh No! Installation Abandoned…

I’ve seen this error message (see lead-in graphic) before. Normally, that means the PS installer has lost its connection to Winget via PowerShell and WinTerm. You can often see the PS installer window open, still running, and finishing its work. Closing, then re-opening WinTerm usually sets things back to rights.

Not this morning, on my Flo6 desktop (B550 mobo with AMD Ryzen 7 5800X CPU). After the upgrade, a new PS session launched cmd prompt instead. WinTerm lost its path to the pwsh.exe executable. When I went to look at its profile, it showed as empty. So I had to delete it, and recreate it, then point to the PowerShell 7 icon. That fixed things right up.

That Worst Case Isn’t Ubiquitous

When I updated PS on the Lenovo ThinkPad P16 Gen 1 mobile workstation, I got the same “installation abandoned” error message. But when I opened a new PS session (using the menu bar “+” control) the new version popped right up in a proper PowerShell pane.

I’m not sure why some machines act out more than others when the PS install goes sideways. Shoot! It could have been cosmic rays. But whatever happens, you can fix it if you check the profile and make sure it’s properly defined. Here in Windows-World knowing what to fix and how to fix it goes a long, long way. This morning, it went far enough to set things back up properly on Flo6. May it do the same for you, should you need it to!

One More Thing…

Just ran the same update on the ASUS Zenbook A14 (Snapdragon X ARM CPU). Completed successfully! I’m starting to think that platform diffs may play into this situation. The AMD platform failed and carried a persistent error state. The Intel platform failed, but recovered. And the ARM platform sailed right thru. Go figure!

 

Facebooklinkedin
Facebooklinkedin
Cool Tools, Insider stuff, Updates, WED Blog

Another OOO, Another Catchup

2 Comments

OK then, I’ve been away from home since October 1. Sorry to report it was to attend a memorial service for my brother-in-law, Mike Carey, who succumbed to lung cancer on September 19. Now that I’m back in the saddle, my first task was to check and apply all outstanding updates to the Windows fleet here at Chez Tittel. That sort of make my marching orders read “Another OOO, another catchup.” Let me tell you what that meant this morning…

Working Through Another OOO, Another Catchup

There are 8 PCs in the fleet at present. Two AMD, one Snapdragon X, the rest Intel. I ran through the gamut of update checks on each one and did the necessary.

Name WinGet DSA PMP Other Total
X12 5 3 2 0 10
P16 2 0 1 0 3
X380 9 0 1 1 11
Flo6 4 0 1 2 7
P3Ultra 4 1 3 0 8
AsusA14 5 0 1 0 6
Ryzen 11 0 1 1 13
D7080 3 0 3 3 9
Totals 43 4 13 7 67

In the column heads PMP = Patch My PC Home Updater and DSA = Intel Driver & Support Assistant. As you can see, I had a decent number of updates to handle (67 for 8 machines averages between 8.0 and 8.5). Under “Other,” I accessed Lenovo Vantage, Dell Command Update and the ASUS update facility, on related systems. And both of my NVIDIA-equipped PCs (RyzenOfc and Flo6) got GPU updates. But it’s all taken care of now.

Now What’s Next?

I keep up with WinGet on a more or less daily basis. The other stuff falls into the “as I read about it in the news” or “once a week” category. So I should be good until next week for now.

It’s good to be back. I look forward to catching up and commenting on recent Windows news, updates and introductions. Stay tuned, and I’ll tell you more.

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

Fixing Macrium Rescue Disk

4 Comments

Microsoft updated its Secure Boot revocation database (DBX) in mid-2026. That update requires Boot Manager binaries to carry a minimum Security Version Number (SVN) of 11.0. It also bans the older “Production PCA 2011” signing certificate. Rescue media that Macrium Reflect X builds fails both tests out of the box. That means with Secure Boot enabled, the Reflect’s boot media won’t work. That’s why I’m writing today about what’s involved in fixing Macrium Rescue Disk.

Most important, this post walks you through a PowerShell script named fixmrrd.ps1 that fixes all three BANNED files in a single pass. Buckle up! There’s LOTS of ground to cover…

Why Fixing Macrium Rescue Disk Is Necessary

Macrium Reflect X builds its WinPE rescue environment from the Windows ADK (Assessment and Deployment Kit). The ADK ships once per Windows release and never gets Patch Tuesday updates. Its boot files stay frozen at the SVN level they carried on release day.

For Windows 11 24H2, the WADK 11 ADK shipped with boot files at SVN 2.0. The current DBX floor is SVN 11.0. That nine-version gap is the core problem that requires fixing.

The standard boot manager file, aka bootmgfw.efi that lives under C:\Windows\Boot\EFI\ also carries the banned Production PCA 2011 certificate. Even when the SVN is correct, that certificate triggers a hard BANNED result. Garlin’s check_bootMedia.ps1 diagnostic tool makes both problems visible immediately.

Introducing fixmrrdv2.ps1

fixmrrdv2.ps1 bridges the gap Macrium leaves open. It pulls every replacement file from your live, fully patched Windows 11 installation. Those files already meet the SVN 11.0 requirement and carry the correct Windows UEFI CA 2023 certificate. It’s a v2 version because @Monica1491 over at ElevenForums pointed out an error that I fixed.

Here is what the script does at each step:

  1. Validates the target USB drive and confirms it carries a MACRIUM label.
  2. Locates boot.wim on the rescue media, typically at sources\boot.wim.
  3. Identifies three source files from your live Windows installation: bootmgfw.efi, bootmgfw_EX.efi, and winload.efi. It reports the version number of each file.
  4. Replaces the external bootmgfw.efi on the USB EFI partition. It uses the EX variant (bootmgfw_EX.efi) as the source — not the standard bootmgfw.efi. The standard file carries the banned Production PCA 2011 certificate. The EX variant carries the required Windows UEFI CA 2023 certificate.
  5. Mounts boot.wim using DISM. Then it adjusts ACLs on the internal target files. WIM images lock their contents with restrictive ACLs. Even Administrator hits an access-denied error without a takeown and icacls step first.
  6. Replaces bootmgfw_EX.efi and winload.efi inside the mounted WIM.
  7. Commits the changes and unmounts the WIM. If any step fails, DISM discards the mount and leaves the original WIM intact.

The script backs up every replaced file with a timestamped .bak_ suffix before touching it. Color-coded [OK], [!!], and [FAIL] status lines show progress at each step.

Before You Run the Script…

There are four prerequisites apply before you run fixmrrdv2.ps1.

  • Run as Administrator. DISM mount operations require elevation.
  • Use Windows PowerShell 5.1 (powershell.exe). Do NOT use PowerShell 7.x (pwsh.exe). The DISM /Mount-Image command does not work correctly under PowerShell Core. The script detects PS 7.x automatically and exits with a clear message if you start it from the wrong shell.
  • Your Macrium rescue USB must be plugged in and assigned a drive letter. Note that letter before you start.
  • Your execution policy must allow local scripts. Run this in an elevated PS 5.1 window if needed:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Download fixmrrdv2.txt from its OneDrive link (read only). Rename it to fixmrrd.ps1. Place it in a convenient location, such as C:\tools\scripts\.

Running the Script…

Open an elevated Windows PowerShell 5.1 window. Navigate to the folder holding fixmrrd.ps1. Then run:

.\fixmrrd.ps1 -TargetDrive G:

Substitute your actual rescue drive letter for G:. If you omit -TargetDrive, the script prompts you for it.

The script runs without further interaction. The DISM commit step takes the longest — typically 30 to 60 seconds. Do not interrupt that step.

Each replaced file gets a timestamped .bak_ backup before the script writes anything new. You can restore any original file by renaming the matching backup.

One timing note: the script reports source file versions from C:\Windows\Boot\EFI\ and C:\Windows\Boot\EFI_EX\. You may notice the version number on the USB after copy differs slightly from what the script reported. This is a FAT32 metadata quirk. The SVN level is what really matters, and transfers correctly.

Verifying Results

Run Garlin’s check_bootMedia.ps1 against the drive when the script finishes:

.\check_bootMedia.ps1 G: -audit -verbose

A correctly fixed drive shows all three boot files as ALLOWED:

USB Drive g: "MACRIUM_PE"
    Windows Boot Manager [Windows UEFI CA 2023] is ALLOWED.
        g:\EFI\Microsoft\Boot\bootmgfw.efi
        File Version: 28000.367, SVN 11.0

    boot.wim:1 (WinPE 26100.1)
        Boot Manager [Windows UEFI CA 2023] is ALLOWED.
            \Windows\Boot\EFI_EX\bootmgfw_EX.efi
            File version: 28000.367, SVN 11.0

    \Windows\System32\winload.efi is ALLOWED.
        File version: 26100.9444

If any file still shows BANNED, check that you ran the script in PowerShell 5.1 with elevation. Re-run if needed — the backup files let you roll back safely.

The Net-Net: Working Rescue Disk

This is a product gap in Macrium Reflect X, not a user error. Macrium builds from ADK components that Microsoft does not update through Patch Tuesday. The recoverydrive.exe tool that ships with Windows sources its boot files directly from the live OS. Macrium does not. Until Macrium ships a fix that closes that gap, fixmrrd.ps1 fills it. It ticks me off, and that’s why I decided to script my way around it.

Keep this script on hand. The next time you rebuild a Macrium rescue drive, perhaps after a major Windows update or a new ADK release, you will need it again. The whole process takes under two minutes once you know the steps. Here in Windows-World, when vendors don’t fix their stuff, we users must sometimes step in to help out. Cheers!


Facebooklinkedin
Facebooklinkedin	

	
	




	
	

			
	

				

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

			
WinGet Mistakenly Reports Discord as Pinned

		

			 			Leave a comment
						

	


		

		
Here’s a scenario many Windows users will recognize. You open a terminal and run winget upgrade to freshen up your apps. Everything looks normal — until you spot Discord sitting there labeled “pinned.” You never pinned it. You have no idea why it shows up that way. Sound familiar? Turns out that WinGet mistakenly reports Discord as Pinned for its own, somewhat murky reasons.


This WinGet Discord pinned situation surprises a lot of people. It looks wrong, or like WinGet won’t update a much-used app. Neither is true.


Take a breath. Discord is fine. WinGet is fine. There’s a perfectly logical explanation — and once you see it, the whole thing makes complete sense. Let me fill  you in…


Why WinGet Mistakenly Reports Discord as Pinned


WinGet uses the “pinned” label for two very different situations, and it doesn’t distinguish between them visually. The first situation is one you control: you run winget pin on a package, and WinGet holds that app at its current version. That’s an intentional, user-driven pin.


The second situation involves the app’s own manifest. Package maintainers can set a field called RequireExplicitUpgrade to true inside their installer’s YAML file. When WinGet sees that flag, it skips the package during bulk upgrade runs. Then, it labels it as “pinned” in the output.


Discord’s manifest resides in the winget-pkgs repository. ICYDK, that’s the Microsoft community Windows Package Manager manifest repository on GitHub. There, its manifest carries RequireExplicitUpgrade: true across many versions, including 1.0.9005, 1.0.9166, and 1.0.9188. WinGet groups both user-set pins and manifest-driven flags under the same display label. That shared label is the root of all this kerfluffle.


Why Discord Sets RequireExplicitUpgrade


Discord ships with its own built-in auto-updater. Most of the time, Discord updates itself quietly in the background without you lifting a finger. It doesn’t need WinGet’s help to stay current. It runs by default each time you open the app (or restart your PC).


Setting RequireExplicitUpgrade: true in the manifest tells WinGet to stand down during bulk winget upgrade runs. This prevents WinGet from downloading and launching a full installer that could interfere with Discord’s own update mechanism. Two updaters competing for the same app can be a recipe for trouble.


This is actually a smart, deliberate design choice. Thus, it’s not a bug, nor an oversight. The Discord team and the winget-pkgs maintainers made a deliberate call to keep things tidy. WinGet and Discord each do their own job, without stepping on each other.


How to Check the Discord Manifest


Want to see Discord’s package details for yourself? Start with this command:


winget show --id Discord.Discord


This output gives you useful metadata — the current version, publisher, installer URL, SHA256 hash, and release date. What it does not show is the RequireExplicitUpgrade field. winget show surfaces display metadata, not every field in its YAML manifest.


The file Discord.Discord.installer.yaml does not exist on your local PC. It lives only on GitHub. To find it, go directly to this URL in your browser. (Swap in whatever the current version number is for 1.0.9258 if needed.) Once there, look for RequireExplicitUpgrade: true in the YAML. That single line is what tells WinGet to treat Discord as a skip-by-default package during bulk upgrades. You can see it highlighted in the lead-in graphic at line 16 of that YAML file, in fact.


Upgrading Discord Through WinGet Anyway


Maybe you want WinGet to handle the Discord update on your terms. No problem. You can override the RequireExplicitUpgrade flag with a single targeted command:


winget upgrade --id Discord.Discord --force


This tells WinGet to update Discord explicitly, bypassing the manifest flag just for this one run. It’s a clean, safe way to push a WinGet-managed update when you want one.


That said, most of the time you won’t need to bother. Discord’s own updater does its job reliably and quietly. The WinGet Discord pinned label looks alarming, but your Discord client is almost certainly already up to date. Check the app’s version in its settings if you want confirmation.


WinGet Category Conflation Explains All


The “pinned” label WinGet shows for Discord is not a real user-set pin. Again, you did nothing wrong, and nothing is broken. It reflects the RequireExplicitUpgrade: true field baked into Discord’s own manifest That tells WinGet to step aside and let Discord’s built-in updater do its thing. Once you understand the distinction, WinGet’s behavior makes perfect sense. This behavior is simply misreported as “pinned” not “RequireExplicitUpgrade.”


Now that you know what’s going on, you can look at that “pinned” label and nod knowingly instead of scratching your head. That’s what understanding tools is all about. That makes you a sharper and better-informed inhabitant, here in Windows-World.

Facebooklinkedin
Facebooklinkedin