MSIX Runtime HKCU CreateKey


If you have a package that contains the registry key


And you run that package and it creates a subkey under Vendor named "Settings".


If the application calls CreateKey against the "Vendor" key requesting access "MaximumAllowed", it is granted permissions "Read/Write."


If the application calls CreateKey against "Settings" key requesting access "MaximumAllowed", it is only granted permissions "Read, Write DAC".


Attached is a procmon trace showing this situation, the highlighted line being the case of opening the key from the redirected helium containerized registry.  In this case, the app examined the return permissions and gives up.





8 Replies


Thanks for reporting this. I would love to know a little more details about this issue (like App name, expected registry details, if it was previously installed, etc.


However, I have faced similar issues in the past, and found that (the workaround of) enabling the capability of 'Run as administrator (restricted)' often resolves this issue.



In case this doesn't work, you can also try to run the (MSIX) application as an administrator, and it may resolve this issue.

The application is "ExamDiff" from PrestoSoft (a free product you can access from their website).

The image I provided in the original post shows the line in a procmon trace that is problematic as the highlighted one (click on the image to view).  The test was on a clean VM that had never seen the product.

This example was taken from a package that included the PSF RegLegacyFixup (which is needed because without it the app won't store user options in the registry at all). The result shows in the details column of procmon that "Read, Write DAC" permissions were granted. Instead, the result should say that "Read/Write" permissions were granted, just like the call made against the parent key 6 lines previous.



Would it be possible for you to share the config.json for the PSF RegLegacyFixup? We can try to fix this manually. We'll share the fix if it works.

Best method would be to send you the package. Give me a link to send it to you.
Tim, can you please send it to me as a Private Message? You can attach files upto 70 MB here.

[package sent previously]

@Aniket_Banergee I have been doing some digging on another app with an issue using CreateKeyEx in a similar situation which may be interesting as well. In this similar case, the call requesting "Maximum_Allowed" permissions gets an access denied.

In this case, the caller first opens the HKCU key.
Then it calls CreateKeyEx using the returned HKCU key and a path "Software\..." which represents a key present in the package, the call to impl:CreateKeyEx is requesting Maximum_Allowed permissions and this call is successful.

The app passes this package key to another CreateKeyEx call to create a subkey not present in the package. If I query the key passed by the app in using NTQueryKey, this shows the key path in the form "=\REGISTRY\USER\...". This CreateKeyEx call is the one returning ACCESS_DENIED, which is incorrect.


PS: I am testing against Windows 10 31H2 (19044.1706) with May 2022 updates.

Hi Tim,

Acknowledging your post. This is more complicated than I initially anticipated. We are working on this, I'll let you know as soon as we find a solution, or if we need more details.
OK. I'll mention that while I haven't run this completely down, I increased some logging and I'm now believing that calls to OpenKeyEx and CreateKeyEx against keys that are in the package return the key, but the "result" value returned by the function is not always 0. Likely that when the native key of what would be the parent key requested by the app is not present on the system (but is in the package) the result value is 2. For keys the dev know were put down by the installer the dev may or may not look at that result value as long as the key is returned.