Update process is is very slow with Microsoft Security Essentials.Because scan speed for maintenanceservice_installer.exe is very slow

RESOLVED FIXED in mozilla33

Status

()

Toolkit
Application Update
RESOLVED FIXED
6 years ago
4 years ago

People

(Reporter: Alice0775 White, Assigned: bbondy)

Tracking

({perf})

unspecified
mozilla33
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 5 obsolete attachments)

(Reporter)

Description

6 years ago
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
(Reporter)

Updated

6 years ago
Blocks: 481815
(Assignee)

Comment 1

6 years ago
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
(Assignee)

Comment 2

6 years ago
Also do you see this problem with both partial updates and full updates?

Thanks for the info!
(Reporter)

Comment 3

6 years ago
(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.
(Reporter)

Comment 4

6 years ago
(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...
(Assignee)

Comment 6

6 years ago
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.
(Reporter)

Comment 7

6 years ago
(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.
(Reporter)

Comment 8

6 years ago
>> 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)
(Assignee)

Comment 9

6 years ago
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.
(Assignee)

Comment 11

6 years ago
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.
(Assignee)

Comment 13

6 years ago
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.
(Assignee)

Comment 14

6 years ago
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.
(Assignee)

Comment 16

6 years ago
Created attachment 644059 [details] [diff] [review]
Patch v1.

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.
(Assignee)

Comment 17

6 years ago
Created attachment 644061 [details]
Fixed installer file

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.
(Assignee)

Comment 18

6 years ago
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?
(Assignee)

Comment 20

6 years ago
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
(Assignee)

Comment 21

6 years ago
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.
(Assignee)

Comment 23

6 years ago
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.
(Assignee)

Comment 24

6 years ago
Created attachment 644092 [details] [diff] [review]
Patch v2

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.
Assignee: nobody → netzen
Attachment #644059 - Attachment is obsolete: true
Attachment #644061 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #644092 - Flags: review?(robert.bugzilla)
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+
(Assignee)

Comment 26

6 years ago
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.
(Assignee)

Comment 27

6 years ago
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.
(Assignee)

Comment 28

6 years ago
Created attachment 644320 [details]
Double clicking maintenanceservice_installler.exe image

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).
(Assignee)

Updated

6 years ago
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.
(Assignee)

Comment 30

6 years ago
K thanks, will make sure nothing breaks on oak before pushing out and will file a follow up for making it look nicer.
(Assignee)

Comment 31

6 years ago
Created attachment 644670 [details] [diff] [review]
Patch v3.

Updated an xpcshell test to pass /S to maintenanceservice_installer.exe. Carrying forward r+.
Attachment #644092 - Attachment is obsolete: true
Attachment #644670 - Flags: review+
(Assignee)

Comment 32

6 years ago
Created attachment 644755 [details] [diff] [review]
Patch v4.

Forgot to increase array size from 0 to 1 in Patch v3.
Attachment #644670 - Attachment is obsolete: true
Attachment #644755 - Flags: review+
(Assignee)

Comment 33

6 years ago
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.
Attachment #644755 - Flags: review+

Updated

5 years ago
Keywords: perf

Comment 34

5 years ago
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.
(Assignee)

Comment 35

5 years ago
It sounds like there is a hung firefox process that you need to kill causing the updates to fail.

Comment 36

5 years ago
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.
(Assignee)

Comment 37

5 years ago
Could you attach a zip of your all users app data Mozilla/logs folder?
%programdata%\Mozilla\logs

Comment 38

5 years ago
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
(Assignee)

Comment 39

5 years ago
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.
(Assignee)

Comment 40

5 years ago
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.

Comment 41

5 years ago
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.

Comment 42

5 years ago
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.

Comment 43

5 years ago
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.

Comment 44

5 years ago
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.
(Reporter)

Comment 45

5 years ago
(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.

Comment 46

5 years ago
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.
(Assignee)

Comment 47

4 years ago
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.
(Assignee)

Comment 48

4 years ago
Created attachment 8440359 [details] [diff] [review]
Patch v5.

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 #644755 - Attachment is obsolete: true
Attachment #8440359 - Flags: review?(robert.strong.bugs)
Attachment #8440359 - Flags: review?(robert.strong.bugs) → review+
(Assignee)

Comment 49

4 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/5f1041f40876
Target Milestone: --- → mozilla33
https://hg.mozilla.org/mozilla-central/rev/5f1041f40876
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.