Windows 10: How to remove python.exe from the WindowsApps directory

Split from this thread. Somehow my user environment is pointing to a python.exe located in my WindowsApps directory, but when I look in my Microsoft Store library and Apps in Settings, it isn't there. I want to remove the python.exe from WindowsApps because I have Python installed elsewhere which I prefer to use, but Windows won't let me delete the file. When I run the file, it takes me to the Microsoft Store to install Python which I don't want to do. It's apparently not actually installed through the Microsoft Store and the python.exe file in WindowsApps is some kind of residual from when

:)

 

Why can't an inactive "WindowsApps" directory/volume be removed?

For those who are unaware, modifying the default storage path for an individual application (or all applications) downloaded through the Windows Store, will result in a protected "WindowsApps" directory/volume being created at the specified path (i.e. "D:"
will become "D:\WindowsApps"). Unfortunately, even if this directory/volume becomes inactive (i.e. no applications utilise it), it cannot be removed (well, it can be removed, but will cause system instability, read below for further details).

I've attempted to remove the inactive "WindowsApps" directory/volume by doing the following:

1) Set the default storage path for applications to "C:" ("Settings", "Save Locations", "New Apps Will Save To...").

2) Ensured no applications are installed to "D:" ("Settings", "Apps & Features", Filter "D:").

3) Took ownership of the directory/volume ("Properties", "Security", "Advanced").

4) Set the relevant registry keys back to default values:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\PackageVolumes: "DefaultVolumeKey" = 1, "EnableExternalVolumes" = 1.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\PackageVolumes\1: "Default" = Null, "Flags" = 2, "MediaId" = Null, "MountPoint" = Null, "Name" = Null, "SISPath" = "C:\Program Files\WindowsApps".

5) Removed unnecessary registry keys (which are created and increment in value — based on the "NextVolumeIndex" DWORD — whenever a new directory/volume is specified):

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\PackageVolumes\2.

6) Performed the equivalent of steps 1-5 through an elevated PowerShell window (using "Set-AppxDefaultVolume", "Get-AppxPackage", "Add-AppxVolume", and "Remove-AppxVolume").

7) Removed/recreated the directory/volume through the recovery command prompt.

8) Removed/recreated the directory/volume through safe mode.

9) Removed/recreated the directory/volume through Linux (using a live CD).

10) Enabled and used the elevated "Administrator" account (by using "net users Administrator /active:yes" in an elevated command prompt).

11) Enabled and used the elevated "SYSTEM" account (by using "psexec -i -s cmd.exe" from System Internals in an elevated command prompt).

12) Assigned a different drive letter (i.e. "D:" became "E:"), even though the volume identifier remained the same.

13) Removed/recreated the partition.

Steps 1-6 (and 12) all resulted in "access is denied" errors. Steps 7-11 all allow the "WindowsApps" directory/volume to be removed and recreated, but not cleanly. If the directory/volume is removed using these methods, and the "WindowsApps" directory is
recreated manually (i.e. through File Explorer "explorer.exe"), it will result in system instability (i.e. process not responding). If the directory/volume is recreated using these methods, the permission issues (i.e. "access is denied") return. It seems like
a background process/service (which isn't active in safe mode) is locking the directory/volume, and preventing it from being removed/renamed or overwritten. So, the actual file permissions seem irrelevant. The only solution — as ridiculous as it is — is formatting
the partition, but the term "solution" is used very loosely.

So, this illogical issue has wasted a significant amount of my time and effort. Why would I say "illogical"? Well, it doesn't make any logical sense as to why an empty and inactive — I repeat, EMPTY and INACTIVE — directory/volume cannot be removed. It could
somewhat be justified if the directory/volume was active to prevent tampering, but even then, couldn't the integrity of the package contents simply be verified via checksums? The lengths Microsoft have gone to in order to prevent users modifying these directories/volumes
is absurd. It's malware-like.

Now, this is more than just an inconvenience, it's a usability issue. There are legitimate reasons (other than tampering or reverse engineering) why users would need to access the "WindowsApps" directory/volume. The Windows Store allows users to purchase
AAA games (such as Rise of the Tomb Raider), which can be quite large in size (in the case of Rise of the Tomb Raider, it's almost 30GB). SSDs have become a necessity for good computing performance (and, as a result, an acceptable user experience), but are
still quite expensive based on capacity, which means most users are opting for boot/system disks in the range of 250-500GB. That doesn't stretch very far when a single game can occupy upwards of 10% of the total capacity. So, what happens when a user wants
to archive (SSD -> HDD) the application/game (whether it's to increase free space on the SSD or because he/she needs to reinstall Windows)? Should they be expected to download the application/game again? [FYI, the download speeds through the Windows Store
are so abysmal, it should be considered a form of torture.] Every notable digital distribution platform (GOG, Origin, Steam, Uplay, etc.) has the ability to backup, restore, and verify the applications/games (or worst case, use junctions), but nope, not Windows
Store!

So, either Microsoft hasn't done any usability testing, or they're oblivious to how users would want to utilise a digital distribution platform, or perhaps they just don't care and would prefer to dictate how users should do their computing (considering
there are several 3 month old discussions/questions bringing attention to this issue without resolution, this seems likely).

Anyway, it looks like I'll be downgrading back to Windows 7. There is no compelling reason to remain with Windows 10 (apart from DirectX 12, which isn't so appealing now that Vulkan is in the frame), but there are many compelling reasons not to (Convoluted
settings — why split them between "Settings" and "Control Panel"? Poor emulation/support for DirectDraw. Privacy concerns. Taking computing control/freedom away from users. The list goes on.).

 

Copying files into WindowsApps directory

Hi,

Thank you for writing to Microsoft Community Forums.

Please note that it is not advised to make any changes in the WindowsApps folder, as it can cause issues while using the pre-installed apps. However, to be on a safer side you can always create a system restore point to restore the PC to the state
where everything was working fine. Refer the article to
Create a system restore point

Kindly follow the steps mentioned below to take ownership of WindowsApps folder.

1. Click on the Search Bar on the left hand side of the
   Taskbar.
   
2. Now type CMD, right click on it, and select
   Run as Administrator.
   
3. Type in the following command: icacls "%ProgramFiles%\WindowsApps" /grant Administrators:F
   
4. Once the above command is successfully executed run the following command:
   icacls "%ProgramFiles%\WindowsApps" /grant Administrators:F /t
   
5. Type Exit and hit enter.
   
6. Restart the PC.
   

After the restart you should be able to make changes inside the WindowsApps folder.

If the issue persists, please get back to us with the results of troubleshooting steps to assist you better.

Regards,

Prakhar Khare

Microsoft Community – Moderator

 

Edit on Context menu and Python

Hi, suggest you try Default Programs Editor - free.

Search the list for your extension:




Example of Edit on the context menu




Add the command you want (Edit):


]