Closed Bug 522436 Opened 15 years ago Closed 14 years ago

Minefield Software Updater keeps crashing under Windows 7 after restart

Categories

(Toolkit :: Application Update, defect)

Product:
Toolkit
Component:
Application Update
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: a.eibach, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091014 Minefield/3.7a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091014 Minefield/3.7a1pre

This is the 7th time in 2 weeks that Minefield Software Updater crashed here.
I'm wondering whether I'm not the only one?


Reproducible: Always

Steps to Reproduce:
0. Precondition: Use a nightly build which is more than 1 day old.
1. Select Help->Check For Updates.
2. (You should get an update suggestion.)
3. Follow this suggestion, download update and select "Restart Minefield".
Actual Results:  
Software updater crashes. (General Protection Fault)

Expected Results:  
This should not happen.
Version: unspecified → Trunk
Ah. Maybe I should add that you will have to install Minefield via Internet Explorer, because of course the browser is erased from your HDD then at this stage ;-)
Sounds like bug 522190 except there is no mention of the updater crashing. Do you have the same result (0-byte files)?
Component: Microsummaries → Application Update
Product: Firefox → Toolkit
QA Contact: microsummaries → application.update
Well, I've updated again, no problems.

My issue seems related to _full_ updates only; that is, if you haven't updated for some days and the Updater detects this and forces a 10 MB full download. THEN this happens. (As you all know, size of day-to-day updates is roughly 2.5 MB).
It is doubtful this is related to bug 522190

Andreas, I've been running nightly updates on Win7 for several months without seeing this. Could you check the Windows event log in case there is a clue there as to the cause. Also, are you running any anti-virus or other software which might be interfering with the update?
No. Of course antivirus was deactivated every time I updated.
So, you manually deactivated your antivirus? This shouldn't be necessary so I am curious as to why you deactivated it? Was it causing problems with updating when it was activated?
No, I did it just to be on the safe shore, but if it works without, I'll be glad :)

But wasn't it you too to write "which might be interfering with the update"?:)
So you DID assume problems caused by antivirus, didn't you?
And then you added "this shouldn't be necessary".

Sometimes you seem to make one statement, and contradict it with the follow-up statement. This rather creates confusion instead of minimizing it...
The last 7 days updating Namoroka crashes mid-way. It leaves firefox in a broken state. I've deleted the mozbackup and update files and tried again. And on different days I replaced my firefox directory with a fresh nightly ZIP. It still crashes.
I'm using Win7 and tried WinVista compatibility to no avail.

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2b2pre) Gecko/20091103 Namoroka/3.6b2pre ID:20091103045100
Can you try using an installer build in case there is a difference with the zip builds? I haven't had any problems updating with an installer build and we have had problems specific to zip builds in the past. Thanks
Ok, works for me now. After some testing it became clear it was a local problem. My plugins folder is a junction and it seems the updater can't patch npnul32.dll.
The update log shows it failed when doing that.
Ah, so the culprit could be the plugins folder?
Thanks Soufian! Yes, I too had to manually intervene here because I absolutely wanted to have the Media Player plugin (since zShare and others use it).
Since it just did not work with the quick'n dirty instructions found in the net, I read about one user on bugzilla here who managed to get it to work (forgot his name, he's Swedish) and followed his instructions.

It's possible that the updater chokes on this.

Soufian, could you please tell me where this update log is to be found and how it is called?
https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg

you can use "windbg -I" to setup windbg to catch random crashes just-in-time.
(In reply to comment #7)
> No, I did it just to be on the safe shore, but if it works without, I'll be
> glad :)
> 
> But wasn't it you too to write "which might be interfering with the update"?:)
> So you DID assume problems caused by antivirus, didn't you?
> And then you added "this shouldn't be necessary".
> 
> Sometimes you seem to make one statement, and contradict it with the follow-up
> statement. This rather creates confusion instead of minimizing it...
Plain and simple... I stated that because often times people don't provide details as to other problems they are experiencing and I wanted info as to why you would disable your antivirus before being asked to disable it and try again.

If you could attach the following files last-update.log in the updates directory, the backup-update.log if present in the updates directory, and the update.log in the updates/0 directory if present it might shed additional light as to what is happening. The following page provides info on where to find these directories.
http://kb.mozillazine.org/Software_Update
Please update if you are able to still reproduce the issue. Please attach the last-update.log and backup-update.log if present located in
%LOCALAPPDATA%\Mozilla\Firefox\Mozilla Firefox\updates and update.log in updates directory.
this is equivalent to
C:\Users\<username>\AppData\Local\Mozilla\Firefox\Minefield\updates
Whiteboard: [closeme 2010-05-28]
No reply to comment #14 or comment #15 so resolving -> incomplete.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [closeme 2010-05-28]
You need to log in before you can comment on or make changes to this bug.