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:
-------------------------------------------------------------------------------------
\RESIGITRY\USER\SOFTWARE\Vendor
\RESIGITRY\USER\SOFTWARE\Vendor\App
\RESIGITRY\USER\SOFTWARE\Vendor\App\Sk1
Name=n1 value="v1"
\RESIGITRY\USER\SOFTWARE\Vendor\App\SK1\SK1SKA
--------------------------------------------------------------------------------------
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.
