Forum Discussion

TIMOTHY_MANGAN's avatar
TIMOTHY_MANGAN
MVP
Jun 21, 2020

More registry issues on OS 2004

Application: Siemens JtToGo

 

When repackaging using the MSIX Packaging Tool, the application pops up a message that it cannot create a key.  ProcMon traces on older OS versions and 2004 show an improvement in what the app is trying to do, but it still isn't enough.

 

See attached trace image taken from a 2004 system of the package.

 

The app package has a key  HKCU\Software\Siemens\JtToGo_retained\12.2\Common\C\ and an unrelated subkey under it.

 

The app first tries to create a new subkey ( VPSearch), and then a sub-subkey (LocationCache).

 

In 1909 and below, the attempt to create the VPSearch subkey fails.  2004 runtime includes support that now allows that subkey to be created.  However the sub-subkey creation still fails, likely due to some faulty logic in the code that allowed the first case to now work.

6 Replies

  • TIMOTHY_MANGAN's avatar
    TIMOTHY_MANGAN
    MVP
    Dec 11, 2022

    Dian Hartono 

     I am bumping this issue as it still has not been addressed and probably should be.

     

    If a package includes registry.dat file(s) for user settings, let's say the equivalent to HKCU\Software\Vendor\App, there is a significant limitation (read bug) in the runtime registry support when the app is run inside the container:

    • The app can add new registry items under the "App" key.
    • The app can add a new subkey under the "App" key (let's call it "Subkey").
    • The app can add new registry items under the new "Subkey".
    • The app cannot add another subkey under the new "Subkey".

    This is not expected behavior and cases apps to fail.  I've mentioned two such apps that show this behavior when re-packaged into MSIX and I'm sure there are many more.

     

    The only work-around is to discover every sub-subkey the app might create at runtime and include these in the package registry.  This is not an acceptable long-term workaround as there is no complete discovery process possible if you don't have the source code to the app. 

     

    This behavior would also not be expected by any new, modern, apps that choose to use the registry, and if not addressed will cause some of those apps issues too.

    • VikrantChib's avatar
      VikrantChib
      Icon for Microsoft rankMicrosoft
      Jul 12, 2023

      TIMOTHY_MANGAN 

      We tested the Siemens JtToGo App on Win 10 and Win 11:

      1. App's package does not contain any predefined subkeys as mentioned "VPSearch" or sub-subkey "LocationCache".
      2. App successfully created subkeys(VPSearch) and sub-subkeys(LocationCache) on both OSs.

      Testing environment:

      Win 10 - Version: 21H2

      Win 11 - Version: 22H2


      Are you still seeing this issue?


       

      • TIMOTHY_MANGAN's avatar
        TIMOTHY_MANGAN
        MVP
        Jul 12, 2023
        I will go back and re-test. There was a fix I made to the RegLegFixup two weeks ago that may have been for the cause of this issue. Not all of the fixup rules were being used so it is possible that the requested permissions were not corrected in the call.
  • TIMOTHY_MANGAN's avatar
    TIMOTHY_MANGAN
    MVP
    Jun 21, 2020

    And here is another case.  WinSCP.

     

    In this case, the package has a key "HKCU\Software\Martin Prikryl\WinSCP 2" with an unrelated subkey.  It attempts to RegCreateKey with the same type of request (Desired Access=Read/Write) in the procmon trace (attached) on OS 2004.

     

    This looks exactly like the Jt2Go case for VPSearch but unlike Jt2Go, this one fails.  So perhaps there is more going on than I can trace, but clearly the results of key creation within the container questionable; I can't figure out what will or won't work from the calling parameters as shown in Procmon and what is in the package.

Resources