Forum Discussion
Registry settings missing on app launch, but exists in User.dat in msix package
pysjkrig It all depends on how the app accesses HKCU.
First of all, when you get to the 2004 or 20H2 version of the OS for deployments, the basic MSIX runtime treats HKCU access better than prior versions. This could be enough to solve the issue if the app wants to open the HKCU keys and items for read/write alone.
But some apps blindly ask for additional permissions that they don't need. The app always worked when natively installed or under App-V, as the app could do anything it wanted under HKCU. MSIX, even under OS2004, does not.
It may be possible to use process monitor against the packaged app and look for access permission issues in HKCU. Some of those may be addressed using PsfTooling and the RegLegacyFixup.
I am having a very similar issue:
1. Package up ARCGisPro as a MSIX, and confirm that I have some required keys under HKCU within the user.dat (within the package)
2. Install MSIX (via App Attach) and the HKCU keys are not available.
On a thick install, the process of launching the product would generate the required keys (linked to licensing), however with the MSIX, it will NOT generate the HKCU key.
My only workarounds are:
1. Run the application elevated as ADMIN, still I can't see the keys get generated, but it appears to launch the product with the information previously captured in the user.dat (its a unique license portal URL)
2. Manually create the HKCU keys for the logged on user, then the application will launch.
Any help / ideas on how you resolved your similar issue would be greatly appreciated.
Thank you
You didn't mention specific tools used, but I assume the Microsoft MSIX Packaging Tool is used to create a MSIX package, and then a second tool is used to convert into either VHD or CIM and MSIX App Attach is used.
Given the above, I would first break the problem into two parts. During the initial capture, the HKCU keys should be captured in the package. This could be verified by installing/running the package, however there may be issues with the vendor software in how they access those keys. To determine if the registry values were captured, you would break into the package to extract the Registry.Dat file, go to RegEdit, create a dummy key somewhere, right click on that dummy key and import the Dat file. It sounds like you have done that (using the User.Dat file which is OK).
Assuming the registry was captured (which I suspect is the case), I would then repackage using the Package Support Framework (PSF). Last year I created a fixup there called RegLegacyFixup that can solve the most common issues we see in how the app might try to access the HKCU keys/values that you captured.
Once you have a working package in MSIX form, then migrate it to CIM and MSIX App Attach. I don't think the second part should break the registry, but at least we'd know where the problem is.
- Hi Timothy,
Thanks for the reply.
Yes you are correct, I am using the latest MS MSIX packaging tool, creating the MSIX then migrating to a VHDX for App Attach.
I can confirm that when I open the MSIX I can see both registry.dat and user.dat, and when I import either or BOTH into a dummy key, I can see my HKCU hive entries just fine.
Would I be correct in thinking that when the MSIX is installed (ignoring App Attach), the embedded HKCU hive should be visible within my HKCU, and again gets removed on uninstallation? (As I am NOT seeing this).
Interestingly, if I simply mount the VHDX disk and browse the VFS to my application launcher, everything appears to work fine.
I have downloaded your PsfTooling from the store, but am unable to see how the RegLegacyFixup works, as when I select it for HKCU, I do not get any option to "Apply to Proposed Changed List" and the JSON file does not get modified. Do you have any guides on how this tool should be used?
Thanks Again
NickNick-S After selecting the RegLegacyFixup, you need to add rules that the app needs. I usually start with a default set of three rules. I'll attach a screenshot.
Older applications will sometimes assume the ability to do whatever they want under HKLM. Inside the container, they are not allowed to request certain permissions, so calls that previously would have worked now fail (even if they don't try to actually use those permissions). So this fixup intercepts those calls and gives them the subset that are supported, or just fake out that it worked even when it doesn't. It isn't perfect, but these three rules seem to be solving every case I've seen to date (for HKCU).
