Closed Bug 310688 Opened 19 years ago Closed 19 years ago

Firefox gets an exception during initialization which prevents the load of the UI

Categories

(Firefox :: General, defect)

x86
Windows XP
defect
Not set
blocker

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: bugs.caleb, Unassigned)

Details

(Keywords: regression, smoketest)

This seems to happen with the 01/10/2005 nightly build.

When you start Firefox the UI will not show up but the process will be listed in
the Task Manager.
If I delete my current profile and start it again, it creates a new profile, but
still doesn't show any UI.

Running Dependency Walker showed this: (A couple last lines from the log)
00:00:04.140: LoadLibraryA("uxtheme.dll") returned 0x5AD70000.
00:00:04.172: GetProcAddress(0x5AD70000 [UXTHEME.DLL], "OpenThemeData") called
from "FIREFOX.EXE" at address 0x00504D67 and returned 0x5AD77CB8.
00:00:04.172: GetProcAddress(0x5AD70000 [UXTHEME.DLL], "CloseThemeData") called
from "FIREFOX.EXE" at address 0x00504D76 and returned 0x5AD74940.
00:00:04.172: GetProcAddress(0x5AD70000 [UXTHEME.DLL], "DrawThemeBackground")
called from "FIREFOX.EXE" at address 0x00504D85 and returned 0x5AD72C28.
00:00:04.172: GetProcAddress(0x5AD70000 [UXTHEME.DLL],
"GetThemeBackgroundContentRect") called from "FIREFOX.EXE" at address 0x00504D94
and returned 0x5AD73F9F.
00:00:04.187: GetProcAddress(0x5AD70000 [UXTHEME.DLL], "GetThemePartSize")
called from "FIREFOX.EXE" at address 0x00504DA3 and returned 0x5AD74456.
00:00:04.187: GetProcAddress(0x5AD70000 [UXTHEME.DLL], "GetThemeSysFont") called
from "FIREFOX.EXE" at address 0x00504DB2 and returned 0x5AD9C8A9.
00:00:04.187: GetProcAddress(0x5AD70000 [UXTHEME.DLL], "GetThemeColor") called
from "FIREFOX.EXE" at address 0x00504DC1 and returned 0x5AD7476A.
00:00:04.203: First chance exception 0xC0000005 (Access Violation) occurred in
"FIREFOX.EXE" at address 0x0059FD0A.


Full log will be attached next.
Looks like my bug 310686 is a duplicate of this one, but under MacOS-X Tiger.

