On my machine, the app crashes on exit every single time. [@ OleRegisterMgr::~OleRegisterMgr() line 111]



19 years ago
14 years ago


(Reporter: selmer, Assigned: shanjian)


({crash, topcrash})

Windows NT
crash, topcrash

Firefox Tracking Flags

(Not tracked)


(Whiteboard: nsbeta3+, crash signature)



19 years ago
Commercial 2000-081708-M18 (and at least yesterday's build too, possibly more)
NT 4.0.

Launch browser w/AIM autologin.  Close app.

Get dialog about referencing location 0xffffffff and sometimes other addresses
like 0x000000014.  No talkback report because it doesn't come up in this case.

Comment 1

19 years ago
Adding crash keyword, nominating nsbeta3.
Keywords: crash, nsbeta3

Comment 2

19 years ago
selmer@netscape.com can you try to reproduce this in a mozilla build.  I am
unable to repro with 081708 mozilla build on NT or win2K.  It might help us
narrow it down if you tried on mozilla and could not reproduce it.

Comment 3

19 years ago
Will look at this w/mozilla on Monday.  Disambiguating summary.
Summary: My machine crashes on exit every single time. → On my machine, the app crashes on exit every single time.

Comment 4

19 years ago
Using today's 82313-m18 build with a brand new (but not activated) profile, I
still get the same crash on exit.  Sorry, didn't get to trying a mozilla build

Comment 5

19 years ago
*** Bug 49998 has been marked as a duplicate of this bug. ***

Comment 6

19 years ago
selmer, I just searched for a talkback under your name for this issues, and 
cannot find one.  Can you reproduce, send in a Talkback, and get stack trace 
data in this bug please?  Thanks!
Assignee: asa → law
QA Contact: doronr → claudius

Comment 7

19 years ago
Jan, talkback doesn't come up for this hence no talkback reports on it.  I need 
to get a debug build and see if it repros there (for some reason, I haven't had 
a debug build on my machine for a long time ;^)


19 years ago
Blocks: 7799

Comment 8

19 years ago
nav triage team:
recommend nsbeta3- because no one can reproduce, no stack trace, etc.
reassigning to selmer, y'all decide
Assignee: law → selmer
No longer blocks: 7799

Comment 9

19 years ago
Since 49998 was marked as a duplicate of this bug, I can provide a talkback.  
I've just sent one in with williamsca@process.com and TalkBack ID TB16255662Q as 
the ID number.  Good luck!

Comment 10

19 years ago
On my Win98 machine I also crash every time.  I have talkback IDs for that
machine: TB16291275H and TB16246741Z.

Comment 11

19 years ago
There is talkback in this bug now.  Back to you.
Assignee: selmer → law

Comment 12

19 years ago
nav triage team:
setting as P2 because we don't know how many users run into this problem.
Won't P1 it without a reproducable test case....
Priority: P3 → P2
Whiteboard: [nsbeta3+]

Comment 13

19 years ago
The Win98 crashes went away after I fixed my prefs.  My prefs had been pointing
various directories into a non-existent profile area from back in the old days
when it went into the build directory.  Fixing those to point into my actual
profile corrected this problem on that machine.

Unfortunately, I did not have a similar situation on my NT box.  All directories
appear to be correct and valid on my NT.  This is the machine where I don't get
talkback reports.

Comment 14

19 years ago
No cycles for this one unless we can reproduce it with a debug build.

Steve, can you try running somebody's debug build and see if you can reproduce 
it?  The stack trace would likely reveal what's happened.  It also isn't likely 
an xpapps bug anyway.  Maybe we could give it to somebody less doomed (but they 
won't likely do anything either unless we can recreate it in the laboratory).
Priority: P2 → P3

Comment 15

19 years ago
Using 9/12 mozilla build, I can reproduce this.  Here is *a* stack trace I got, 
but I'm not sure I believe this one.

DIMM! 642090db()
USER32! 77e7e21c()
USER32! 77e71982()
NTDLL! 77f763a3()
OleRegisterMgr::~OleRegisterMgr() line 111
$E20() + 42 bytes
_CRT_INIT(void * 0x01c60000, unsigned long 0, void * 0x00000001) line 236
_DllMainCRTStartup(void * 0x01c60000, unsigned long 0, void * 0x00000001) line 
289 + 17 bytes
NTDLL! 77f69dca()
KERNEL32! 77f19ffb()
doexit(int 0, int 0, int 0) line 392
exit(int 0) line 279 + 13 bytes
mainCRTStartup() line 345
KERNEL32! 77f1ba06()

When I ran without the debugger, I got this message on the console: "###!!! 
ASSERTION: Component Manager being held past XPCOM shutdown.: 'cnt == 0', file 
d:\5\mozilla\xpcom\build\nsXPComInit.cpp, line 667" and then the memory 
exception followed very quickly.

In the debugger, I had to wade through a whole series of assertions but never 
made it to this one before ending up back in the debugger.  I think the message 
about component manager is more likely relevant.

Comment 16

19 years ago
Cleared up a lot of the assertions, I had a bogus news server defined.  It seems
that whether or not the component manager assertion comes before or after the
crash is slightly random.  I've had the crash happen first a couple times now.
(Or maybe getting rid of those assertions changed things.)

Anyway, now I believe the stack trace and I'm wondering if there's some
configuration on my machine that might be involved.

Any suggestions?

Comment 17

19 years ago
I have no idea what's going on.

I see the "component manager being held past xpcom shutdown" assertion now and 
again.  I always attributed it to bad karma.  I usually say "ignore" (and 
sometimes it crashes?) or just "Abort" 'cause it's faster.

I've seen that stack before, too, it seems.  Funny thing is that there's doesn't 
seem to be any Mozilla code in there.  It's all VC++ runtime stuff.

Comment 18

19 years ago
Could it be due to some configuration on my machine?  Is it possible we're using
the compiler in a way that brings us here even without explicit calls in the app?

Comment 19

19 years ago
*** Bug 52836 has been marked as a duplicate of this bug. ***

Comment 20

19 years ago
cc myself.
I see this every time on my Winnt spk5 system, running commercial release builds
up to today (2000-09-18-08M18) I always run installer. I saw it consistently on
a co-workers system with Win 2000 spk1 also.It also occured fo me if I launch
-Aim or -mail and simply exit those apps.
Note, when I exit the app with the same build at home (on dialup 56k line) I
won't crash. It's only on the builds on the lan at work that this crash occurs.
The only other diff from the builds at home is I run a custom install to save
some time. I installed Browser, mail, talkback and IM, with no language paks or
java at home.

Comment 21

19 years ago
I get the same stack trace as selmer above. I'm using NT 4.0, build 1381, SP3,
with MSIE 5.00.2919.6307 installed.


19 years ago
Keywords: topcrash
Summary: On my machine, the app crashes on exit every single time. → On my machine, the app crashes on exit every single time. [@ 0x00000040 - nsQueryInterface::operator()]

Comment 22

19 years ago
Adding topcrash keyword...this is a topcrasher according to talkback data. [@ 
0x00000040 - nsQueryInterface::operator()]  The stacktrace from bug 52836 is the 
same as those in the latest talkback reports.  Here are some entries and a 

0x00000040 19671430
        Build: 2000091506 CrashDate: 2000-09-15 UptimeMinutes: 2  Total: 151 
        OS: Windows NT  4.0 build 1381
        Comment: Crash exiting browser...aim is in sidebar logged in Win32 

    0x00000040 19671430
        Build: 2000091506 CrashDate: 2000-09-15 UptimeMinutes: 0  Total: 151 
        OS: Windows NT  4.0 build 1381
        Comment: Crash exiting browser

    0x00000040 19671430
        Build: 2000091506 CrashDate: 2000-09-15 UptimeMinutes: 0  Total: 152 
        OS: Windows NT  4.0 build 1381
        Comment: crash exiting aim

0x00000040 19671430
        Build: 2000091506 CrashDate: 2000-09-15 UptimeMinutes: 115  Total: 149 
        OS: Windows NT  4.0 build 1381
        Comment: crash exiting seamonkey Win32 2000-09-15-06M18

0x00000040 f12e5c88
        Build: 2000091508 CrashDate: 2000-09-17 UptimeMinutes: 16  Total: 16 
        OS: Windows 98  4.10 build 67766446
        Comment: closing the app! arf arf arf

Stack trace from a crash with build 2000091508:
Incident ID 17534744 
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp, line 
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp, line 
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjs.cpp, line 319] 
line 102] 
line 125] 

