Completely uninstall provisioned apps: how-to and detailed explanation

*** SECTION ONE ***
*** Introduction ***
In this post I will explain how to completely remove a Metro-style app (or Modern app or Windows app) from a Windows 10 machine. All tests have been performed on 64-bit Windows Home build 10.0.19041.508 (semi-annual channel). I can't guarantee that Microsoft will not change things with the next feature updates.
I will NOT talk about traditional desktop programs, NOR will I worry about removing a Metro-style app for a single user. These two tasks can be easily performed through the Windows GUI (Graphic User Interface) and they are widely documented on the web - see for instance Brink's tutorial "How to Uninstall Desktop Apps and Windows Apps in Windows 10":
Uninstall Apps in Windows 10
Option 6 and 7 in that tutorial are intended to completely uninstall specific apps from the computer, which is the topic I want to cover, but those commands are wrong and they don't actually do the job.
Before getting started, make sure you understand the different apps included in Windows 10. Please, do follow the link and read the article carefully, especially if you're not familiar with the topic:
https://docs.microsoft.com/en-us/win...-in-windows-10
Also, it is important to point out that different apps may require different uninstall procedures. Many apps can be completely removed simply through the Windows GUI, either from the Start menu or from the Settings app - these are the easy ones.
System apps, on the other hand, cannot be removed at all as they are integral to the operative system. There are tutorials around the web showing how to delete them, but I would not advise trying to do so as forcefully deleting system apps is very likely to break things.
In the following I will focus on provisioned apps, which somehow lie in between the two previously mentioned categories. If you're not sure about the meaning of "provisioned apps", the Microsoft link above will help. These apps CAN be completely removed, but the uninstall procedure is often tricky and it can only be completed through CLI (Command Line Interface). Just remember that there is one such app that shall not be removed because it can't be easily re-installed: that is of course the Microsost Store.





*** SECTION TWO ***
*** Brink's suggestion ***
I will take, just as an example, Xbox Console Companion. Brink suggests to open Powershell with admin rights and issue the command:

Code:

Get-appxpackage -allusers *Microsoft.XboxApp* | Remove-AppxPackage

These cmdlets actually uninstall Xbox Console Companion for the current user i.e. the admin account used to invoke Powershell. The app will remain installed for all the other users on the machine and the packages at %ProgramFiles%\WindowsApps will stay in place. In my tests, more than 99.98% of the disk space originally used by the app is still occupied - this is because I never opened the app; if you ever used it you'd free more disk space.
In order to understand why the command is wrong, we have to recall two concepts about Powershell.
First: differently from the command prompt (cmd.exe), the typical output of a Powershell cmdlet is not simple text, but rather a fully featured object. If you are familiar with OOP (Object-Oriented Programming) you know what I mean. In case you are not, you can imagine an object as a structured variable that contains several fields. Each field has a name and stores a value. For example, the object MyIdentity could be:
Name: Mark
Age: 83
The Name field stores a string value, while the Age field stores an integer value. Get-AppxPackage returns an AppxPackage object. If you're wondering how it looks like, just type:

Code:

Get-AppxPackage -AllUsers -Name "*xboxapp*"

and hit return.
Second: the second concept is piping. To make it short, it is possible to pass the output of a cmdlet as the input to a second cmdlet by using a pipe (|). For example:

Code:

cmdlet1 | cmdlet2 | cmdlet3

The output of the last cmdlet in the chain (which will be an object) is converted to text and printed on the screen - unless it gets redirected, right, but I'm trying to keep it simple. Please note that you and only you are responbile for granting that the output object type and the following input object type are compatible with each other. If they are not, the execution will be aborted and you'll typically get an error on the screen.
Back to our inital problem, now you see that the AppxPackage object(s) returned by Get-AppxPackage is(are) sent to Remove-AppxPackage. In case you really want to check what pops out on the right-hand side of the pipe, you can use the pretty redundant command:

Code:

Get-AppxPackage -AllUsers -Name "*xboxapp*" | Write-Output

No big surprise, the output printed on the screen is the same as using Get-AppxPackage alone.
This is the crucial point: as you can check yourself using the command here above, the AppxPackage object passed down the pipe does NOT contain any reference to the -AllUsers parameter. Moreover, even if it did, Remove-AppxPackage does NOT accept pipeline input for its -AllUsers parameter. Therefore, Remove-AppxPackage gets executed with the default value for its -User parameter i.e. the user who invokes the cmdlet.
Adding -AllUsers to Get-AppxPackage has no effect at all. Both with and without it, the app will be removed only from the admin account if that account has the app installed. Both with and without it, nothing will happen if the admin account doesn't have the app installed.





