Closed Bug 775458 Opened 9 years ago Closed 7 years ago
Update process is is very slow with Microsoft Security Essentials
.Because scan speed for maintenanceservice _installer .exe is very slow
With Security Essentials Version: 4.0.1526.0 *Update browser from Help > About Firefox is very slow. *The scan of the zip file(down load from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/) halts for a while at maintenanceservice_installer.exe
By zip file you mean MAR file? maintenanceservice_installer.exe is only 189KB, relatively small compared to the other binaries in that zip. Perhaps this problem is when upacking the MAR and not downloading the MAR? Otherwise I'm not sure how it would know what's contained in our custom MAR format. Do any other files take a long time to scan? For example: xul.dll? or if it only scans .exes how about firefox.exe?
Component: General → Application Update
Product: Firefox → Toolkit
Also do you see this problem with both partial updates and full updates? Thanks for the info!
(In reply to Brian R. Bondy [:bbondy] from comment #2) > Also do you see this problem with both partial updates and full updates? > > Thanks for the info! both.
(In reply to Brian R. Bondy [:bbondy] from comment #1) > By zip file you mean MAR file? > No. firefox-17.0a1.en-US.win32.zip > maintenanceservice_installer.exe is only 189KB, relatively small compared to > the other binaries in that zip. > > Perhaps this problem is when upacking the MAR and not downloading the MAR? It takes about 40sec to restart browser after I click "Restart to Update" button. > Otherwise I'm not sure how it would know what's contained in our custom MAR > format. > > Do any other files take a long time to scan? For example: xul.dll? or if it > only scans .exes how about firefox.exe? The scan is completed instantly, except maintenanceservice_installer.exe
I see the same hang when installing an .exe Uninstall Firefox via add/remove programs Win7 x64 After downloading the .exe installer run the installer During the extraction phase the install will stall at about 4-5% mark for several seconds After that hang the extraction completes fairly quickly Go through all the prompts for a normal install The install progress meter will go to about 1/2 done and stall again, sometimes for upwards of 20+ seconds, then finally complete. Going to the downloaded .exe installer and using MSE to just scan that file, will show the hang during the manual-scan on the maintinstaller...
Some questions for rstrong: Is this something we should contact MS about? Do you have any ideas on why it might be happening? I'm confused why a zip is being downloaded from help | about too from Comment 0.
(In reply to Brian R. Bondy [:bbondy] from comment #6) > Some questions for rstrong: > > Is this something we should contact MS about? May be not. > Do you have any ideas on why > it might be happening? May be maintenanceservice_installer.exe is not signed, and contains something similar to malware code. > I'm confused why a zip is being downloaded from help > | about too from Comment 0. No, I do not say that. Update is slow. Scanning zip file is also slow.
>> Do you have any ideas on why >> it might be happening? >>May be maintenanceservice_installer.exe is not signed, and contains something similar to malware code. please ignore this.(sorry)
It is signed in the same way as the other binaries. One difference about this file is that it has a manifest to be started with administrative privs. Whereas the other installers will do this with a UAC plugin after it is started. It doesn't actually contain any binaries, it just installs them from the local directory. It does contain some plugin code, but I think that's in the normal installer too. We could try changing the way UAC is elevated.
(In reply to Brian R. Bondy [:bbondy] from comment #6) > Some questions for rstrong: > > Is this something we should contact MS about? If you think it will help, definitely. There really isn't much different between it and helper.exe so it would be good to verify that this doesn't also happen with helper.exe. > Do you have any ideas on why > it might be happening? Not really unless it also happens with other helper.exe which doesn't seem to be the case. Checking if it happens when it isn't set to elevate would be a good thing since it may see that and the scanning software might be doing something different.
I can reproduce the slow scan by right clicking on a nightly zip and selecting to scan with Microsoft Security Essentials. I also noticed when extracting this zip that if the "Use Real time protection" checkbox is on (and on is the default), then it pauses for a few seconds on maintenanceservice_installer.exe when extracting. As soon as I disable real time protection it extracts right away. helper.exe also has the embedded manifest to run elevated as rstrong said, and I cannot reproduce with helper.exe. So I suspect some other aspect of maintenanceservice_installer.exe is triggering a more thorough scan.
(In reply to Brian R. Bondy [:bbondy] from comment #11) > I can reproduce the slow scan by right clicking on a nightly zip and > selecting to scan with Microsoft Security Essentials. > > I also noticed when extracting this zip that if the "Use Real time > protection" checkbox is on (and on is the default), then it pauses for a few > seconds on maintenanceservice_installer.exe when extracting. > > As soon as I disable real time protection it extracts right away. > helper.exe also has the embedded manifest to run elevated as rstrong said, > and I cannot reproduce with helper.exe. I didn't actually say that... it is set to asInvoker. I was curious whether it was also affected to rule out whether it was Microsoft Security Essentials handling of NSIS files and this data point makes me wonder if it is due to it being set to run as admin.
oh! ok cool. I just double clicked on helper.exe and it prompted me to elevate so I thought it was an embedded manifest. I bet that's it, I'll try repacking an asInvoker exe for the same installer to see.
Packaging a maintenanceservice_installer.exe with RequestExecutionLevel user instead of admin has the same delay. I'll keep trying things.
I wonder how it would behave if it had a different name. MS has used file names in the past to perform different actions (e.g. update, install, or setup in a file name would cause an elevation request on Win Vista). Another thing to check would be to compile it with sections of code removed to see if the problem goes away.
So by code removal a'la binary-search I found the problem to be exactly with nsExec::Exec calls. Even if maintenanceservice_installer.exe simply has a single line inside the main section with nsExec::Exec I can reproduce the slow scan. I have a fix, but I don't like this fix. I'd rather hold out for a better fix before asking for a review. The downside of this patch is when it executes the applications inside it has a dos prompt flash up.
If you want to see it working, you can just unpack your zip and replace maintenanceservice_installer.exe with this one. Then re-zip and scan. You'll see a fast scan.
The only difference is replacing nsExec::Exec with ExecWait. But as mentioned we need to find another solution that won't flash a dos screen.
There are nsExec::Exec calls in the uninstaller (e.g. helper.exe). Any idea why one is affected and not the other?
I noticed the other calls too but I can't explain it yet. I'm still investigating by the way. The simple switch from nsExec::Exec to ExecWait does fix the problem though :S
I found an alternate way to fix this simply by removing this from the Function .onInit > SetSilent silent So it seems that something is triggered in MS security essentials for silent NSIS installers that use nsExec::Exec.
I could see them doing that. I wonder what getting rid of that and just not displaying ui would do.
You can't get rid of the progress bar part even if you have no PAGE definitions. What we can do to fix this is remove the silent call and then whenever we execute it we would execute maintenanceservice_installer.exe /S instead.
So this fixes the bug, the only side effect is if someone double clicks manually on maintenanceservice_installer.exe it'll show an install progress bar and then a close button when it's done. There is also no header image. But we don't document anywhere that a user should do this that I know of so I think it's ok. If you want this approach, I'll test on oak before pushing.
Comment on attachment 644092 [details] [diff] [review] Patch v2 I suspect you could go with either moving the install into .oninit or a pre function for the first page and just exit prior to the installer to get rid of the "install progress bar and then a close button". This will still be needed if you do that so r+ for this.
Attachment #644092 - Flags: review?(robert.bugzilla) → review+
I tried moving all of the main section code intio the init function but when I start the installer it will show a progress bar at 0% with a close button. It's better with the code inside the section where it will show the progress bar going across and then the close button. Also when the nsExec::Exec call happens in the init function I can reproduce the original issue which was a several second slow scan.
Actually sorry I did get it to work silently by appending an Abort at the end of the init. But as mentioned in Comment 26 the slow scan happens when I do this. It seems MS security essentials is smart enough to detect a hidden window while a call to nsExec::Exec is made.
Attached what it looks like when you double click on the maintenanceservice_installer. Please let me know if it's ok to land that way. By the way even when nsis generates the file, I can tell it will be slow. So I can see why updates are slow too, if the content of a hidden program that calls nsExec::Exec is written to disk or read from disk, it lags for several seconds (3-10sec).
Attachment #644320 - Attachment description: Double clicking maintenanceservice_installler.exe → Double clicking maintenanceservice_installler.exe image
It is ok to land as is... would be nice to clean that up someday but not as part of this bug. Please file a new bug for this.
K thanks, will make sure nothing breaks on oak before pushing out and will file a follow up for making it look nicer.
Updated an xpcshell test to pass /S to maintenanceservice_installer.exe. Carrying forward r+.
Forgot to increase array size from 0 to 1 in Patch v3.
Comment on attachment 644755 [details] [diff] [review] Patch v4. Cancelling review for now. The problem with the current method is that the currently installed service executes the new maintenanceservice_installer.exe after it does an update. This is problematic because /S will not be passed in that case. The update after that will pass /S though, but the first one needs a way to be silent too.
Possibly related: Bug 768278 "update could not be installed Please make sure there are no other copies of Firefox running on your computer" I get failed updates about 20% of the time, using Beta, Aurora & Nightly, running on WinXP with a somewhat slow processor. I suspect the new updater is contending with MSSE. Retrying the update does not work. Unlocking either the application exe or plugin-container.exe fixes it.
It sounds like there is a hung firefox process that you need to kill causing the updates to fail.
Nope, the file is locked by System. There is no Firefox or Plugin-container process active. The install error log explains what happened. Using a 3rd party utility called Unlocker I can fix it. Restarting the computer works too. I don't think I'm the only person stuck in this endless "Cannot update" loop, but I may be one of the few who knows how to get out of it.
Could you attach a zip of your all users app data Mozilla/logs folder? %programdata%\Mozilla\logs
I don't have that path. I do have some "Crash Reports/InstallTime\d+" files but I don't have permission to attach file here. The list of the most recent ones and their contents: firefox-aurora InstallTime20120923030601: 1348447717 InstallTime20120923042010: 1348443667 InstallTime20120924030626: 1348609054 InstallTime20120924042009: 1348564824 InstallTime20120925030547: 1348651283 InstallTime20120925042009: 1348651231 InstallTime20120926042010: 1348677702 seamonkey-beta InstallTime20120830225246: 1346592378 InstallTime20120906034402: 1347336909 InstallTime20120912204827: 1348051147 InstallTime20120923003628: 1348651879 I also have one "updates/0/update.log" that I saved before the next successful update erased it. Here it is: SOURCE DIRECTORY C:\Documents and Settings\(user)\Local Settings\Application Data\Mozilla\Firefox\Aurora\updates\0 DESTINATION DIRECTORY C:\Program Files\Aurora NS_main: callback app open attempt 1 failed. File: C:\Program Files\Aurora\firefox.exe. Last error: 32 NS_main: callback app open attempt 2 failed. File: C:\Program Files\Aurora\firefox.exe. Last error: 32 NS_main: callback app open attempt 3 failed. File: C:\Program Files\Aurora\firefox.exe. Last error: 32 NS_main: callback app open attempt 4 failed. File: C:\Program Files\Aurora\firefox.exe. Last error: 32 NS_main: callback app open attempt 5 failed. File: C:\Program Files\Aurora\firefox.exe. Last error: 32 NS_main: callback app open attempt 6 failed. File: C:\Program Files\Aurora\firefox.exe. Last error: 32 NS_main: callback app open attempt 7 failed. File: C:\Program Files\Aurora\firefox.exe. Last error: 32 NS_main: callback app open attempt 8 failed. File: C:\Program Files\Aurora\firefox.exe. Last error: 32 NS_main: callback app open attempt 9 failed. File: C:\Program Files\Aurora\firefox.exe. Last error: 32 NS_main: callback app open attempt 10 failed. File: C:\Program Files\Aurora\firefox.exe. Last error: 32 NS_main: file in use - failed to exclusively open executable file: C:\Program Files\Aurora\firefox.exe
I'm going to triage you over to bug 794160, that matches your issue but this bug is for a different issue that doesn't match the log you sent in Comment 38.
Both reporters in this bug have Microsoft security essentials installed. It may be that because of the slow scan in bug 794160 Microsoft security essentials keeps the a hold on firefox.exe for longer.
My updates are also slow and I do have Microsoft Security Essentials installed, but my updates do not fail as in bug 794160. They all complete, they just take a long time to install the necessary files and get the button to restart Firefox.
Maybe the lock by system in WinXP is a bug in Microsoft Security Essentials. The utility I use is happy to unlock the exe (firefox.exe or seamonkey.exe, or sometimes plugin-container.exe), and does not suggest going to the next level of killing a process or thread. Or maybe that is just because it is a lock by system. One more fact: Seamonkey opens with a Safe Mode modal window when I start it after unlocking the exe.
It can also be maintenanceservice.exe or maintenanceservice_installer.exe (I forgot to write down which one). To find the file with the System handle lock I used unlocker.exe ( http://www.emptyloop.com/unlocker/ though ver 1.1.8). Using Aurora 20 in WinXP with MSE, on slow hardware.
Aurora cannot apply the update. Screenshot here shows plugin-container.exe locked by the System process in WinXP on slow hardware. PID is 4. I should probably be commenting on Bug 768278 but that one is *still* listed as Unconfirmed. I get this update problem about once a week, either in Aurora 20, Nightly 21, Seamonkey beta, or Thunderbird release. Besides MSE, I have some suspicions about PC Tools Firewall Plus, which tracks changes in executables. Would be interested if other affected MSE users also have that firewall.
(In reply to kitchin from comment #44) > Created attachment 713976 [details] > Screenshot of locked plugin-container.exe > > Aurora cannot apply the update. Screenshot here shows plugin-container.exe > locked by the System process in WinXP on slow hardware. PID is 4. I should > probably be commenting on Bug 768278 but that one is *still* listed as > Unconfirmed. I get this update problem about once a week, either in Aurora > 20, Nightly 21, Seamonkey beta, or Thunderbird release. > > Besides MSE, I have some suspicions about PC Tools Firewall Plus, which > tracks changes in executables. Would be interested if other affected MSE > users also have that firewall. Different problem. please file a new bug.
I should have commented on the open Bug 794160 - "REOPENED: Update after restart failed, error said Firefox was still running." Its likely dup is Bug 768278 - "UNCONFIRMED - update could not be installed Please make sure there are no other copies of Firefox running on your computer." Only people with Microsoft Security Essentials are affected, as far as we know, which is the connection to this bug.
Now that we don't execute the maintenance service installer on updates, I think we can land this. I'll take a look at the patch and problem again.
I found a good solution to this with no side effects. This patch uses ExecWait which doesn't have the problem of picky windows defender. To get around the dos prompt popup from ExecWait which nsExec::Exec supresses, I set the windows subsystem linker option on the thing that was being executed (maintenanceservice). I noticed with the old patch that it no longer worked by the way, due to the SetDllDirectory, which we don't want to remove. I verified w/ Windows Security Essentials on Win7 and the newer Windows Defender on Win8. This saves up to a few seconds each time the data of maintenanceservice_installer.exe is written to disk. So that's on installs, on some partial updates, and all full updates.
Attachment #8440359 - Flags: review?(robert.strong.bugs) → review+
Target Milestone: --- → mozilla33
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.