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.

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.

I was doing a routine check of my WinGet pin list on Flo6 just now (ICYMI, Flo6 is my production desktop). After running winget pin list I spotted three pinned packages. Two of them I recognized immediately. Adobe Acrobat Reader (64-bit) and GNU Backgammon  I pinned myself, on purpose. But the third one stopped me cold. It showed Microsoft.DirectX at version 9.29.1974.0. I had never pinned that. Why did I see this strange DirectX pin?

How I Got a Strange DirectX Pin on Flo6…

First, let me share some background. Modern DirectX, meaning DirectX 11 and DirectX 12, is baked directly into Windows. Windows Update manages it entirely. Winget does not install, update, or remove it. How, then, did it make its appearance?

The Microsoft.DirectX package from the WinGet community catalog is something else entirely. It refers to the DirectX End-User Runtime redistributable, specifically its June 2010 release. That’s the last one MS ever shipped.

Indeed, Version 9.29.1974.0 is the final, frozen-forever build. It’s unchanged since 2010. Back in the day, games and apps from that era bundled this runtime to pull in legacy components. Think D3DX9, XAudio2, and XInput. On most modern Windows systems, this redistributable is obsolete and irrelevant.

The Source of This Strange Pin May Be…

Here’s where things get weird. The Microsoft.DirectX manifest in the WinGet community catalog had a long-running typo. For a while, it listed the package version as 9.29.1974.1 instead of the correct 9.29.1974.0. A community contributor eventually caught the error and submitted a pull request to fix it.

Once that fix merged into the catalog, WinGet suddenly saw a mismatch on affected machines. The catalog now declared 9.29.1974.0 as current. The installed runtime also reported 9.29.1974.0. So far so good. But the metadata around the install technology did not reconcile cleanly. Windows owns and controls the DirectX runtime. WinGet does not.

Winget could neither upgrade the package nor cleanly resolve the discrepancy. So it did the next best thing. It quietly added a Pinning-type pin to suppress its spurious upgrade prompt. That kept its noise out of winget upgrade --all output. In short, winget added the pin to stop nagging itself about a package it cannot actually manage. I have to laugh about that, give me a moment…

Removing the DirectX Winget Pin Is Safe

The good news here is straightforward. This pin is purely administrative. WinGet created it as a workaround for its own catalog inconsistency. It was never protecting anything vital.

Removing the pin leaves the DirectX runtime alone. The actual runtime stays right where it is. Windows Update continues to manage it, same as always. Better yet, the phantom upgrade version, 9.29.1974.1, is already gone from the WinGet catalog. Removing the pin won’t spur any bogus upgrade attempts. Nothing bad is waiting to happen.

The command to remove it is simple:

winget pin remove --id Microsoft.DirectX --source winget

As you can see in the screenshot above, the operation returns “Pin removed successfully” in under two seconds. A quick follow-up winget pin list confirms the DirectX entry is gone. No drama, no side effects.

Separating Signal from Noise

This episode is a good illustration that WinGet isn’t infallible. Sometimes its catalog or tooling leaves artifacts behind that look alarming but turn out to be harmless. The DirectX pin on Flo6 was exactly that: a breadcrumb left by WinGet’s own error-handling logic, not by anything I did. A single one-liner clears it up in seconds. Now, winget pin list shows only packages I actually chose to pin. That is exactly how it should be, and I am glad to have one less mystery on my machine. That counts as a win, here in Windows-World. Cheers!

Running WinGet just now on my Flo6 desktop, I got reminded that installer changes sometimes stymie its update facilities. If you look at the lead-in graphic, you’ll see that one upgrade gets blocked because of “different install technology.” Winget goes onto recommend “Uninstall each package, then install the newer version.” Not so fast: IMO, an in-app update beats remove/replace when that’s an option. I’ll explain, and use the Edge browser as an illustration.

You can jump to Edge, click the ellipsis, and get to Help and feedback in 3 clicks. Uninstall/reinstall takes 20+ keystrokes, and might fail.

Why Say: In-app Update Beats Remove/Replace?

My explanation boils down to: less time and effort, fewer keystrokes involved. Jumping to Edge, clicking the ellipsis for Settings, then visiting Help and Feedback to prompt the update process takes 3 mouse clicks (add one more click to restart, and the update is done). Uninstalling, then re-installing edge takes at least 20 keystrokes (“winget uninstall edge”). Worse, it then falls victim to exit code 93. TLDR version: Edge is considered a Windows built-in feature, so it blocks its own uninstall by default.

Sure, you can work around this. And it works for other browsers as directed for Chrome, Firefox, and so forth. But my preferred approach for browsers in particular is: try the built-in update mechanism first, if WinGet steers around an update. It usually does so for a good reason, as is the case here with Edge.

Here in Windows-World, it pays to recognize such cul-de-sacs when they pop up. It saves you the time involved in driving to the end, turning around, and doing something else. Not an unfamiliar experience for Windows warriors, but one best avoided when possible!