How to Use The File Extensions Entry Point to Trigger Self-healing in an MSI

Self-healing, also known as self-repair, is one of the major benefits of the Windows Installer technology. In simple words, it ensures packages are secure and resilient by automatically checking and fixing them.

Although triggering the self-healing mechanism can be as simple as just clicking on the dedicated shortcut for it, there are some cases when you can’t apply the traditional shortcut method to trigger it.

As an alternative, you can use other entry points, such as file extension, to perform this necessary operation and fix your package.

Let’s first see how we can trigger the process of self-healing using the file extension entry point. But, before we dive into it, let's identify the main difference between advertised shortcuts and file extensions.

Advertised Shortcuts vs. File Extensions Entry Points

The self-healing mechanism is triggered by its entry points, some of which include:

• Advertised shortcuts.
• Internal components (COM) that are shared and used by other COM applications.
• File extensions.

In the self-healing process, a file extension entry point works similar to advertised shortcuts, with one particular difference:

An advertised shortcut entry point launches the application directly by triggering the shortcut target (an application executable), whereas, a file extension entry point launches the application indirectly - based on the association made by the registered file type when that specific file is executed.

Due to this distinction, a standard file type association (not registered via the specific Windows Installer advertised table) will not be able to trigger the self-healing mechanism.

In our Feature and Component Self-Repair article, you can find more information about the self-healing mechanism.

How does self-healing work using the file extension entry point?

The logic behind it can be summed up to this: when you register the file extension via the specific Windows Installer advertised table, an extra registry value gets installed to the target device.

That extra registry value is essentially an encoded value of the corresponding Product Code, Feature Name and Component ID that installs that specific file type association.

When you trigger the file extension entry point, Windows Installer decodes the data from the extra registry value and checks all its components under the specific feature and all the features above, until it gets to the top feature. If any keypath is missing or corrupted, then self-healing gets triggered.

To get a better grasp of it, here is how the registry keys look like for a file type association registered via the Registry table in an MSI. For the following example, Notepad ++ has been repackaged as an MSI.

The image below shows how the registry keys look like for the same application when the file type association is registered via the corresponding advertised table.

As you can see, an extra registry value named “command” is added into the registry keys and set to the encoded value of the corresponding Product Code, Feature Name, and Component ID.

Conclusion

In most cases, if you use the self-healing mechanism in your environment, advertised shortcuts should be enough to trigger it.

However, there are some scenarios when there is no shortcut for the package or the users do not really use the shortcuts (and therefore the self-healing mechanism doesn't get triggered). If this is the case for you, then you can use the other entry points, like file extensions, to trigger self-healing.

I hope you found this article useful and that it shed some light on how the self-healing mechanism works when triggered using a file extension entry point.