@SteveL-MSFT @joeyaiello this sounds like it could be a consequence of the missing WinRT libraries (#13042). Will the Appx module maintainers will want to package the WinRT libs with their module? Even if they do, it will mean anyone using newer versions of PS on older Windows versions will be unable to use the AppX module, since that module is shipped with Windows.

@carlocardella can you provide the output from Get-Error after the failed import as well? Thanks! 😊

Here you go:

[92mException             : [0m
    [92mType       : [0mSystem.PlatformNotSupportedException
    [92mTargetSite : [0m
        [92mName          : [0mGetExportedTypes
        [92mDeclaringType : [0mSystem.Reflection.RuntimeAssembly, System.Private.CoreLib, Version=5.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e
        [92mMemberType    : [0mMethod
        [92mModule        : [0mSystem.Private.CoreLib.dll
    [92mStackTrace : [0m
   at System.Reflection.RuntimeAssembly.GetExportedTypes()
   at System.Reflection.Assembly.get_ExportedTypes()
   at System.Management.Automation.Runspaces.PSSnapInHelpers.GetAssemblyTypes(Assembly assembly, String name)
   at System.Management.Automation.Runspaces.PSSnapInHelpers.AnalyzeModuleAssemblyWithReflection(Assembly assembly, String name, PSSnapInInfo psSnapInInfo, PSModuleInfo moduleInfo, String helpFile, Dictionary`2& cmdlets, Dictionary`2& aliases, Dictionary`2& providers)
   at System.Management.Automation.Runspaces.PSSnapInHelpers.AnalyzePSSnapInAssembly(Assembly assembly, String name, PSSnapInInfo psSnapInInfo, PSModuleInfo moduleInfo, Dictionary`2& cmdlets, Dictionary`2& aliases, Dictionary`2& providers, String& helpFile)
   at System.Management.Automation.Runspaces.InitialSessionState.ImportCmdletsFromAssembly(Assembly assembly, PSModuleInfo module)
   at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadBinaryModule(PSModuleInfo parentModule, Boolean trySnapInName, String moduleName, String fileName, Assembly assemblyToLoad, String moduleBase, SessionState ss, ImportModuleOptions options, ManifestProcessingFlags manifestProcessingFlags, String prefix, Boolean loadTypes, Boolean loadFormats, Boolean& found, String shortModuleName, Boolean disableFormatUpdates)
   at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadModuleNamedInManifest(PSModuleInfo parentModule, ModuleSpecification moduleSpecification, String moduleBase, Boolean searchModulePath, String prefix, SessionState ss, ImportModuleOptions options, ManifestProcessingFlags manifestProcessingFlags, Boolean loadTypesFiles, Boolean loadFormatFiles, Object privateData, Boolean& found, String shortModuleName, Nullable`1 manifestLanguageMode)
   at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadModuleManifest(String moduleManifestPath, ExternalScriptInfo manifestScriptInfo, Hashtable data, Hashtable localizedData, ManifestProcessingFlags manifestProcessingFlags, Version minimumVersion, Version maximumVersion, Version requiredVersion, Nullable`1 requiredModuleGuid, ImportModuleOptions& options, Boolean& containedErrors)
   at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadModule(PSModuleInfo parentModule, String fileName, String moduleBase, String prefix, SessionState ss, Object privateData, ImportModuleOptions& options, ManifestProcessingFlags manifestProcessingFlags, Boolean& found, Boolean& moduleFileFound)
   at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadUsingExtensions(PSModuleInfo parentModule, String moduleName, String fileBaseName, String extension, String moduleBase, String prefix, SessionState ss, ImportModuleOptions options, ManifestProcessingFlags manifestProcessingFlags, Boolean& found, Boolean& moduleFileFound)
   at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadUsingModulePath(PSModuleInfo parentModule, Boolean found, IEnumerable`1 modulePath, String name, SessionState ss, ImportModuleOptions options, ManifestProcessingFlags manifestProcessingFlags, PSModuleInfo& module)
   at Microsoft.PowerShell.Commands.ImportModuleCommand.ImportModule_LocallyViaName(ImportModuleOptions importModuleOptions, String name)
   at Microsoft.PowerShell.Commands.ImportModuleCommand.ImportModule_LocallyViaName_WithTelemetry(ImportModuleOptions importModuleOptions, String name)
   at Microsoft.PowerShell.Commands.ImportModuleCommand.ProcessRecord()
   at System.Management.Automation.CommandProcessor.ProcessRecord()
    [92mMessage    : [0mOperation is not supported on this platform. (0x80131539)
    [92mSource     : [0mSystem.Private.CoreLib
    [92mHResult    : [0m-2146233031
[92mCategoryInfo          : [0mNotSpecified: (:) [Import-Module], PlatformNotSupportedException
[92mFullyQualifiedErrorId : [0mSystem.PlatformNotSupportedException,Microsoft.PowerShell.Commands.ImportModuleCommand
[92mInvocationInfo        : [0m
    [92mMyCommand        : [0mImport-Module
    [92mScriptLineNumber : [0m1
    [92mOffsetInLine     : [0m1
    [92mHistoryId        : [0m33
    [92mLine             : [0mipmo Appx
    [92mPositionMessage  : [0mAt line:1 char:1
                       + ipmo Appx
                       + ~~~~~~~~~
    [92mInvocationName   : [0mipmo
    [92mCommandOrigin    : [0mInternal
[92mScriptStackTrace      : [0mat <ScriptBlock>, <No file>: line 1

Hmmmm, this I don't understand, as the compatible libraries should be available on the box. But it's WinRT, not NetFx, so we're probably not looking in the right place for them with our GAC logic. Or maybe the included WinRT libraries in 3.1 were forwarders all along?

@adityapatwardhan can you and I talk about this one offline this week?

@joeyaiello PowerShell is likely still loading everything as it does in 7.0, but the CoreCLR cannot consume Windows Metadata files (WinMDs) anymore.

Quote from dotnet/docs#18875

Old behavior

Consumption of WinMDs by CoreCLR was possible. This permitted activation and consumption of WinRT types.

New behavior

Direct consumption of WinMDs is no longer possible by CoreCLR.

Examples of failures that may now occur:
...
Activation of a WinRT class will result in the following:

Unhandled exception. System.PlatformNotSupportedException: Operation is not supported on this platform. (0x80131539)

@joeyaiello It's throwing in Assembly::FindModuleByTypeRef when resolving an assembly reference with WindowsRuntime in it's assembly flags. Loading the WinRT package won't change that unfortunately. All binary modules that previously utilized WinRT will need to be recompiled to target the new package explicitly. Don't think there's anything PowerShell can do about it.

Edit: Oops GitHub didn't update, @daxian-dbw beat me to it 🙂

But as @SteveL-MSFT noted here (and @iSazonov below that), if the module author can put em back, than so can PS.

My question is whether we need both of those DLLs to get this WinMD support, or if we could ship something lighter that picks up the remaining right stuff off the Windows install.

Also, I'd like to spend a little time understanding .NET's decision a little better. We may be reinventing the wheel here, or they may be a larger reason they pulled support in .NET 5 that we're missing.

I'll try to do a little digging this week

But as @SteveL-MSFT noted here (and @iSazonov below that), if the module author can put em back, than so can PS.

That works because he's referencing the newly defined types from the package. The AppX module directly references WinRT types. This exception is at type load because of how the AssemblyRef is encoded.

My question is whether we need both of those DLLs to get this WinMD support, or if we could ship something lighter that picks up the remaining right stuff off the Windows install.

I'd love to be wrong but I'm pretty sure there's nothing PowerShell can ship to make this work, other than a new version of the AppX module.

The exception is too early in the code path for anything to be injected atm. I don't know if this would work, but it might be worth talking to the dotnet team to see if the exception can be moved to after custom assembly resolve handlers are raised. Maybe if that was done the handler could point the resolution request to the new managed lib. At a glance it looks like the signatures should match.

I'm guessing that would be flimsy at absolute best but maybe that sparks an idea for them.

Nah that's a bust. To test I manually removed the assembly ref flag for WindowsRuntime on the assembly in the GAC (ty dnSpy) and added an assembly resolve handler to point the ref to the new managed lib. It actually works for the most part, but eventually I get a JIT exception because the new managed lib prefixes it's set accessor methods with set_ instead of put_.

Exception             :
    Type       : System.MissingMethodException
    Message    : Method not found: 'Void Windows.Foundation.IAsyncOperationWithProgress`2.put_Completed(Windows.Foundation.AsyncOperationWithProgressCompletedHandler`2<!0,!1>)'.
    TargetSite :
        Name          : RunAppxOperation
        DeclaringType : Microsoft.Windows.Appx.PackageManager.Commands.AppxPackageManager
        MemberType    : Method
        Module        : Microsoft.Windows.Appx.PackageManager.Commands.dll
    StackTrace :
   at Microsoft.Windows.Appx.PackageManager.Commands.AppxPackageManager.RunAppxOperation()
   at Microsoft.Windows.Appx.PackageManager.Commands.AppxPackageManager.SetVolumeState(AppxVolume volume, Boolean setOnline)
   at Microsoft.Windows.Appx.PackageManager.Commands.MountAppxVolumeCommand.ProcessRecord()
   at System.Management.Automation.CommandProcessor.ProcessRecord()
    Source     : Microsoft.Windows.Appx.PackageManager.Commands
    HResult    : -2146233069
CategoryInfo          : NotSpecified: (:) [Mount-AppxVolume], MissingMethodException
FullyQualifiedErrorId : System.MissingMethodException,Microsoft.Windows.Appx.PackageManager.Commands.MountAppxVolumeCommand
InvocationInfo        :
    MyCommand        : Mount-AppxVolume
    ScriptLineNumber : 1
    OffsetInLine     : 22
    HistoryId        : 34
    Line             : Get-AppPackageVolume|Mount-AppxVolume
    PositionMessage  : At line:1 char:22
                       + Get-AppPackageVolume|Mount-AppxVolume
                       +                      ~~~~~~~~~~~~~~~~
    InvocationName   : Mount-AppxVolume
    CommandOrigin    : Internal
ScriptStackTrace      : at <ScriptBlock>, <No file>: line 1

I manually changed the method ref to set_ in the strings heap and now everything appears to be working fine. Maybe the team working on the managed lib could add fake put_ accessors that point to the set_ accessors for compat (hidden with EditorBrowsableState.Never).

It seems .Net team explicitly said that WinRT application should be recompiled in the case. So we need new version of the module.

@iSazonov Yeah that's definitely their current stance. It was pretty easy to coerce it into working though. I think it would be moderately easy for the dotnet team to enable an application to re-add support for these assemblies. They would be able to keep actual support for winrt completely out of dotnet/runtime, but an application like PowerShell could hook it back up potentially seamlessly.

Anyway that's mainly just to give @joeyaiello some ideas if he was still intending to discuss it with them. If not then yeah just ship a new version I suppose.

I have exactly the same problem. 😭

I manually changed the method ref to set_ in the strings heap and now everything appears to be working fine. Maybe the team working on the managed lib could add fake put_ accessors that point to the set_ accessors for compat (hidden with EditorBrowsableState.Never).

can you place a download link of your package so can verify it too?

@salyounis It was just for testing purposes, I would heavily advise against using an assembly whose metadata has been modified manually.

We are still investigating this, but we are open to servicing this if this isn't fixed by 7.1 release.

Per .NET team, if we retarget the Windows release to net50-windows, that would pull in the WinRT assemblies and should work. However, that new TFM isn't available until .NET 5 Preview 8.

@SteveL-MSFT are we 100% sure they mean it'll work without recompiling? It fails at the runtime level, unless they plan on lighting up the assembly resolution logic again, this module will still need to be recompiled.

@SeeminglyScience won't know until we try, the implication is that retargeting to the new TFM will pull in the necessary assemblies to make it work. My suspicion is that a recompilation of Appx module is required, but that will then break running in Windows PowerShell. The other option is to not mark it as Core compatible to have it go through the Windows PowerShell path.

Even now, you can just import-module appx -usewindowspowershell to get it working.

@SeeminglyScience won't know until we try, the implication is that retargeting to the new TFM will pull in the necessary assemblies to make it work.

This may already be understood so I apologize if I'm just reiterating facts y'all already know, but the point where this exception is thrown won't be affected by any additional assemblies. It's hard coded to throw at type ref resolution well before any other code runs. It's more or less the first stop in the code path.

Really I'm just trying to make sure y'all aren't banking on that working, if that's already understood then 👍

My suspicion is that a recompilation of Appx module is required, but that will then break running in Windows PowerShell. The other option is to not mark it as Core compatible to have it go through the Windows PowerShell path.

I did outline another potential path that would allow host processes like PowerShell to map these older assembly references to the new library.

1. Defer the exception in Assembly::FindModuleByTypeRef until after assembly resolve events are raised. If a registered handler finds the assembly then don't throw, if it does then throw the same exception
2. In the new WinRT package add put_ methods that map to the new set_ accessor methods for properties

If those are done then compat can be kept for these modules without compromising their goal of getting the code out of dotnet/runtime.

I just want to make sure all the options are being considered. If y'all don't want to pursue that then 👍

@SeeminglyScience spoke with .NET team and based on your idea, they agreed that to maintain compatibility, they would expose both set_ and put_ accessors for WinRT microsoft/CsWinRT#402. Thanks!

@sccook-intel can you test this on Windows 11 22H2? I'm on the latest Insider Preview but still does not work.

Sorry; I'm on Windows 11 21H2, and don't have a newer version available to me. :-/

I wanna copy over my comment from the other very similar issue #15428 where exactly the same root causes lead the maintainers to say "We dont care, not our problem, ok, closed":

And you know, it doesn't matter if "it works on my machine" kind of crap. It's a MICROSOFT issue. If you're going to close a real issue, you should at least open another issue with the correct group.

This kind of "closed because it's not a problem" is utterly rife with the new Microsoft. What happened? You guys used to be a great company.

@jgwinner (quote)

It's bureaucracy and that the teams within many large companies don't really work together/communicate properly or at all..
Even after more than a year, Microsoft didn't accomplish to let the OS/Appx/whatever other team, make a Microsoft product (that advertises itself as an improvement over the standard version) integrate properly. It's a failure of the chain or maybe the MS devs in github here are low level ones that don't have enough connections within the "real" company and can't break some barriers of team interoperability and cooperation. Of course, in the end, the result being produced is a symptom of lack of quality as a company, but the maintainers of this repo don't care enough and it's convenient to shove any such things with the thought "Not our problem / we dont get paid for this / there is invisible walls within Microsoft we cant break up, neither are we interested in looking at a solution for that"

Originally posted by @FuccDucc in #15428 (comment)

@FuccDucc Absolutely!

Of course, in the end, the result being produced is a symptom of lack of quality as a company,

Yup, this is the problem. Still occasionally great, but just stupid sometimes. This is a failure of leadership at the top.

I fear you're right about GitHub being low level employees who can't get anything done, but hopefully SOMEONE will bubble this up. It's why I try anyway.

Microsoft, you could be better. Please try.

I'm getting this error simply trying to run Get-AppxPackage in PowerShell 7.3.2. I installed PowerShell manually from PowerShell-7.3.2-win-x64.msi.

The status and workaround are unclear to me.

• Is someone going to fix this?
• Is there a workaround that does not involve installing some third-party project off GitHub such as winget-installer?

The last response from Microsoft was:

Long story short, I've been working with the AppX team on this issue. They have been working on a fix which is not a small change. The changes will not be backported to shipped versions of Windows and will show up in a future release of Windows.

The standard work-around is to run the following command before using any cmdlets from the AppX module:

Import-Module -Name Appx -UseWindowsPowerShell

Alternatively, the AppX module is compatible with PowerShell 5.1. You can launch PowerShell 5.1 by specifying its executable name: powershell.exe Remember that PowerShell 6 and later use pwsh.exe as their executable name.

That recent comment about WinGet is not relevant to this issue.

Mike

Alternatively, the AppX module is compatible with PowerShell 5.1. You can launch PowerShell 5.1 by specifying its executable name: powershell.exe Remember that PowerShell 6 and later use pwsh.exe as their executable name.

Yeah, this isn't working for me. Every time I specify powershell.exe, even if I give the full path to it, it still gets redirected to pwsh.exe.

So good to know that MS's stance is "Oopsie, we broke it three years ago. Oh well, get a new operating system." With support like that, my new OS will be Ubuntu.

Long story short, I've been working with the AppX team on this issue. They have been working on a fix which is not a small change. The changes will not be backported to shipped versions of Windows and will show up in a future release of Windows.

@SteveL-MSFT, I want you to know that this type of "support" is exactly why I don't care to purchase from MS anymore. If something was working when the OS was shipped, but was broken later on, you should have the common decency to fix the issue for the customers you already have. Telling them to just go get a new version you do care about is one of the scummiest, greediest things I can imagine. And no, I don't mean you specifically, I mean MS as a whole.

Well this is clear as mud. Closing an issue - that if you are unfortunately using Windows 10, can only be solved by upgrading to Windows 11 or becoming an insider?

Super frustrating problem that still exists, and an even more frustrating Issue conclusion (Use the Feedback Hub.)

It really sucks when we need to report a problem and the only mechanism Microsoft provides is via the Feedback Hub. It's impossible to get any feedback from Microsoft after doing so. It's similarly impossible to know whether others are experiencing the same issue or whether anybody has come up with a workaround. Or whether it is in fact an actual issue to begin with!

Get-AppXPackage: The 'Get-AppXPackage' command was found in the module 'Appx', but the module could not be loaded due to the following error: [Operation is not supported on this platform. (0x80131539)]
For more information, run 'Import-Module Appx'.
PS C:\Windows\System32> Import-Module Appx
Import-Module: Operation is not supported on this platform. (0x80131539)

Still seeing the issue with PowerShell 7.3.5. Solutions in thread to use the command

Import-Module -Name Appx -UseWindowsPowerShell

works but gives the following warning:

PS C:\Windows\System32> Import-Module -Name Appx -UseWindowsPowerShell
WARNING: Module appx is loaded in Windows PowerShell using WinPSCompatSession remoting session; please note that all input and output of commands from this module will be deserialized objects. If you want to load this module into PowerShell please use 'Import-Module -SkipEditionCheck' syntax.

Also seeing 0x80131539 on OS build 19045.3393 with ps 7.3.6. MS documentation points us here for github support so I'm not sure why it would be marked as external?

Hit this today (7.3.6) trying to reinstall a broken Maps app with Get-Appxpackage (0x80131539)

Still the same in 7.3.9

Let me attempt a pragmatic summary, as of late 2023:

The problem:

• The AppX module was PowerShell Core-compatible, but only until v7.0.x.

• The move to .NET 5+ in PowerShell 7.1+ broke this, due to the removal of built-in WinRT support from .NET.

• In PowerShell 7.1+, as of this writing, the only way to use the module is via the Windows PowerShell Compatibility feature, with the performance penalty and the type-fidelity limitations that entails (due to needing to use cross-process serialization via a hidden Windows PowerShell child process).

• A proper fix - necessitating a recompiled AppX module, which ships with Windows - is supposed to be coming, but will not be back-ported, so Windows 10 systems will definitely not see it.

Workarounds:

• On Windows 11 (presumably in all currently deployed versions):

  • Windows 11 ships with an updated AppX module that - as a stopgap - explicitly signals its incompatibility with PowerShell Core, which means that - explicit or implicit import of the AppX module now implies the -UseWindowsPowerShell switch, i.e. automatic use of the module via the Windows PowerShell Compatibility feature, so a workaround may not be needed:

    • You can verify that the presence of this updated module by running Get-Module Appx -ListAvailable -All: the PSEdition column should list Desk only (i.e. compatibility only with Windows PowerShell).

  • However, use of the Windows PowerShell Compatibility feature has side effects that you may want to suppress, but doing so requires an explicit Import-Module call:

    • It displays a progress bar while the transient implicit-remoting module for communicating with the hidden Windows PowerShell child process is being created, when the module is first loaded, possibly implicitly via the module auto-loading feature.

    • When using an explicit Import-Module call, a warning to alert the user to the limitations of Windows PowerShell Compatibility mode is displayed.

    • To suppress the progress bar you need an explicit Import-Module call, which in turn necessitates suppressing the warning:

      • & { $ProgressPreference = 'Ignore'; Import-Module Appx 3>$null }

  • If and when a truly PowerShell Core-compatible update arrives via a future Windows update, existing code (that doesn't explicitly use -UseWindowsPowerShell) will automatically start using the new, natively compatible module.

• On Windows 10:

  • Ad hoc workaround:

    • Import the AppX module explicitly and add -UseWindowsPowerShell.
    • To suppress the side effects discussed above:
      • & { $ProgressPreference = 'Ignore'; Import-Module -UseWindowsPowerShell Appx 3>$null }

  • Persistent workarounds, for a given computer - if upgrading to Windows 11 isn't an option:

    • Note: The following workarounds in effect cause implicit use of the Windows PowerShell Compatibility features, as in Windows 11. Therefore, unless explicit importing is used as shown above, the progress bar will show the first time a command from the AppX module is used in a given session, due to triggering auto-loading.

    • Either: Use $PSDefaultParameterValues to automatically apply -UseWindowsPowerShell dynamically via a script block; if you place the following in a $PROFILE file, it will take effect for all future sessions, but note that profile loading can always be bypassed with -NoProfile:

      $PSDefaultParameterValues['Import-Module:UseWindowsPowerShell'] = { 
        if ((Get-PSCallStack)[1].Position.Text -match '\bAppX') { $true } 
      } 
      

    • Or: Modify "C:\Windows\system32\WindowsPowerShell\v1.0\Modules\Appx\Appx.psd1" to remove 'Core' from the CompatiblePSEditions entry (which mimics the updated version of the module that ships with Windows 11).

      • This not only requires elevation, but requires taking ownership of the file first.
      • Obviously not a great solution, but I think it would work, given that the module doesn't appear to be signed.
      • If subsequent OS updates don't yet include the fixed module, you'll have to do it again.

I just got a newish laptop and installed the new PS on it; while I did not run into the OP's issue as I have before with a new laptop (as noted above) I did get this:

WARNING: Module Appx is loaded in Windows PowerShell using WinPSCompatSession remoting session; please note that all input and output of commands from this module will be deserialized objects. If you want to load this module into PowerShell please use 'Import-Module -SkipEditionCheck' syntax.

Per this: https://learn.microsoft.com/en-us/answers/questions/295167/activedirectory-with-powershell-7-on-windows-serve looks like the built-in PS's prompt to load a new version of PS was, in fact, wrong?

lol. Such a mess.

Ah, that's covered above. I checked and my output was definitely per the above:

PS C:\Windows\System32> Get-Module Appx -ListAvailable -All

    Directory: C:\Windows\system32\WindowsPowerShell\v1.0\Modules

ModuleType Version    PreRelease Name                                PSEdition ExportedCommands
---------- -------    ---------- ----                                --------- ----------------
Manifest   2.0.1.0               Appx                                Desk      {Add-AppxPackage, Get-AppxPackage, Get-…
Script     0.0                   Appx                                Desk      {Get-AppxLastError, Get-AppxLog}

I'm not going to worry with this because the new company is on AWS, not Azure, so I can let sleeping dogs sleep.

ActiveDirectory with Powershell 7 on Windows Server 2016 - Microsoft Q&A

Hello, I get this error when I run Import-Module -Name ActiveDirectory on Powershell 7: WARNING: Module ActiveDirectory is loaded in Windows PowerShell using WinPSCompatSession remoting session; please note that all input and output of commands…

Encountered a similar issue. Strangely, "...AppData\Local\Microsoft\WindowsApps" was not included in the system's PATH variable.

@doctordns please reopen this issue and remove external tag

Just hit this issue trying to install the new Teams client in Windows Server 2019 and found it did not recognise MSIX files at all then I had to install the latest PowerShell then I received the error listed here but the command from @juvtib worked and then I was able to run the install so the order of commands was:

Import-Module -Name Appx -UseWindowsPowerShell
Add-AppPackage -path ".\MSTeams-x64.msix"

However I then received an error saying I needed a Windows Developer Licence or a sideloading policy so I went to Settings > Update & Security > For developers and changed the option to allow sideloading.

After that I repeated the second command above and the appx package was installed.

So I got there in the end but why does everything have to be made so difficult 😅

It would be nice if supported operating systems could be updated, you know as if they were supported!

@robinwilson16 Thanks for updating the procedure. For the record, I did not invent Import-Module -Name Appx -UseWindowsPowerShell--someone else did, and I believe PM Steve Lee endorsed it at some point. My contribution was collecting the steps that worked for me and putting them in one place: as you've done. 😃

I tried all the above fixes, none work. Fairly sure I don't even want or need Appx in Win10? If the canonical fix only works in win11 I am happy to get rid of Appx to get round these issues. Is that a possibility? The forced adoption of this seems to be related to every issue I've had.

BTW: Recent Win10 Update completely screwed my machine with most things reporting similar errors, loads of inaccessible apps or apps reporting missing DLLs. No start menu. One fix did a forced update to PS7 (which broke even more things). Broken WSL2. At one point most apps did not work. Then those that were in the systray during the update. Tried dozens of so called PowerShell fixes, (most of which are like magic spells to me an I'm supposed to know a thing or two about computers..) Of those, most did more damage or nothing at all. The 'update' even removed the vendor supplied system restore partition! Thinking of just giving up and formatting HDD then installing Debian. I only use Windows for some CAD software that does not run on Linux and Wine is getting useful. Is all this an attempt to force the die hard 10 users to 11? My machines have rarely got virus infections but when they have they did less damage. Now, I've fixed most issues (including WSL) but the start menu missing is annoying as I have to go seek the actual .exe to run anything. Would removing appx (as this appears to be a win 11 thing) fix that?

I'm sorry for your troubles.

Based on the symptoms you describe, it sounds like you're having a more serious issue than a simple PowerShell error. And, I suggest looking for advice in a dedicated support forum or in a local repair shop.

Note that AppX is just a file format (like .vhdx or .docx) which you can just ignore. There is nothing to gain by trying to remove support for AppX within Windows.

Regards,