Jun 21 2020 08:58 AM
Jun 21 2020 08:58 AM
I have a specific application in mind, but this is a general issue with the containerized registry.
The application is Fiddler, and it throws an exception when shutting down. The app has a HKCU based key for preferences which it reads at startup, but then deletes when shutting down. Why? I'm not sure but let's assume it is trying to be a good program and clean up after itself. Such an operation was always allowed under the Win32 runtime, but an access denied occurs and the app throws an exception. I am attaching images of the application error popup, ProcMon trace showing the ACCESS_DENIED, as well as the call stack showing it was calling NtDeleteKeyEx.
We don't want the app to delete any registry item in the immutable system copy of the hive, just like we don't want it to write to it or add to it. But as we have seen with registry write calls, it is necessary to allow apps to make such attempts and we work around it. Recent changes to the MSIX Runtime allow writing to certain parts of the containerized registry, presumably using some sort of redirection to the user's application container, keeping the system copy intact but allowing the user to have an altered state.
We similarly need to allow apps to delete keys and items. This was similarly accomplished in App-V by the use of high-order bits in registry type fields (on the item itself, or in the case of a registry key by setting the high-order bit on the "default item" of the key) in the redirected area.
I see three possible approaches to solving this issue:
I can move ahead and build either #2 or #3, but really want Microsoft to weigh in on this as there is no sense in duplication of work. My preference is idea #1, but it isn't the first time I have asked for this.
Jun 30 2020 06:47 AM
Is anybody investigating/evaluating this? We've also seen apps that require elevation after being packaged as an MSIX just because the app is trying to write under HKCU.
Jul 08 2020 12:18 PM
Jul 13 2020 07:47 AM
@TIMOTHY MANGAN The PR is now completed and is part of the Microsoft Develop branch.
A build of this PSF is also included in the new PsfTooling version 4.0., available in the Microsoft Store (free).