Fixup: RegLegacyFixup

The RegLegacyFixup provides support for applications that use the registry in ways that would work when run outside of the container but are blocked when running inside of MSIX.

It allows you to define a set of rules that will be used when certain registry calls are intercepted. Currently the fixup supports two kind of rules:

1. A rule to modify the access permissions that the application is requesting.
2. A rule to ask the fixup to fake the result of a request to delete an item or key.
3. A rule to ask the fixup to hide native keys/values that might be present by including a "deletion marker".
4. A rule to ask the fixup to block access to all Java versions greater the specified version.

The RegLegacyFixup will intercept the following Windows API calls to the registry based on the rule type. These calls are the intercepted functions for the first rule type (ModifyKeyAccess):

• RegCreateKeyEx
• RegOpenKeyEx
• RegOpenKeyTransacted

These calls are the intercepted functions for the second rule type (FakeDelete):

• RegDeleteKey
• RegDeleteKeyEx
• RegDeleteKeyTransacted
• RegDeleteValue

These calls are the intercepted functions for the third type (DeletionMarker):

• RegCreateKeyEx
• RegEnumKeyEx
• RegOpenKeyEx
• RegOpenKeyKeyTransacted

These calls are the intercepted functions for the fourth type (JavaBlocker):

• ReOpenKey
• RegOpenKeyEx
• RegOpenKeyKeyTransacted

Traditional applications were allowed full control over registry keys and items located in the HKCU hive. This includes not only read and write permissions, but deletion, change of ownership, and other advanced and special permissions. Under MSIX, the HKLM hive only supports calls requesting Read accesses. Originally, this also applied to the HKCU, however the MSIX runtime was updated in the Windows 10 2004 (20H1) release to allow support for requests for Read and Write. Any calls to the registry keys/items defined in the container registry requiring other access permissions will result in an Access Denied error return.

The typical use of the first rule, is to modify the call accesses requested by the application to use an access request type newly defined in the OS called MAX_ALLOWED. When requested with this new access type, the key will be opened with whatever permissions that the MSIX runtime supports at that time. Assuming that the application did not actually require the additional permissions, the application will work as intended. Especially for older applications, it is not that unusual for the application to open registry keys under HKCU for the FULL_CONTROL access type and assume that the call will always succeed. Under MSIX without this fix the application may crash or request re-installation.

The typical use of the second rule is when the traditional application used the registry as a scratch space and wants to clean up after itself when shutting down. As deletion of registry keys/values that are part of the package container registry hive are not permitted, this may also cause the application to crash or produce errors. In faking this deletion, it is possible that the application may have issues when next run, but our experience so far indicates that this has not been an issue so far.

The configuration for this fixup consists of n field called remediation, which is an array of rules.

For the first three of the rule types, each of these rules consists of the following four name/value pairs:

• type, which defines the rule type with a value of ModifyKeyAccess or FakeDelete or DeletionMarker.
• hive, which defines the hive with values HKCU or HKLM.
• patterns, which is an array of RegEx strings to speficy the path (not including hive) to be affected.
• access, which is a name that specifies a combination of requested access type and substituted access type. This is only used for the ModifyKeyAccess type.

For the JavaBlocker rule type, the rule consists of the following name/value pairs instead:

• type, which defines the rule type with a value of JavaBlocker.
• majorVersion, which defines the major Java version ("1" at present).
• minorVersion, which defines the minor Java version (such as "4", "5", "6", "7", or "8").
• updateVersion, which defines the update version (such as "45").

The most common use of this fixup is to define three rules that cover most situations facing applications. This is shown in the example below:

    {
      "dll": "RegLegacyFixups.dll",
      "config": [
        {
          "remediation": [
            {
              "type": "ModifyKeyAccess",
              "hive": "HKCU",
              "patterns": [
                ".*"
              ],
              "access": "Full2MaxAllowed"
            },
            {
              "type": "ModifyKeyAccess",
              "hive": "HKCU",
              "patterns": [
                ".*"
              ],
              "access": "RW2MaxAllowed"
            },
            {
              "type": "FakeDelete",
              "hive": "HKCU",
              "patterns": [
                ".*"
              ]
            }
          ]
        }
      ]
    }

#More Information More information on the RegLegacyFixup, including an example using the DeletionMarker and JavaBlocker rules, may be found on the Developer Documentation page.