Mozilla exits (or perhaps crashes, though there is no talkback or illegal operation type dialog) immediatly after putting the splash screen up. This happens quickly enough that you can't even really see the spash screen, just an orange blob.
delynxified, that said: Mozilla exits (or perhaps crashes, though there is no talkback or illegal operation type dialog) immediatly after putting the splash screen up. This happens quickly enough that you can't even really see the spash screen, just an orange blob. and this is (according to Daniel on IRC) happening with most recent trunk nightly 20030316...
Crash seen on todays trunk build. Talkback ID: TB18137771M. Setting as smoketest blocker, as I cannot sucessfully complete the smoketests with the presence of this bug. Testing on clean profile, data to come.
Crashes after mozilla -profilemanager is used to create a clean profile.
RDFServiceImpl::GetUnicodeResource [c:/builds/seamonkey/mozilla/rdf/base/src/nsRDFService.cpp, line 1123] xptiInterfaceInfoManager::EnumerateInterfaces [c:/builds/seamonkey/mozilla/xpcom/reflect/xptinfo/src/xptiInterfaceInfoManager.cpp, line 1836] XPCWrappedNative::ToString [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2433] XPCWrappedNativeProto::SystemIsBeingShutDown [c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednativeproto.cpp, line 167] js_Interpret [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 3309] js_Interpret [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 3131] js_Interpret [c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 1590] JS_CallFunction [c:/builds/seamonkey/mozilla/js/src/jsapi.c, line 3400] nsJSContext::CompileEventHandler [c:/builds/seamonkey/mozilla/dom/src/base/nsJSEnvironment.cpp, line 912] nsRange::SurroundContents [c:/builds/seamonkey/mozilla/content/base/src/nsRange.cpp, line 2178] nsRange::SurroundContents [c:/builds/seamonkey/mozilla/content/base/src/nsRange.cpp, line 2151] nsNetModuleMgr::UnregisterModule [c:/builds/seamonkey/mozilla/netwerk/base/src/nsNetModuleMgr.cpp, line 133] nsAboutBloat::NewChannel [c:/builds/seamonkey/mozilla/netwerk/protocol/about/src/nsAboutBloat.cpp, line 152] VR_SetRegDirectory [c:/builds/seamonkey/mozilla/modules/libreg/src/VerReg.c, line 1059] NS_NewInputStreamPump [../../../dist/include/necko\nsNetUtil.h, line 338] NS_ParseContentType [../../../dist/include/necko\nsNetUtil.h, line 698] nsFileSpec::operator= [c:/builds/seamonkey/mozilla/xpcom/io/nsFileSpec.cpp, line 1030] nsRegistry::GetBytesUTF8IntoBuffer [c:/builds/seamonkey/mozilla/xpcom/components/nsRegistry.cpp, line 916] nsRegistry::GetBytesUTF8 [c:/builds/seamonkey/mozilla/xpcom/components/nsRegistry.cpp, line 869] nsRegistry::GetValueLength [c:/builds/seamonkey/mozilla/xpcom/components/nsRegistry.cpp, line 1313] USER32.dll + 0x4455 (0x77d44455) USER32.dll + 0x95d5 (0x77d495d5) nsAppShellService::Quit [c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp, line 623] main1 [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1273] main [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1639] WinMain [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1660] Mozilla.exe + 0x10bc4 (0x00410bc4) kernel32.dll + 0x214c7 (0x77e814c7)
that stack is from talkback. Daniel - what is the exact URL you use to download the bits?
I see this too with this mornings windows zip build. However I do not see the crash with yesterday mornings windows zip build.
possible dup? 197237
if you delete your compreg.dat and xpti.dat the problem goes away. But before you try this and if you can cause this crash, please post both of these files to this bug. given work around - downgrading severity.
http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-installer- sea.exe That said, you're seeing a different bug. The bug I reported does not bring up talkback, and -profilemanager exhibits the same symptoms. Moving compreg.dat and xpti.dat out of the way doesn't help, and there are no differences between the old ones and the new ones mozilla generates before it exits. I suppose it's now a blocker again, but whatever.
I'm seeing this with a CVS build from 2003-03-16-21, but first saw it with a build ~24 hours previous. What's happening here is that in nsGREDirServiceProvider::GetGREDirectoryPath() the line strcpy(szKey, GRE_WIN_REG_LOC GRE_BUILD_ID); is setting szKey to "Software\mozilla.org\GRE\1.4a<CR>_2003031621" where <CR> is a literal CR (ASCII 0xD) This causes the subsequent call to RegOpenKeyEx() to fail. Also, on my machine, there is a Reg key HKLM\software\mozilla.org\1.4a but not HKLM\software\mozilla.org\1.4a_2003031621 Looks like it could be a DOS/Unix EOL issue in the packager Perl scripts? The same build runs fine from dist/bin because xpcom.dll is in the same place as mozilla.exe
yeah, I am definately seeing bug 197237. sorry about the confusion =( dougt: do you still want those compreg.dat and xpti.dat posted in the other bug?
owen - not a duplicated, so I don't need those files. parish - nice detective work. Over to seawood.
Fix for this was checked in last night. (stupid dos line-endings)
Except that I still have the exact same problem with today's build, 20030318. Regmon shows that the query for HKLM\Software\mozilla.org\GRE\1.4a_2003031804 \GreHome succeeds, so it's a different bug. The next query for 0xC1944A60 \C:\PROGRAM FILES\COMMON FILES\MOZILLA.ORG\GRE\1.4A_2003031804\XPCOM looks a little weird to me, and it fails. Mozilla tries this twice, I think. The interesting thing is that I don't have a GRE directory, of if I do it's somewhere else. I also don't have any of the other GREs mentioned in the registry. Is the uninstaller supposed to remove the gre, but not the registry entries?
Daniel: Try uninstalling Moz and then deleting \Program Files\Common Files\mozilla.org which will be left behind (greunistall.exe fails for the same reason Moz won't start). Also delete \Program Files\mozilla.org if it is left behind. > The interesting thing is that I don't have a GRE directory, > of if I do it's somewhere else. This tripped me up at first. GRE has moved from \Program Files\mozilla.org to \Program Files\Common Files\mozilla.org I spun a new build with this fix and it works fine. I've just pulled a new tree and am spinning a new build. I'll see if this is still working.
Might also be worth zapping HKEY_LOCAL_MACHINE\SOFTWARE\mozilla.org\GRE in the registry as well (in fact I zapped the whole of HKEY_LOCAL_MACHINE\SOFTWARE\mozilla.org\ just to be sure), though I'm not sure it is absolutely necessary.
I just nuked everything, and the same thing happens.
today's build works fine for me under winXP. looking for a win98 system now.
Re comment 16: I finally got a new build (kept pulling bad trees) and can confirm that this problem does not exist, at least on XP. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030319 Maybe it is Win9x-specific or something wrong with Daniel's system, although what, I don't know since he's nuked everything.
Just out of curiosity, did you try it with an installer? The zipped version works, so I reckon a regular plain build will too. (zip builds are just a compressed copy of the contents of dist/bin/)
OK, I finally got my tree built, built the SEA installer, installed it, and guess what? I saw this bug :-( Unfortunately, it didn't do anything useful like generate a Talkback, just the "phone home to MS" dialogue. The only thing I could glean from that was that it had caused an Access Violation in xpcom.dll. I confirmed that I had no old (i.e. incompatible) copies of xpcom.dll lying around. If I run it from dist/bin then it works fine (I'm using it now), which explains why Daniel got the ZIP build to run. The only difference I can spot is that when run from dist/bin xpcom.dll is in the same directory as mozilla.exe but in the installed version xpcom.dll is in \Program Files\Common Files\mozilla.org\GRE\<buildID> OK, I'll respin it as a debug build and run it in the debugger to try and find out what is happening.
Hang on, I'm confused. This bug was for Moz dying silently, wasn't it? Now it's crashing. Am I, and Daniel, really seeing bug 197237? Also, I've just checked the 594(!!) bugs filed in the last 3 days but none are about this and I've seen nothing in the NGs. OK, *I* might be having problems 'coz I'm building my own but Daniel is using the nightlies from mozilla.org. Correct? ssu - since you have both bugs can you clarify please?
Found the problem :-) Whilst waiting for my debug build I uninstalled Moz, deleted \Program Files\mozilla.org that was left behind (but Daniel had tried that anyway so this wasn't the cause), then went a-hunting in the registry. The uninstaller had removed Mozilla and mozilla.org in HKEY_LOCAL_MACHINE\Software but had left some **** around under HKEY_CURRENT_USER\Software including mozilla.org\GRE which had a 1.4a (note, no buildID) under it. I zapped everything Mozilla under HKCU and reinstalled (the same one that was crashing) and it works fine. I hadn't realized that it put stuff in HKCU and although I deleted the remnants in HKLM (as per my suggestion in comment 17) after grabbing seawood's fix for the original problem I hadn't looked in HKCU. Daniel, can you try this with the SEA exe that you d/l'd to confirm please?
I'm not sure why mozilla is looking in HKEY_CURRENT_USER for the location of GRE. It shouldn't be. in either case, this is bug is not the same as bug 197237. Bug 197237 occurrs when installing 1.4a over 1.3. Still trying to get my win98 system up and running.
The uninstaller removes all of the keys correctly, and the installer adds them all back correctly (with version numbers and so on), but it still won't launch. The keys in HKCU look like duplicates of those in HKLM, if that matters. The files in the GRE look ok, but I don't have any way of knowing for sure. Is there any way to make this thing log what it's doing? Doesn't look like a widespread problem, that's for sure. It's just this bug and the crasher I hear about on irc.
Sean: I don't know why it's using HKCU either since it installs system-wide (puts a Moz icon on the desktop of every user who's logged in (XP) when it's installed, but it definitely does. As I said, I zapped all the Moz stuff in HKCU\Software and reinstalled the same build; it recreated the HKCU keys (correctly) and runs. Since this was the only thing I'd missed when cleaning up before installing seawood's fix I figure this was the cause of the crash. Having said that Daniel has tried the same and still gets a crash so maybe it is a Win9x-specific thing. Hopefully you will be able to confirm that when you get a 98 system up. Daniel: It doesn't run for long enough to log anything, which is probably why it doesn't generate a talkbalk either. The only way, IMO, is to make a debug build and step through from the start in the debugger. Hopefully Sean, if he can recreate the problem, will be able to do that.
still present in: version: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 package: http://ftp.mozilla.org/pub/mozilla/releases/mozilla1.4/mozilla-win32-1.4-installer.exe md5sum -b mozilla-win32-1_4-installer.exe 28cb37dfe56476fe0c5a74689cdc0063 *mozilla-win32-1_4-installer.exe to reproduce: 1. use windows 98 || windows 95osr2 which never had mozilla installed || (any mantioned && installed with step 2,3 and removed as through control pannel...uninstall) 2. run installer mozilla-win32-1_4-installer.exe 3. select custom install uncheck all leave just the grey checked field || select custom install and leave all checked 4. uninstall with control pannel.install/remove.uninstall 5. continue with 1. workaround,to avoid splash and die: 5. use step 4. windows installation (maybe step 1. will work too) 6. run installer mozilla-win32-1_4-installer.exe 7. select browser only instead of custom installation 8. run mozilla as expected and enjoy it. btw how about changing severity and some other bug details(have no idea which part is it... installer?)
197692#28 is somewhat broken. sorry. i used wrong package to start off the tests. was not clean w98 installation but heavily loaded with binary patches from microsoft and also windows update. tried it again with realy fresh installation(used correct archive) and state 8. from 197692#28 is splash and die. once again it seems to be issue solved only by updates/patches from microsoft because it had been patched for some time having update and mozilla installed and it did not worked, then left it idle for few hours being busy and later reinstalled mozilla browser only and it worked. bug is always exposed in: 1. install and pack -> 2. unpack correct package ;) 2. -> 3. custom inst. moz., uncheck all leave grey (.exe) 3. -> 4. uninstall moz. 4. -> 5. install browser only(not custom) (.exe) 5. -> 6. uninstall moz. 6. -> 7. install full moz. (.exe) no reset since now, not using quickstart 7. -> 8. uninstall moz. install ethernet card 8. -> 9. install moz. (.zip) 9. -> 10. uninstall moz. 3&5&7&9 splash and die have whole registry dumps of <1,6> and finds, ls -lid for each relevant file+md5sum if anyone interrested + have whole registry dump of same windows but patched with working mozilla again if anyone is interrested no md5sum/listings for working installation but will try to reproduce it but don't expect fine grained change & test .exe stands for executable mentioned in 197692#28 .zip stands for zip archive: md5sum -b mozilla-win32-1_4-talkback.zip a9f6bd8aaa369d2518a95cc1cd527253 *mozilla-win32-1_4-talkback.zip grabbed from same place as .exe highest probability sollution: 99% windows update; from my point of view (and nothing else -> mozilla unusable on 98 and earlier SDMVer=040a.1998, WinVer=070a040a, Build=04.0a.1998, WinFlags=00003c29 and ( not up2date system || just about nything offline )
under early version of w98: problem: splash and die sollution(workaround): upgrade w\system\oleaut32.dll seems 100% reproducible splash and die problem with windows\system\oleaut32.dll, version 2.20.4122(as seen in file properties), size 503808B, md5sum -b is "b2ac8930d8bee999b52574cf2f556eae *./windows/system/oleaut32.dll" description from file properties: Microsoft OLE 2.20 for Windows NT(TM) and Windows 95(TM) Operating Systems also it seems in same installation that 100% sollution is upgrading windows\system\oleaut32.dll to following: version 2.30.4265(as seen in file properties), size 598288, md5sum -b is "dbc403a7d9ce44ebe5f9719bd0749c49 *./windows/system/oleaut32.dll" description from file properties: Microsoft OLE 2.30 for Windows NT(TM) and Windows 95(TM) Operating Systems (it is reproducible to make mozilla run with: unpack w98, install mozilla, splash and die, reboot, replace just oleaut32.dll, boot win, mozilla ok and also unpack w98, replace just oleaut32.dll, boot win, install mozilla ok and also some other more complicated ways) oleaut32.dll 2.30 is availaible as part of patch from http://www.microsoft.com/windows98/downloads/contents/WURecommended/S_WUFeatured/Libraries/Default.asp this patch does some rewriting and also creates in temp directory random named file and modifies wininit.ini, after reboot it replaces on startup oleaut32.dll. patch works for me(makes the splash and die go away) patch does some other rewrites which have been in my earlier tests included and later excluded. just replacing oleaut32.dll prooved only reason of it's success. for me it's fixed, not a bug, feature (but that is close to removal of w95&w98 from requirements list) (maybe add detection code to installer||before splash which will alarm user?)
I have replicated everything from comment 28, comment 29, and comment 30, with the same outcome. I tried installing Mozilla 1.4, Mozilla 1.5a, and the nightly build from August 5, 2003, as well as Firebird 0.6.1 and the Firebird nightly build from August 5, 2003. None of these would launch after installation/unzipping. These were done on completely clean Windows 98 installations (completely clean by using a fresh-from CD Windows 98 install saved in Virtual PC). Updating oleaut32.dll allowed all five versions of Mozilla/Firebird to launch without a problem. This is almost certainly the problem causing bug 213021 and maybe bug 212363 as well. (Three with one blow!)
*** Bug 217190 has been marked as a duplicate of this bug. ***
*** Bug 217126 has been marked as a duplicate of this bug. ***
*** Bug 213021 has been marked as a duplicate of this bug. ***
*** Bug 224074 has been marked as a duplicate of this bug. ***
We need a hint in the release notes about the oleaut32.dll and others, we should recommend to install the VB6SP6 runtimes from http://support.microsoft.com/default.aspx?scid=kb;en-us;290887. See also bug 212363 comment 6 and bug 232060 comment 16.
In win95 i installed a Windows Library Update and now Mozilla starts. (last version working was 1.3.1 without update) http://www.microsoft.com/windows95/downloads/contents/WURecommended/S_WUServicePacks/MFCLibrary/Default.asp
(In reply to comment #37) > In win95 i installed a Windows Library Update and now Mozilla starts. http://www.microsoft.com/windows95/downloads/contents/WURecommended/S_WUServicePacks/MFCLibrary/Default.asp This is a subset of the files I mentioned in comment 36. http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q197/2/98.asp&NoWebContent=1
I experienced this problem once. But that is a long time ago. Can this bug be marked as WorksForMe?
*** Bug 222966 has been marked as a duplicate of this bug. ***
Please restatus this to WorksForMe, and/or remove 'smoketest' keyword.
no reports for 3 years, looks like WORKSFORME (or INVALID)