Need to allow app to "delete" HKCU registry keys/items.


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:

  1.  A full support for all registry operations in the MSIX Runtime, using redirection spoofing. One comprehensive change supporting full spoofed access to HKLM and HKCU in the redirected app container.  This is a complete and clean solution to any containerized registry issues.
  2.  Adding support in the PSF to spoof specific operations on specific items, by implementing a redirection to a per-package location in the non-containerized user hive. This piecemeal approach has the advantage of being more targeted, but far more complicated for everyone involved. And it wouldn't be cleaned up with the package is uninstalled (unless we get an uninstall script capability).
  3. Adding support in the Psf RegLegacyFixups for a new fixup type that simply spoofs the delete by telling the app that it did it, even when it didn't.  Advantage of more targeted and isn't leaving anything behind, but probably is more limited in what it can fix. 


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.

3 Replies

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.

Support for this fixup is part of PR #150 now submitted to the Microsoft Develop branch. It is a new type added to RegLegacyFixups. In essence, it allows one to specify keys/registry items for which if the app tries to delete it to ignore the error and return success.

@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).