Application Hive limitations for HKCU


When we have an MSIX package that contains a Registry.dat hive with REGISTRY\USER keys and name/value pairs, the behavior of the runtime is, in in mind, incorrect and leads to many issues with bringing traditional code into MSIX.


The problem stems from situations where the dat file contains some initial keys and the application wants to add subkeys, and sub-subkeys under some of those entries at runtime.  The traditional app usually assumes that attempts to open or create these subkeys and sub-subkeys will return ""PATH_NOT_FOUND"/FILE_NOT_FOUND"/"ERROR_SUCCESS" return codes.  Given a native app and an attempt to open/create a HKCU key, that is the only response you'd see, so other returns are not expected and the developer rarely looks for them.  Should the call fail for other purposes the code is likely to crash, or at best the developer will put up a dialog to say the installation needs to be repaired/replaced.


A specific example can be found in an application like "Fiddler", when repackaged.  The description that follows is a generic one to explain where things go wrong.  The packaged app crashes when shut down and there is nothing that the PSF can do about it.


Example Registry.dat file in package:


                                                                                  Name=n1 value="v1"



The app calls OpenKeyEx HKEY_CURRENT_USER\SOFTWARE\Vendor\App with "MAXIMUM_ALLOWED" permission request (Success)
The app calls OpenKeyEx HKEY_CURRENT_USER\SOFTWARE\Vendor\App\SK1 with "MAXIMUM_ALLOWED" permission request (Success)
The app calls OpenKeyEx HKEY_CURRENT_USER\SOFTWARE\Vendor\App\SK2 with "MAXIMUM_ALLOWED" permission request (ACCESS_DENIED) <-- This should be FILE_NOT_FOUND
The app calls CreateKeyEx HKEY_CURRENT_USER\SOFTWARE\Vendor\App\SK2 with "MAXIMUM_ALLOWED" permission request (ACCESS_DENIED) <-- This should be SUCCESS


In the traditional app models, such a call would never generate an ACCESS_DENIED return code to an attempt to open/create a key under HKCU and a lot of existing vendor code does not check for that error (resulting in using a null handle) or assumes that the installation is botched and asks the user to reinstall.


Adding a SK2 key to the Registry.dat file solves this issue, however that means you need to understand every key that the app might expect to look for in order to create a good package.  This is too high of a hurdle when you don't have access to the vendor source code, and probably even for the vendor that does ;)


I would suggest that the runtime processing for registry requests that fall under the area of influence of the Registry.dat overlay should allow such operations to proceed, looking into the redirected non-persistent overlay of the package in the user's profile and allowing key enumeration and creation without error.


2 Replies
So according to your post you are adding user keys (HKCU) to Registry.dat, but Registry.dat can only contain machine keys (HKLM).

User keys should be added to User.dat, not Registry.dat. Can you please try that and see if that works?

@Dian Hartono 

Well let me clarify. I did intend to say the Registry.dat as that's one of the places they are stored when a package is captured by the Microsoft MSIX packaging tool (see attached image). Another copy of the user portion contained in that file is also stored in the User.dat file, so whichever source the installer uses I mean that one.

By the way, it would be nice to know if one of those is a mistake by the packaging tool and not needed in the package. My tooling, for example, assumes that since the MMPT is putting the user registry keys in both dat file, I must make duplicate changes in both of those files when editing the package.