*** SECTION THREE ***
*** Let's Remove-AppxPackage for -AllUsers ***
Now that we know why the first approach fails, we can attempt a second iteration with:

Code:

Get-AppxPackage -AllUsers -Name "*xboxapp*" | Remove-AppxPackage -AllUsers -Confirm

where I added two parameters to Remove-AppxPackage:
-AllUsers: the first cmdlet needs it, in order to retrieve the app even if it is not installed to the admin account. The second cmdlet needs it, as previously demonstrated. Also very important, this parameter tells Remove-AppxPackage to work off the parent package type.
-Confirm: because the object that goes down the pipe is not printed on the screen and I want to know what is going to be removed before it actually gets removed. In addition, unless I'm writing a script intended for background execution, I like to be prompted for confirm before any modification is made to the system.
Surprisingly, the command works for a few seconds and then it fails. This time it exits with error code 0x80073D19. A quick look at the developer help page:
https://go.microsoft.com/fwlink/?LinkId=235160
reveals that this error code corresponds to:
ERROR_DEPLOYMENT_BLOCKED_BY_USER_LOG_OFF --- 0x80073D19 --- An error occurred because a user was logged off.
However, this description will turn out to be very misleading. The failure has nothing to do with a user logged off.
In order to gain a better understanding of what is going on, I run the Event Viewer by typing eventvwr.msc in the run dialog box. In the left pane, I expand:
Event Viewer (Local) -> Applications and Services Logs -> Microsoft -> Windows -> AppXDeployment-Server -> Microsoft-Windows-AppXDeploymentServer/Operational
and I review the latest log entries. I see that everything goes well until an attempt is made to access a registry key, then error 0x80070002 is thrown. Since not even this error code is helpful, I switch back to Powershell and I point it to the problematic registry hive by typing:

Code:

Get-ChildItem HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\Applications\*xboxapp*

which returns only one key with name:
Microsoft.XboxApp_48.67.14001.0_neutral_~_8wekyb3d8bbwe
Got it. The problem is a registry key mismatch. Get-AppxPackage returns an AppxPackage object with a PackageFullName field containing the value:
Microsoft.XboxApp_48.67.14001.0_x64__8wekyb3d8bbwe
This is the package Remove-AppxPackage works on. Everything goes well while uninstalling the app from the user profiles, but when the cmdlet reaches the final steps of the process and queries the registry, it doesn't find a matching package name.





*** SECTION FOUR ***
*** RTFM ***
So how come the registry key doesn't match? The key was created by Microsoft and they should know what they're doing. Of course they do. It was our mistake. As usual, when things go wrong it is a good idea to RTFM: Read The "Fine" Manual - or at least the one with "Fine" is the polite version of it.
https://docs.microsoft.com/en-us/pow...-ps#parameters
The Remove-AppxPackage official help page states that, when calling the cmdlet with the -AllUsers switch parameter, it is important to check whether the app you want to remove is distributed as a bundle. If so, it is mandatory to feed the bundle package to the cmdlet. As you can check yourself, the app I'm trying to uninstall is a bundle indeed. Actually, the great part of the provisioned apps are installed as bundles.
https://docs.microsoft.com/en-us/pow...-ps#parameters
Reading carefully the Get-AppxPackage help page brings us to the end of the story. Unless otherwise specified, Get-AppxPackage queries the local app repository for packages of type Main and Framawork only. Bundle and Resource packages are not retrieved by default. If you want the bundle package, you have to use the -PackageTypeFilter parameter and specify the bundle. The final and correct version is therefore:

Code:

Get-AppxPackage -AllUsers -PackageTypeFilter Bundle -Name "*xboxapp*" | Remove-AppxPackage -AllUsers -Confirm

Hit return and wait until the uninstall process completes. The app will be uninstalled from all user profiles on the machine and the app's main files will be removed. All the app remnants under %UserProfile% and %ProgramFiles% will be deleted. Also, the command will take care of deprovisioning the app from the online Windows image, so there is no need to call DISM cmdlets. If you really want to check, just run:

Code:

Get-AppxProvisionedPackage -Online | Where-Object PackageName -Like "*xboxapp*"

Nothing will be returned, which means the app has been deprovisioned. As an additional check, I had a look at the Event Viewer: only information-level entries are recorded, no errors or warnings. Also, the app's registration in the Windows registry is removed, and a new key is created to flag the app as deprovisioned. I repeated the process with a few more apps and eveything worked seamlessly so far.





