1683425 - RegisterDLL may fail for some DLLs if MSVC runtime is not available

Status: NEW

(Firefox :: Installer, defect)

Description

[(No longer employed by Mozilla) Aaron Klotz]

I noticed this while installing a test build on a clean Windows 7 VM. If you look at the installation log, AccessibleMarshal.dll fails to register.

This is because the aforementioned DLL dynamically links to the MSVC runtime. If the runtime is not installed globally for the entire machine, then the Windows loader needs to be able to locate the MSVC runtime DLLs that we copied along with our Firefox installation.

Fixing this could be as simple as changing the cwd to the Firefox installation directory prior to registering the DLLs. Another option could be adding the Firefox installation directory to the PATH before starting regsvr32.

Now, the Real Correct Fix (TM) is for us to stop shipping the individual MSVC and UCRT DLLs in our Program Files directory, and instead use the MSVC redistributable installer to ensure that these libraries are installed machine-wide. This would offer several benefits:

• We would no longer be on the hook for updating MSVC DLLs if they have any bugs or security vulnerabilities; that burden would get to fall onto Windows Update. (Let's be honest, I don't think we stay on top of this with respect to releng!)
• We could do things like add smarts to the stub installer make it check for the redist package's presence and not even bother downloading the CRT if it's already present on the machine, thus reducing the amount of data we need to download and install;
• We currently install a few DLLs on the machine that do contain a statically-linked CRT because of concerns around machine-wide availability. If we actually fixed this right, then we could stop doing this static linking, eliminate that gross redundancy, and save even more space in our installation.

I suppose the ugliest mitigation is to statically link the CRT into these other DLLs that don't have it, but that's just gross.

Comment 1

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

I'm curious how you were running the installer that this showed up. I reproduced it when installing with the stub installer, but not when directly using the 84.0.1 full installer, which made me wonder whether the issue was related to the full installer not having elevated itself. Running the full installer directly from an administrator command prompt also causes the failure. So I suspect the elevation is involved here somehow. I added a log entry to record the working directory, it records the install directory in both success and failure cases. I'll poke around a bit more, but I'm not sure what's going on here.

I agree it's worth looking into using the redistributable installer, but that might want to be a separate bug.