Why do I need to keep “$hf_mig$”?

Question

After having read the Microsoft's explanation and also some others, I still don't get it:

When a security update, critical update, update, update rollup, driver, or feature pack installs GDR version files, the hotfix files are also copied to the %windir%\$hf_mig$ folder. This supports migration to the appropriate files if you later install a hotfix or service pack that includes earlier versions of these files. For example, consider the following scenario:

You apply a security update that installs a GDR version of File.dll with a version number of 5.2.3790.1000 and copies a hotfix version of File.dll with a version number of 5.2.3790.1000 to the %windir%\$hf_mig$ folder.

You apply a hotfix that includes a hotfix version of File.dll with a version number of 5.2.3790.0000.

In this scenario the hotfix installation in step 2 installs the hotfix version of File.dll (version number 5.2.3790.1000) from the %windir%\$hf_mig$ folder instead of the hotfix version of File.dll (version number 5.2.3790.0000) from the hotfix package.

I don't get it. Why not this way:

• You apply the first thing containing the version 5.2.3790.1000, the old version gets replaced.
• You apply the second thing containing the version 5.2.3790.0000, the updater finds out that your version is newer and leaves the file alone.

The advantages are obvious, so am I misunderstanding it?

Answer 1

• Not every feature is installed at once. A patch may deliver an updated file.dll that nothing is using. You later install a feature using file.dll and you get the latest version that the system can provide -- which isn't necessarily the one on the installation media.
• You remove a feature. file.dll gets removed from %systemroot%\system32. You later reinstall the feature (or another program/feature that requires file.dll). If you didn't have the cached version in $hf_mig$, you'd have an insecure or unstable version of file.dll. If you're especially unlucky, it got installed via some method that prevents Windows Update from correctly noticing the old file version.
• Patches were often delivered for different SP levels at once. If you weren't running the latest service pack, installing the service pack would install older versions of file.dll without the cached versions in $hf_mig$. Or say you need to uninstall a SP -- you'll get rolled back to the latest versions available in $hf_mig$ rather than whatever was delivered with SP2 (vs. SP3), which will minimize the number of updates you'll have to re-download via Windows Update.
• IIRC, this can also be used to track non-versioned files and make sure they're as up to date as possible.

Basically, it's used in scenarios where Windows features, patches, and service packs are added on and removed after initial system installation and updating. If all you ever do is install Windows, go to Add/Remove Features right afterwards once, and only ever add updates to your system, it might not make a lot of sense. For everyone else who might have occasion to roll back a bad patch, uninstall a misbehaving SP, or add a feature to Windows much later in a system's lifecycle, it's a necessity for making sure that the latest versions of files can be delivered as soon as possible rather than requiring a user to re-run Windows update after every minor system change.