:(
It starts here, this one: 1.9a1_2005100106.
(In reply to comment #0)
> This seems to happen with the 01/10/2005 nightly build.
> 
> When you start Firefox the UI will not show up but the process will be listed in
> the Task Manager.
> If I delete my current profile and start it again, it creates a new profile, but
> still doesn't show any UI.
> 
> Running Dependency Walker showed this: (A couple last lines from the log)
> 00:00:04.140: LoadLibraryA("uxtheme.dll") returned 0x5AD70000.
> 00:00:04.172: GetProcAddress(0x5AD70000 [UXTHEME.DLL], "OpenThemeData") called
> from "FIREFOX.EXE" at address 0x00504D67 and returned 0x5AD77CB8.
> 00:00:04.172: GetProcAddress(0x5AD70000 [UXTHEME.DLL], "CloseThemeData") called
> from "FIREFOX.EXE" at address 0x00504D76 and returned 0x5AD74940.
> 00:00:04.172: GetProcAddress(0x5AD70000 [UXTHEME.DLL], "DrawThemeBackground")
> called from "FIREFOX.EXE" at address 0x00504D85 and returned 0x5AD72C28.
> 00:00:04.172: GetProcAddress(0x5AD70000 [UXTHEME.DLL],
> "GetThemeBackgroundContentRect") called from "FIREFOX.EXE" at address 0x00504D94
> and returned 0x5AD73F9F.
> 00:00:04.187: GetProcAddress(0x5AD70000 [UXTHEME.DLL], "GetThemePartSize")
> called from "FIREFOX.EXE" at address 0x00504DA3 and returned 0x5AD74456.
> 00:00:04.187: GetProcAddress(0x5AD70000 [UXTHEME.DLL], "GetThemeSysFont") called
> from "FIREFOX.EXE" at address 0x00504DB2 and returned 0x5AD9C8A9.
> 00:00:04.187: GetProcAddress(0x5AD70000 [UXTHEME.DLL], "GetThemeColor") called
> from "FIREFOX.EXE" at address 0x00504DC1 and returned 0x5AD7476A.
> 00:00:04.203: First chance exception 0xC0000005 (Access Violation) occurred in
> "FIREFOX.EXE" at address 0x0059FD0A.
> 
> 
> Full log will be attached next.


I've got it here too:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051001
Firefox/1.6a1 - Build ID: 2005100106
I can't attach the full compressed log because it's 700KB and Bugzilla doesn't
allow binary files over 300KB.
Firefox will start neither in safe mode or opening profile manager.
No specific error from Windows, but the process stayed and listed in Task Manager.
I have to manually kill the exe.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051001
Firefox/1.6a1 ID:2005100108

Also this one is running without any problems here so this is quite weird.
What is more weird, there were no checkins between 2005100106 and 2005100108
builds, as far as I can see on Checkins for both core and firefox.
I got it on branch 2005100107 build after auto-update.
I can reproduce this bug with the latest Firefox and Thunderbird branch nightly
on Windows (the branch builds on linux work fine). Requesting blocking1.8b5...
Flags: blocking1.8b5?
Flags: blocking1.8b5? → blocking1.8b5+
Keywords: smoketest
Is anyone besides Nickolay seeing this with an 10/01 BRANCH build? 
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051001 Firefox/1.6a1
Build ID: 1.9a1: 2005100106

Zip build unzipped in new directory.
Scott: at least two nightly thunderbird testers in the mozillazine Thunderbird
builds forum and a bunch of testers in Firefox builds forum (see Peter's daily
branch thread), but it seems that not everyone can reproduce it. Weird...
WFM Using thunderbird auto update to 10/01 on the branch (Windows). Any of you
seeing this have any extensions bundled? If so, what are they?
I'm also having this problem with the latest nightly (hourly) firefox branch
builds. The only bundled extension I install is the DOM inspector.
It doesn't matter what extensions are installed - Firefox hangs very early in
startup sequence - even before the Profile manager is shown (comment 5).

A number of people can reproduce this on branch -
http://forums.mozillazine.org/viewtopic.php?p=1780200#1780200
Some of the comments on the forum thread indicate there was corrupted update
data on the mirrors, is this confirmed?  Do we have any idea why this happened
(version switch?)  WFM just now going 09/30 -> 10/01
I've just grabbed a recent trunk hourly build (pacifica):
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051001
Firefox/1.6a1 ID:2005100121

It seems to be working fine now.

-> WFM.
See bug 309335... Could be related. Can someone add it in depend list, please ?
2005-09-30-06-mozilla1.8/firefox-1.4.en-US.win32.zip
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20050930 Firefox/1.4
Clean, default profile

Start Firefox -> Help - Check for updates... -> Download & Install Now -> 509 KB
-> (successfully downloaded and verified) -> Restart Firefox Now -> Firefox is
installing your updates and will start in a few moments... -> (ZoneAlarm
Security Alert: Firefox is trying to access the trusted zone, This program has
changed since the last time it ran! -> Allow) -> Firefox doesn't start. There is
firefox.exe process in Windows Task Manager with about half memory resources
than usual with successful start. -> Kill firefox.exe process. -> Start Firefox
-> Same result.

-----

2005-10-01-08-mozilla1.8\firefox-1.4.1.en-US.win32.zip, as well 

firefox-1.4.1.en-US.win32.installer.exe (with default and customs settings as well)
Clean, default profile

Start Firefox -> (ZoneAlarm Security Alert: Firefox is trying to access the
trusted zone -> Allow) -> Firefox doesn't start. There is firefox.exe process in
Windows Task Manager with about half memory resources than usual with successful
start. -> Kill firefox.exe process. -> Start Firefox -> Same result, but updates
directory in firefox folder is created. -> Start Firefox -> Same result.

-----

pacifica-mozilla1.8\firefox-1.4.1.en-US.win32.zip
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b5) Gecko/20051001
Firefox/1.4.1
Start Firefox -> (ZoneAlarm Security Alert: Firefox is trying to access the
trusted zone -> Allow) -> Import Wizard -> Dont Import anything -> Firefox does
start. There is firefox.exe process in Windows Task Manager with usual memery
resources.
The latest build from Oregon mirror starts and works correctly.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051002
Firefox/1.6a1 ID:2005100202
I'm marking as WFM.

No point in arguing over something that is already fixed (there were probably a
few bad builds at the time I downloaded it).

Everything is working fine now, and it should be fine with the next nightly
build, so just wait.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
Flags: blocking1.8b5+
You need to log in before you can comment on or make changes to this bug.