197692 - [win9x] Mozilla exits immediately after showing the splash screen (due to outdated oleaut32.dll)

Status: VERIFIED WORKSFORME

(SeaMonkey :: General, defect)

Description

[Daniel Brooks [:db48x]]

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.

Comment 1

[Michael Lefevre]

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...

Comment 2

[Owen Marshall (Not reading bugmail)]

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.

Comment 3

[Owen Marshall (Not reading bugmail)]

Crashes after mozilla -profilemanager is used to create a clean profile.

Comment 4

[Doug Turner (:dougt)]

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) 

Comment 5

[Doug Turner (:dougt)]

that stack is from talkback.

Daniel - what is the exact URL you use to download the bits?

Comment 6

[Doug Turner (:dougt)]

I see this too with this mornings windows zip build.  However I do not see the
crash with yesterday mornings windows zip build.

Comment 7

[Doug Turner (:dougt)]

possible dup? 197237 

Comment 8

[Doug Turner (:dougt)]

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.

Comment 9

[Daniel Brooks [:db48x]]

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.

Comment 10

[parish]

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

Comment 11

[Owen Marshall (Not reading bugmail)]

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?

Comment 12

[Doug Turner (:dougt)]

owen - not a duplicated, so I don't need those files.

parish - nice detective work.  


Over to seawood.  

Comment 13

[hacker formerly known as [e-mail]]

Fix for this was checked in last night. (stupid dos line-endings)

Comment 14

[Daniel Brooks [:db48x]]

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?

Comment 15

[hacker formerly known as [e-mail]]

-> ssu

Comment 16

[parish]

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.

Comment 17

[parish]

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.

Comment 18

[Daniel Brooks [:db48x]]

I just nuked everything, and the same thing happens.

Comment 19

[Sean Su]

today's build works fine for me under winXP.  looking for a win98 system now.

Comment 20

[parish]

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.

Comment 21

[Daniel Brooks [:db48x]]

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/)

Comment 22

[parish]

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.

Comment 23

[parish]

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?

Comment 24

[parish]

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?

Comment 25

[Sean Su]

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.

Comment 26

[Daniel Brooks [:db48x]]

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. 

Comment 27

[parish]

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.

Comment 28

[asdfasdf]

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?)

Comment 29

[asdfasdf]

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 )

Comment 30

[asdfasdf]

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?)

Comment 31

[davidkolar]

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!)

Comment 32

[Bill Mason]

*** Bug 217190 has been marked as a duplicate of this bug. ***

Comment 33

[Simon Paquet [:sipaq]]

*** Bug 217126 has been marked as a duplicate of this bug. ***

Comment 34

[Mike Connor [:mconnor]]

*** Bug 213021 has been marked as a duplicate of this bug. ***

Comment 35

[Simon Paquet [:sipaq]]

*** Bug 224074 has been marked as a duplicate of this bug. ***

Comment 36

[OstGote!]

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.

Comment 37

[Manfred Lebek]

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

Comment 38

[OstGote!]

(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

Comment 39

[Jan Vlug]

I experienced this problem once. But that is a long time ago.
Can this bug be marked as WorksForMe?

Comment 40

[OstGote!]

*** Bug 222966 has been marked as a duplicate of this bug. ***

Comment 41

[Ronald Tilby]

Please restatus this to WorksForMe, and/or remove 'smoketest' keyword.

Comment 42

[Andrew Schultz]

no reports for 3 years, looks like WORKSFORME (or INVALID)