*** SECTION FIVE ***
*** Sum it up ***
That's it. If you want to completely uninstall and remove a provisioned app from a Windows 10 machine, follow these steps. Substitute "*appname*" with the name of your app, keeping the double quotes (") and the wildcards (*).
STEP 1 - Open a Powershell prompt: Win + X -> Windows Powershell. At this point it is not important whether or not the shell is elevated. That's because we're going to access the HKLM registry Root Key with a read-only query. Run:

Code:

Get-ChildItem HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\Applications\*appname*

STEP 2 - If the key returned in step 1 contains either _x64__ or _x86__, the app you're about to remove is NOT installed as a bundle. From within an elevated Powershell window, run:

Code:

Get-AppxPackage -AllUsers -Name "*appname*" | Remove-AppxPackage -AllUsers -Confirm

STEP 3 - If the key returned in step 1 contains _neutral_~_, the app you're about to remove IS installed as a bundle. From within an elevated Powershell window, run:

Code:

Get-AppxPackage -AllUsers -PackageTypeFilter Bundle -Name "*appname*" | Remove-AppxPackage -AllUsers -Confirm

STEP 4 - If you feel the need to verify that everything went well, open the Event Viewer by typing eventvwr.msc in the run dialog box. In the left pane, expand:
Event Viewer (Local) -> Applications and Services Logs -> Microsoft -> Windows -> AppXDeployment-Server -> Microsoft-Windows-AppXDeploymentServer/Operational
and check the last few entries. There should be no errors or warnings.
STEP 5 - In case you find the procedure fails for some apps, please post back so that your feedback can help other users.

Cheers,
Mark

- - - Updated - - -

A few updates.

1 - I see that Brink modified option 6 and 7 in his tutorial by adding -AllUsers to all Remove-AppxPackage cmdlets. However, I'm still convinced that's only part of the problem. @Brink, I'll continue the discussion here because I think this thread is more specific to the topic I'm focusing on.

2 - I disagree that the -Name word makes any difference. If you don't specify -Name, the cmdlet parser will try to fit the literal string you give to the right parameter and it will implicitly add -Name before executing. In case no parameter match is found, the execution is aborted and an error is thrown. My decision to add -Name is just a matter of programming style: I find it more readable and closer to natural language. Both versions behave the same.

3 - In order to verify what stated in point 2, try your command style:

Code:

Get-AppxPackage -AllUsers "*bingweather*"

and see that it only returns the Main package, flagged by _x64__. This is because no value is passed to -PackageTypeFilter and therefore the cmdlet queries the local package repository for packages of type Main and Framework only.

4 - As an additional test, now try to issue the following command:

Code:

Get-AppxPackage -AllUsers "*bingweather*" -PackageTypeFilter Bundle, Framework, Main, Resource

This time all packages are returned. In both point 3 and 4 I do NOT explicitly call the -Name parameter. The difference is only made by -PackageTypeFilter.

Cheers,
Mark

Further update.

@Brink, I have a theory to justify the different behaviour between my machine and yours. That's system language.
I guess your system language is English. In that case, it can be that several provisioned apps are installed as a single package, i.e. the Main package. This explains why you could remove the XboxApp without using -PackageTypeFilter. Get-AppxPackage retrieves the Main package as by default, which matches the package name stored in the registry and so Remove-AppxPackage runs smoothly.
My system language is NOT English and indeed I often see three packages: the Main one, the language Resource package, plus the Bundle package used to wrap them up. Therefore I necessarily have to specify the -PackageTypeFilter parameter, as its default value does NOT include the Bundle and I would get a registry key mismatch which, in turn, would crash Remove-AppxPackage.

Anyway, I recommand to pay attention because many apps come in bundles including packages other than the language one. This I cannot try, because I am biased by the language packages. Someone with an English distro should query the registry for installed bundles:

Code:

Get-ChildItem HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\Applications\*neutral*

and try to uninstall any of them without -PackageTypeFiler to see if it fails, i.e.:

Code:

Get-AppxPackage -AllUsers -Name "*appname*" | Remove-AppxPackage -AllUsers -Confirm

Cheers,
Mark

Brink said:

Great work Mark.

As a test, I searched the app list created using step 2 in option 3 with the keyword "neutral" to see which apps may require -PackageTypeFilter Bundle.

It appears the app packages with "neutral" were mostly all system apps that shouldn't be removed, so I'm not sure this will be needed for apps installed by users from the Microsoft Store.

Did you see anything different?

Sorry, that can't work, because you're searching for neutral after quering without -PackageTypeFilter. That is: you retrieve only Main and Framework packages and then you search the ones with an undefined architecture.
You should rather use:

Code:

Get-AppxPackage -PackageTypeFilter Bundle | Select-Object Name, PackageFullName

But I would suggest you to query the registry as I suggested in my last post. That should be even better because you're not relying on assumptions on Get-AppxPackage. With a registry query you're asking Windows which Bundle apps it has installed.
Or, if you feel like, try both and compare the results.
Cheers,
Mark

A few more updates.

1 - Hello @Brink. Nice you added option 12 in the tutorial, and thank you for providing a link to this thread. I think it is good to keep this sub-topic separated, so that the tutorial thread doesn't get too overcrowded and also because I understand it sometimes gets too technical for some users. I had a look at option 12 and that's indeed the only way it works for me. More on this in point 5.



2 - I read again my last post and I see I was not totally clear, so I'll try to elaborate. In particular, I'd like to talk about the difference between _neutral_ and Bundle, as they are unrelated, but partially overlapping concepts. I want to say that there is no official explanation from Microsoft - or at least I didn't find any. Therefore the following are my conclusions after extensive testing.
A FullPackageName has the general form xxx_Field1_Field2_yyy. To stay focused on the topic, I won't talk about xxx and yyy. _Field1_ indicates the package architecture. It can be any of the following:
_x86_ -> 32-bit package
_x64_ -> 64-bit package
_neutral_ -> undefined, i.e. good for both architectures
_Field2_ indicates the package type. It can be any of the following:
__ (i.e. _void_) -> either Main or Framework
_~_ -> Bundle
_split.otherstuff_ -> Resource
I checked all app packages installed on my machine and this interpretation works consistently. I'll report just an example of Powershell output, which provides a meaningful summary:

Code:

PS C:\Users\Mark> Get-AppxPackage -PackageTypeFilter Bundle, Framework, Main, Resource -Name "*BingWeather*" | Select-Object PackageFullName, Architecture, IsBundle, IsResourcePackage

PackageFullName                                                            Architecture IsBundle IsResourcePackage
---------------                                                            ------------ -------- -----------------
Microsoft.BingWeather_4.8.19002.0_neutral_~_8wekyb3d8bbwe                       Neutral     True             False
Microsoft.BingWeather_4.46.22322.0_x64__8wekyb3d8bbwe                               X64    False             False
Microsoft.BingWeather_4.46.22322.0_neutral_split.language-xx_8wekyb3d8bbwe      Neutral    False              True
Microsoft.BingWeather_4.46.22322.0_neutral_split.scale-100_8wekyb3d8bbwe        Neutral    False              True

So now we see the difference between _neutral_ and Bundle: all Bundle are _neutral_, but not all _neutral_ are Bundle.



3 - Digging even deeper. At the time I started this thread I thought that all Main and Framework packages would have a defined architecture. Or, to put it in a different way, I thought that _neutral_ would imply either Bundle or Resource.
It turns out I was wrong. Scrolling through the installed packages, I saw a few examples of Main packages with _neutral_ architecture. These are rare cases, but still something to keep in mind.



4 - I really have to rephrase the justification I gave in my last post for quering the registry - I was tired, sorry, reading it today it doesn't make any sense at all. What I ment is simply that I first saw the error during a registry key lookup and I suggested to start the investigation from there.
Anyway, after what I discovered in point 3 here above, it is probably easier for the average user to use Get-AppxPackage to retrieve the installed app bundles.



5 - @Brink, I suggest to make one modification to point 12 in the tutorial. I can think of a situation where the admin account used to run Powershell has some apps already uninstalled. In order to retrieve all apps, it is better to add -AllUsers:

Code:

Get-AppxPackage -AllUsers -PackageTypeFilter Bundle | Select-Object Name, PackageFullName

Cheers,
Mark

Brink said:

Do you think it best to update options 6 and 7 for all users to use commands based on step 3 of option 12?

That's a good question. Based on my limited experience, I would be tempted to say yes - it doesn't work for me without bundle. But it's also true that you managed to successfully remove XboxApp without having to go through the bundle thing. So I think it's best to leave it as it is until we figure out exactly when bundle is needed. I see it would be unpleasant for you to revert the tutorial back to its current version, so I wouldn't advise to completely modify option 6 and 7 unless we know for sure that it will work for everyone.

I can't think of any further test on my machine, other then checking both versions with more apps. If you feel like, you could help with some tests on your side. Instead of just running the command, may I suggest you to take a look at the logs to see if you get the same events with and without bundle? The logs are in:
Event Viewer (Local) -> Applications and Services Logs -> Microsoft -> Windows -> AppXDeployment-Server -> Microsoft-Windows-AppXDeploymentServer/Operational

Cheers,
Mark