Comment 23

19 years ago
The stuf in the talkback reports is almost certainly a dup of 52940 which I just 
fixed. It would have failed in different places depending randomly on how soon 
the free'd memory was recycled.

I don't know about this OleRegisterMgr::~OleRegisterMgr() business.

The first run only asserts in Component Manager are annoying but harmless. We 
just don't have shutdown order under very good control.

I'd vote for just marking this a dup of 52940. But if there is something here 
you want to preserve separately then fine by me.

Comment 24

19 years ago
I have never gotten talkback to come up when hitting this problem.  The
OleRegister cruft is really what's in my stack trace.  I don't think the stuff
jpatel added belongs in this bug and I don't think this is a dup of 52940.
Please don't dup/close this bug unless you can verify it.

Has anyone who gets the OleRegister stack ever seen talkback come up for it?

Comment 25

19 years ago
selmer, I gotcha. Maybe you should change the subject line back to what it was 
or to mention "OleRegisterMgr::~OleRegisterMgr()" or the aim angle if 
appropriate. The addition to the subject that jpatel made threw me.

Comment 26

19 years ago
Changing summary to reflect OleRegister stack.  Please take other stacks
elsewhere :-)
Summary: On my machine, the app crashes on exit every single time. [@ 0x00000040 - nsQueryInterface::operator()] → On my machine, the app crashes on exit every single time. [OleRegisterMgr::~OleRegisterMgr() line 111]

