MSIX works on Windows 11 but not 10

Copper Contributor

Hi everyone,


I am in a bit of a bind.

We are trying to hammer a Qt application into a MSIX package.

We succeeded for Windows 11.

We use LoaderSearchPathOverride to make sure all dlls can be found.

Additionally we use installedLocationVirtualization so we may create files and write to the install folder in WindowsApps.


Unfortunately the msix installed app fails on Windows 10.

A secondary exe in our package (webengineprocess.exe) tries to open Qt6Webenginecore.dll in the WritablePackageRoot.

This returns ACCESS_DENIED and the application fails with 0xc0000022 


I am at a bit of a loss how this could work for windows 11 but not windows 10.

Does anyone have any suggestions?


2 Replies

Hi @WaterPigeon,

you can try to add the webengineprocess.exe executable to the AllowAllTrustedApps registry key.

This is the least invasive solution and will allow the MSIX package to work on both Windows 10 and Windows 11.

To add the webengineprocess.exe executable to the AllowAllTrustedApps registry key, follow these steps:

  1. Open the Registry Editor.
  2. Navigate to the following key:


  1. Right-click on the AllowAllTrustedApps key and select New > String Value.
  2. Enter the following name for the new string value:


  1. Double-click on the new string value and enter the full path to the webengineprocess.exe executable in the Value data field.
  2. Click OK to save your changes.

Once you have added the webengineprocess.exe executable to the AllowAllTrustedApps registry key, you should be able to install and run the MSIX package on both Windows 10 and Windows 11.

Please click Mark as Best Response & Like if my post helped you to solve your issue.
This will help others to find the correct solution easily. It also closes the item.

If the post was useful in other ways, please consider giving it Like.

Kindest regards,

Leon Pavesic

@WaterPigeon If the reply by LeonPavesic solves this for you it might be the simplest way, although I'm not sure how that solves it. But then I'm not sure why Win10 isn't working either if Win11 works with the same package. There are a few things that are that way, but you didn't mention any of them.  If Walter's suggestion does not work, here are some additional ideas.


It is not unusual for a multi-executable package to get confused with InsalledLocationVirtualization.  This happens when an exe looks to a file handle and queries where that file is.  Even if the file was opened using a path somewhere under the package folder, the reported path WILL be under the redirected root folder.  The app often then asks for an offset from that folder which can confuse things. Using the PSF's MfrFixup in ILV-Aware mode, among other things, will redirect the subsequent request back to the equivalent package path and would likely solve this.


As it is a dll, there are situations where you may need a different solution, although adding in the MfrFixup should cause no harm.  Either the PSF DynamicLibraryFixup, or the AppXManifest extension LoaderSearchOrder to find that dll as well.


If you want the PSF version with MfrFixup, the best way depends on how you are making the package.


And please let us know what worked for you!