1628924 - default-browser-agent.exe fails with missing VCRUNTIME140.DLL on uninstall

Status: RESOLVED FIXED

(Firefox :: Installer, defect, P1)

Description

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

On a stock Windows 10 install, there will be two error messages when uninstalling due to a missing runtime, this is installed with Firefox but not present globally in a stock install.

default-browser-agent.exe - System Error
The code execution cannot proceed because VCRUNTIME140.DLL was not found. Reinstalling the program may fix this error.

and another for MSVCP140.dll. Thus the scheduled task isn't uninstalled.

This may be because we run the program and then proceed with the uninstall without waiting for it to finish; by the time the EXE has started the DLLs could be gone. This might be fixed by bug 1626887, which changes this to ExecWait.

Alternately there might be something odd about the working directory?

Comment 1

[Molly Howell (she/her) (mostly inactive)]

I'm not immediately able to reproduce this on a clean Win10 install (I did verify that there is no other copy of VCRUNTIME140.dll), which suggests it is indeed a timing thing; we must be deleting the DLL before the agent process tries to load it. I also checked that the working directory (and thus the DLL search path) is correct; the first place that it looks really is the right place.

So, without being able to reproduce the bug, I am as sure as I can be that bug 1626887 has (accidentally) fixed it.

Adam, now that bug 1626887 is on central, can you still repro this? If not I'll call it fixed.

Comment 2

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

I misremembered, bug 1626887 adds ~ExecWait on register, not unregister. I did try 20200410095419 (first release with) but no luck.

It's probably timing- and cache-sensitive, when I was checking Nightly 20200409131623 I couldn't reproduce it until I unchecked the box to run Nightly after the install, so perhaps running Nightly gets the DLL lookup cached so they can be found and linked before the uninstall removes them (though default-browser-agent.exe had already run to register the task, so why wouldn't that be sufficient?). It isn't only about not running the browser, though; I first spotted this after uninstalling a normal stub-driven install of current release 75, which automatically launches Firefox.

My testing has all been on a single-core VM (64-bit Windows 10 Home 1909 on Hyper-V), so that might sufficiently slow things down to make it easier to hit.

Comment 3

[Molly Howell (she/her) (mostly inactive)]

(In reply to Adam Gashlin (he/him) [:agashlin] from comment #2)

I misremembered, bug 1626887 adds ~ExecWait on register, not unregister.

'Doh.

My testing has all been on a single-core VM (64-bit Windows 10 Home 1909 on Hyper-V), so that might sufficiently slow things down to make it easier to hit.

After switching my VM to also be single-core, I can now reproduce this consistently, and based on that I can confirm that switching to ExecWait solves the problem. I'll go ahead and put up a patch that does that.

Comment 4

[Molly Howell (she/her) (mostly inactive)]

Attachment: Bug 1628924 - Wait for the default browser agent to finish unregistering before deleting it. r=agashlin

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a09288e4e3c6
Wait for the default browser agent to finish unregistering before deleting it. r=agashlin

Comment 6

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/a09288e4e3c6

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:mhowell, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment 8

[Molly Howell (she/her) (mostly inactive)]

Comment on attachment 9139872 [details]
Bug 1628924 - Wait for the default browser agent to finish unregistering before deleting it. r=agashlin

Beta/Release Uplift Approval Request

• User impact if declined: Default browser agent task may not be unregistered and error messages may appear during uninstall, depending on system conditions.
  The agent executable file is correctly deleted when this happens, so the task will not actually continue running even though it is still registered. The error messages are really the bigger problem.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This patch converts unregistering the default browser agent to a synchronous operation, so it could harm uninstall performance, but in testing the difference was not noticeable.
• String changes made/needed:

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9139872 [details]
Bug 1628924 - Wait for the default browser agent to finish unregistering before deleting it. r=agashlin

Approved for 76.0b5.

Comment 10

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/releases/mozilla-beta/rev/d6359ee17150