Comment 27

19 years ago
When the OleRegisterMgr thing happens to me, I don't get Talkback.

Comment 28

19 years ago
Nav triage team: Minusing this because we can't reproduce consistently; however, 
this problem will be addressed... and addressed again... and again...
Whiteboard: [nsbeta3+] → [nsbeta3-]

Comment 29

19 years ago
DIMM.DLL is related to Active IME. See 

It seems DIMM.DLL is not installed by default NT4/95/98 installation. You 
probably need to download the ActiveIME to reproduce it.
add kato-san, yokoyama, and shanjian  to the cc list.
you may need to install some Active IME to reproduce this. For Netscape people, 
you can find the active IME we put in the internal place in 

I believe anyone of these have dimm.dll in it.

Comment 30

19 years ago
I uninstalled the IME and rebooted and now I don't crash on exit anymore.
Thanks for the info!

Would a release note suffice for this?  (Crashing when you were exiting anyway...)

Comment 31

19 years ago
Sorry for the confusion, but if my info from 9/18 isn't related to this bug, why 
is bug 52836 marked a dup of this one?  Please point me to the right place or 
let me know if i should log a new bug for the crash involving 
nsQueryInterface::operator().  Thanks.

Comment 32

19 years ago
We have a fix, reportedly, reassigning.
Assignee: law → shanjian

Comment 33

19 years ago
I reproduced the bug on mozilla with NT4, it is very annoying. After I 
compared the implementation with mine for 4.x, I found the problem is 
caused by a missing function call before release AIMM. here is the diff:

Index: nsToolkit.cpp
RCS file: /cvsroot/mozilla/widget/src/windows/nsToolkit.cpp,v
retrieving revision 3.12
diff -c -r3.12 nsToolkit.cpp
*** nsToolkit.cpp       2000/04/26 06:22:21     3.12
--- nsToolkit.cpp       2000/09/21 21:02:59
*** 189,194 ****
--- 189,195 ----

      if (!nsToolkit::gAIMMCount) {
          if(nsToolkit::gAIMMApp) {
+             nsToolkit::gAIMMApp->Deactivate();
              nsToolkit::gAIMMApp = NULL;


Comment 34

19 years ago
remove nsbeta3- in status whiteboard.

My fix is simple and straitforward. Same implementation for 4.x has been 
working for several months. I strongly recommend to check in this fix.
Whiteboard: [nsbeta3-]

Comment 35

19 years ago
make sense, check it in.
Priority: P3 → P2
Whiteboard: nsbeta3+

Comment 36

19 years ago

Comment 37

19 years ago
fix checked in.
Last Resolved: 19 years ago
Resolution: --- → FIXED


19 years ago
Summary: On my machine, the app crashes on exit every single time. [OleRegisterMgr::~OleRegisterMgr() line 111] → On my machine, the app crashes on exit every single time. [@ OleRegisterMgr::~OleRegisterMgr() line 111]
mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31.

if you think this particular bug is not fixed, please make sure of the following
before reopening:

a. retest with a *recent* trunk build.
b. query bugzilla to see if there's an existing, open bug (new, reopened,
assigned) that covers your issue.
c. if this does need to be reopened, make sure there are specific steps to
reproduce (unless already provided and up-to-date).


[set your search string in mail to "AmbassadorKoshNaranek" to filter out these
Product: Browser → Seamonkey
Crash Signature: [@ OleRegisterMgr::~OleRegisterMgr() line 111]
You need to log in before you can comment on or make changes to this bug.