Windows appx removal fails with x64 package full name, succeeds with neutral package full name

Question

Windows appx removal fails with x64 package full name, succeeds with neutral package full name

Jeff Price 0

tldr: How am I supposed to use RemovePackageAsync?

I've got a packages Windows app that I install using StagePackageAsync followed by ProvisionPackageForAllUsersAsync. The package is specifically x64 only. When I install, I do have the package installed under two architectures: x64 and neutral.

When I use FindPackages to examine the system, I only see the x64 architecture. When I look at volumes and then use FindPackages on the volume I see both the x64 and neutral architectures, with unique install paths. e.g. full names

myAppName_1.2.3.4_x64__someId
myAppName_1.2.3.4_neutral_~_someId

When I uninstall the app I call RemovePackageAsync. I get different result from RemovePackageAsync depending on whether I call it with the full name for the x64 architecture or the neutral architecture.

When I use the x64 full name I sometimes get the following error. This doesn't occur on all systems, but on systems where it does occur it appears to happen every time.

Deployment DeStage operation with target volume C: on Package myAppName_1.2.3.4_x64__someId from:   failed with error 0x80070002. See http://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app deployment issues.

Going to that link showed me where to look in the event viewer to find:

Opening registry key: Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\Applications\myAppName_1.2.3.4_x64__someId failed with error: 0x80070002.

Looking for that registry key on systems where this is installed doesn't show it. Even on the system where this works I never have that key. I do have the equivalent key for the neutral architecture on all systems

Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\Applications\myAppName_1.2.3.4_neutral__someId

Using all this knowledge, I've been able to work around my uninstall problem by just trying both full names, and ignoring any errors. I "prove" it's really uninstalled by doing another check after trying and seeing if I can find any such packages. If I get 0 packages after uninstall I call that a success.

I'm looking for an explanation of this behavior, and best practices around removing packages using this API. Thanks!

Jeanine Zhang-MSFT 11,356 Reputation points Microsoft External Staff

2023-02-28T07:20:30.5333333+00:00

As far as I'm concerned, because you installed using StagePackageAsync, when you use FindPackages to examine the system, you only see the x64 architecture. And that registry key on systems where this is installed doesn't show it.

StagePackageAsync: Stages a Package to the system without registering it.

RemovePackageAsync: Removes a Package for the current user asynchronously

E_FILENOTFOUND 0x80070002: File or path is not found.

For more details about how to use the api you could refer to the sample: https://learn.microsoft.com/en-us/uwp/api/windows.management.deployment.packagemanager.removepackageasync?view=winrt-22621
Jeff Price 0 Reputation points

2023-02-28T15:56:56.8433333+00:00
@Jeanine Zhang-MSFT I'm not sure I follow your explanation.

I think you're telling me that it's expected that I only see the x64 architecture when using FindPackages.

I still don't understand why I don't see myAppName_1.2.3.4_x64__someId in the registry, when that's what error I get in the windows event viewer.

I don't understand why removing the package using only myAppName_1.2.3.4_x64__someId works for some systems, but that on others I need to both that and myAppName_1.2.3.4_neutral_~_someId

The link you've provided doesn't show a complete enough example for me to understand this behavior. It just shows somebody providing a full name as a command line argument and then the code calls RemovePackageAsync. I'm calling that successfully, including getting the progress events from it. If I wasn't, I wouldn't be able to see it uninstall successfully on the systems where this works.
Jeff Price 0 Reputation points

2023-02-28T16:18:45.91+00:00
It may help me to have a useful vocabulary here. What do the following terms mean in this context?:

"add", as in "add package"

registry

provision

stage
Jeanine Zhang-MSFT 11,356 Reputation points Microsoft External Staff

2023-03-01T02:23:02.7166667+00:00

Could you please provide the sample and detailed steps to help us reproduce the issue?
Jeanine Zhang-MSFT 11,356 Reputation points Microsoft External Staff

2023-03-07T07:46:44.24+00:00

Haven't heard from you for a while. Have you got any updates about this issue? Could you please provide the sample and detailed steps to help us reproduce the issue?

1 answer

Your answer

Jeanine Zhang-MSFT 11,356 Reputation points Microsoft External Staff

2023-02-28T07:20:30.5333333+00:00

As far as I'm concerned, because you installed using StagePackageAsync, when you use FindPackages to examine the system, you only see the x64 architecture. And that registry key on systems where this is installed doesn't show it.

StagePackageAsync: Stages a Package to the system without registering it.

RemovePackageAsync: Removes a Package for the current user asynchronously

E_FILENOTFOUND 0x80070002: File or path is not found.

For more details about how to use the api you could refer to the sample: https://learn.microsoft.com/en-us/uwp/api/windows.management.deployment.packagemanager.removepackageasync?view=winrt-22621
Jeff Price 0 Reputation points

2023-02-28T15:56:56.8433333+00:00

@Jeanine Zhang-MSFT I'm not sure I follow your explanation.

I think you're telling me that it's expected that I only see the x64 architecture when using FindPackages.

I still don't understand why I don't see myAppName_1.2.3.4_x64__someId in the registry, when that's what error I get in the windows event viewer.

I don't understand why removing the package using only myAppName_1.2.3.4_x64__someId works for some systems, but that on others I need to both that and myAppName_1.2.3.4_neutral_~_someId

The link you've provided doesn't show a complete enough example for me to understand this behavior. It just shows somebody providing a full name as a command line argument and then the code calls RemovePackageAsync. I'm calling that successfully, including getting the progress events from it. If I wasn't, I wouldn't be able to see it uninstall successfully on the systems where this works.
Jeff Price 0 Reputation points

2023-02-28T16:18:45.91+00:00

It may help me to have a useful vocabulary here. What do the following terms mean in this context?:

"add", as in "add package"

registry

provision

stage
Jeanine Zhang-MSFT 11,356 Reputation points Microsoft External Staff

2023-03-01T02:23:02.7166667+00:00

Could you please provide the sample and detailed steps to help us reproduce the issue?
Jeanine Zhang-MSFT 11,356 Reputation points Microsoft External Staff

2023-03-07T07:46:44.24+00:00

Haven't heard from you for a while. Have you got any updates about this issue? Could you please provide the sample and detailed steps to help us reproduce the issue?

Answer 1

I don't have a limited code sample that could easily demonstrate an issue.

I was mostly hoping that there would be documentation on how this whole system works that I could read. I don't find the API documentation you linked to be particularly useful in this regard. The sample just demonstrates the basic behavior without any acknowledgement of the issues I think I'm seeing, and the API docs just use the same terms without defining them.

That said, what we're doing now seems to work around the issue, and we've moved on to other problems. Thanks for your time.

Share via

Windows appx removal fails with x64 package full name, succeeds with neutral package full name

1 answer

Your answer