574701 - Plugin-container.exe crashes Nvidia nvd3dum.dll [@ EverQuest2+0x15c45b]

Status: RESOLVED WORKSFORME

(External Software Affecting Firefox Graveyard :: Flash (Adobe), defect)

Description

[joseph_01]

User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.30618; .NET CLR 3.5.30729; InfoPath.2; .NET CLR 1.1.4322; Creative ZENcast v2.01.01)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; WOW64; en-US; rv:1.9.3a6pre) Gecko/20100617 Minefield/3.7a6pre ( .NET CLR 3.5.30729)

If I close the Everquest game, and then run it again, Everquest crashes, and I get the error below in my event log. 

In order to run Everquest2.exe again, I have to kill the plugin-container first. 

The error is: 
Faulting application EverQuest2.exe, version 1.0.0.1, time stamp 0x4c16a916, faulting module nvd3dum.dll, version 8.17.11.9745, time stamp 0x4bb7dd53, exception code 0xc0000005, fault offset 0x0027fc52, process id 0xf00, application start time 0x01cb0ede5527a060. 

The Nvidia driver I'm using is current and I do not have any other crashes whatsoever. 


Reproducible: Always

Steps to Reproduce:
1. Run Everquest2 game.
2. Run Minefield. Browse Internet while playing game.
3. Exit Everquest2 game.
4. Try to run Everquest2 game again. 
5. Everquest2 crashes with the above error.
6. Go to task manager and kill plugin-container.exe
7. Run Everquest2, and it runs fine.
8. If I close Everquest game, go back to 2.
Actual Results:  
Everquest2 fails to run unless I kill the plugin-container.exe first.

Expected Results:  
Allowed me to run Everquest2 without the game crashing.

Firefox version
3.7a6pre 

Operating system
Vista-64 bit Ultimate Pro SP1 

User Agent
Mozilla/5.0 (Windows; U; Windows NT 6.0; WOW64; en-US; rv:1.9.3a6pre) Gecko/20100617 Minefield/3.7a6pre ( .NET CLR 3.5.30729) 

Plugins installed

Adobe Acrobat, DivX Web Player, Google Update, Java Platform SE 6 U20, Pace Client Helper Plugin, Photosynth, Picasa, Quicktime plug-in 7.6.5, RealJukebox NS Plugin, RealPlayer Version Plugin, RealPlayer G2 Live Connect-Enabled Plug-In (32-bit), Shockwave Flash 10.1 r53, Shockwave for Director ver 11.5, Silverlight Plug-In 4.0.50524.0, Unity Player 2.6.1f3, Yahoo Application State Plugin 1.0.0.7,

Comment 1

[(not currently active) Ted Mielczarek]

If you go to about:config and toggle the pref dom.ipc.plugins.enabled (to false), and restart your browser, do you still have this problem?

I suspect a plugin and Everquest are competing for some graphics-related resource.

Comment 2

[joseph_01]

I did as you suggested.

EQ2 worked for about 5 minutes before crashing with error in event viewer:

Faulting application EverQuest2.exe, version 1.0.0.1, time stamp 0x4c1fe7f0, faulting module nvd3dum.dll, version 8.17.11.9745, time stamp 0x4bb7dd53, exception code 0xc0000005, fault offset 0x0027fc52, process id 0x1960, application start time 0x01cb149007011a30.

Comment 3

[(not currently active) Ted Mielczarek]

Ok, then I think this is a bug in a plugin or in EverQuest. If it crashes the same way regardless of whether you have out-of-process plugins enabled, then I doubt it's anything in Firefox.

Comment 4

[Matthias Versen [:Matti]]

Note: nvd3dum.dll is from your Nvidia video card, maybe you upgraded the video drivers ?

Comment 5

[joseph_01]

There's a new version of video driver for my card. I'll try that out, but I don't think it's the driver. When I was using Firefox, I didn't have this issue, and IE 8 works fine. Only when I started using Minefield 3.7a5pre and 3.7a6pre, did I start having this issue. For a while, I thought it was EQ2 messing up, but then I narrowed it down to the plugin-container a week ago.

Comment 6

[joseph_01]

Installed the new video driver, but getting the same crash and error message. 

I also thought my version of Minefield was 64-bit, but it is running in Vista 64 as a 32-bit program.

Comment 7

[timeless]

we don't officially distribute 64bit versions of firefox for windows at this time.

Comment 8

[joseph_01]

I'm going to try disabling a few plugins at a time and see how that goes.

Comment 9

[timeless]

https://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report
https://developer.mozilla.org/En/How_to_get_a_stacktrace_with_windbg

you can use windbg to get stack traces for everquest too. if you provide stack traces, someone here might look at them.

But you really should contact NVidia directly:

http://www.nvidia.com/object/driverqualityassurance.html

Comment 10

[joseph_01]

Attachment: First Debug Log

Comment 11

[joseph_01]

Thank you.

I reported the issue to NVidia.

I also created a Windbg log and attached it.

Comment 12

[timeless]

Comment on attachment 454411 [details]
First Debug Log

hrm, you need to use debug>go at least once more :(

Comment 13

[joseph_01]

No problem, but what do you mean by doing that once more? I have had to use "Debug > Go" twice to get Minefield to launch in Windbg.

Comment 14

[timeless]

you need to do it until you *don't* see:
Break instruction exception - code 80000003 (first chance)

as the message.

Comment 15

[joseph_01]

Attachment: Latest Debug Log, 28 June 2010 08:11 pm

Comment 16

[timeless]

ok, sorry. i'm still new to the 64bit debugger story (and it doesn't help that my w7x64 license was replaced by a w7x86 license, so I don't have a 64bit environment anymore).

this should be my final answer.
after you do .logopen.... before you do anything else, enter these two commands:

.load wow64exts
.effmach x86

then continue w/ the instructions you've always followed. the results should actually be useful then.

Comment 17

[timeless]

ok, really my final answer:

after you do .logopen, before you do anything else, enter:

!wow64exts.sw

then continue w/ the instructions you've always followed. the results should
actually be useful then, i hope.

Comment 18

[joseph_01]

Attachment: Latest Debug Log 29 June 2010 11:33 AM

Comment 19

[joseph_01]

FYI, Minefield updated itself, and I'm resubmitting a new log, I didn't catch that !wow64exts.sw command until just now, sorry!

Mozilla/5.0 (Windows; U; Windows NT 6.0; WOW64; en-US; rv:2.0b2pre) Gecko/20100629 Minefield/4.0b2pre ( .NET CLR 3.5.30729; .NET4.0E)

Comment 20

[joseph_01]

Attachment: Latest Debug Log 29 June 2010 11:54 AM

Comment 21

[timeless]

sorry, you did almost everything right, but you need to quit firefox before you run it from windbg:
 0n2696 firefox.exe
 0n4604 plugin-container.exe
0n11180 windbg.exe
 0n6588 firefox.exe

So the log you posted is for a firefox which: started, looked around, found itself already running, sent a message to the existing firefox, and exiting.

Comment 22

[joseph_01]

Hmm, that's odd. Firefox has always not been running before I ran Windbg. Always, always.

This is what I've been doing: 

Firefox is not running.
Run Windbg.
Open firefox.exe executable from Windbg.
In the command window:
.sympath SRV*c:\symbols*http://symbols.mozilla.org/firefox
.symfix+ c:\symbols
.reload /f

Now wait for the symbols to download.  WinDbg will show "Busy" at the bottom of the application window until the download is complete.

.logopen /t l:\debug\firefox-debug.log
!wow64exts.sw
.childdbg 1
.tlist
sxn gp
|* lm

Debug > Go
(Firefox doesn't run)
Debug > Go again
Firefox runs
Run Everquest2.exe
Everquest2.exe loads almost all the way and hangs near the end of loading.
|* ~* kp
|* !analyze -v -hang
|* lm
Submit log.
 
Note that normally, when Minefield is running, if I kill plugin-container.exe, then I can run Everquest2.exe and it doesn't hang.

Okay, I'm trying to create a new log, but this time Minefield is hanging on loadup, so I will submit the log (just remember I couldn't run Everquest2.exe because Minefield is hanging from Windbg).  I can start Minefield fine if Windbg is closed.

Comment 23

[joseph_01]

Attachment: Latest Debug Log 30 June 2010 10:27 PM ; Minefield hanging upon 2nd Go from Windbg

Comment 24

[timeless]

don't worry about it, i'm making mistakes too :(. fwiw, one of the reasons for the .tlist step is to enable me to recognize this mistake (but I really need to include some form of explanation into the web page so people can spot it and start over instead of posting to bugzilla).

sorry for the large number of round trips. i'm still having trouble figuring out the 64bit stuff.

let's make two changes:
1. move ".reload /f" down from where it is right now to right before "|* ~* kp"

2. can you please install the 32bit version of windbg and use that instead?  The 32bit windbg can debug our 32bit program (it will ignore some stuff that I hope is irrelevant). Since the application we're debugging is 32bit using the 64bit version is just giving me more headaches than I can take.

Comment 25

[joseph_01]

It installs the same version of Windbg when I select 32-bit. I think I need to set the debugger to 32-bit but I don't know how.

Comment 26

[joseph_01]

Okay, the documentation for Windbg states I cannot use the 32-bit version of Windbg since I'm on Vista 64. I have to install the 64-bit version of Windbg. However, Windbg still allows me to debug 32-bit programs.

Comment 27

[timeless]

it should be in
c:\program files (x86)\... instead of c:\program files\...

which documentation says you can't? i know i've used the 32bit version on w7...

Comment 28

[joseph_01]

I found the installer. It was hidden away as an .msi in the Windows SDK folder. I'll get back to you on this.

Comment 29

[joseph_01]

Attachment: Latest Debug Log 01 July 2010 7:59 PM Minefield hanging on start

I think it took like 3 "Go" in Windbg to start Minefield this time.

Comment 30

[timeless]

the debugger shows that you haven't debug>go'd enough times

from the log:
(8f8.20a4): Break instruction exception - code 80000003 (first chance)
eax=00000000 ebx=00000000 ecx=bc460000 edx=00000000 esi=fffffffe edi=77054c52
eip=77040004 esp=0048fa1c ebp=0048fa4c iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
ntdll!DbgBreakPoint:
77040004 cc              int     3
0:027> .reload /f

you should be using debug>go each time you see:

(???.????): Break instruction exception - code 80000003 (first chance)
...
ntdll!DbgBreakPoint:
77040004 cc              int     3
0:???>

But this is hopeful. please note that if you don't comment w/in the next 6 hours, my next comment will probably be Sunday (i don't work 24-7), but don't worry, just post as usual :).

Comment 31

[joseph_01]

I didn't do it the first time because that runs Minefield right away, and Minefield is not supposed to be running before I do these commands:

.sympath SRV*c:\symbols*http://symbols.mozilla.org/firefox
.symfix+ c:\symbols
.logopen /t l:\debug\firefox-debug.log
.childdbg 1
.tlist
sxn gp
|* lm

Do you still want me to do that and then close Minefield before I run those commands? Or should I leave Minefield open and hit Debug>Go everytime (which will launch more Minefields)?

Comment 32

[joseph_01]

Well, I tried it the first time the int 3 popped up, and Minefield loaded, and WinDbg says "Busy* Debuggee is running", and I can't type anything in WinDbg. I haven't started any commands yet either.

Comment 33

[timeless]

the command sequence is somewhat maleable, the instructions there are basically mine, written up by someone else for me.

.sympath/.symfix are things we want early. .logopen is something we need to make sure that we know what you've done (arguably it should be first, i'm still thinking about it). .childdbg lets us catch plugin children and thus really needs to be done before the program starts. .tlist catches the case where someone forgot to quit firefox (and thus needs to be done before it's started). the .reload OTOH is something that can be done repeatedly (it grabs symbols for libraries which are loaded).

let's try this order:

.logopen /t l:\debug\firefox-debug.log
.sympath SRV*c:\symbols*http://symbols.mozilla.org/firefox
.symfix+ c:\symbols
.childdbg 1
.tlist
sxn gp
|* lm
g

after "g", you should expect the debugger to be busy for a while. it's waiting for you to use debug>break / ctrl-c or for the app to do something which triggers a break


when you see:
(???.????): Break instruction exception - code 80000003 (first chance)
...
ntdll!DbgBreakPoint:
77040004 cc              int     3

use "g" to continue.

Since your problem is that something is hanging, then you're going to want to use ctrl-c/debug>break to get the debugger out of the busy state. Then use:

|* .reload /f
|* ~* kp
|* !analyze -v -hang
|* lm

Comment 34

[joseph_01]

Well, interesting, EQ2 is not crashing anymore, and I've got lots of IE and Firefox windows open too. Great, but unexpected.

Comment 35

[joseph_01]

Attachment: Latest Debug Log 03 July 2010 09:38 AM

Everquest2.exe hung in the middle of playing after about 2 hours.  I was turning left in the game. Checked my Event log to ensure that I got the same error as before (yes) and also plugin-container.exe was running.

Closing Everquest2.exe in its hung state results in Minefield now being hung.

Comment 36

[timeless]

hrm, we got a stack, but it isn't one i was expecting...

nsCSSRuleProcessor::RefreshRuleCascade
nsStyleSet::AppendFontFaceRules
nsPresContext::FlushUserFontSet
PresShell::FlushPendingNotifications
nsDocument::FlushPendingNotifications
nsDocument::FlushPendingNotifications
nsGenericElement::GetPrimaryFrame
nsGenericElement::GetStyledFrame
nsGenericHTMLElement::GetOffsetRect
nsGenericHTMLElement::GetOffsetHeight
nsIDOMNSHTMLElement_GetOffsetHeight
js_NativeGet
js_Interpret
js_Invoke
js_InternalInvoke
JS_CallFunctionValue
nsJSContext::CallEventHandler
nsGlobalWindow::RunTimeout

This doesn't really implicate EQ, Flash or NVidia :(. I wonder if gecko was starved while you were playing EQ and then tried to catch up...

Comment 37

[joseph_01]

Hmm, Minefield seemed to be working when I was in EQ2.  During that time, I went to Eq2 Wikia, Twitter, Facebook and YouTube. Also, Google and Google's stocks page.

Comment 38

[joseph_01]

Attachment: Latest Debug Log 07 July 2010 7:57 AM EQ2 crashed, Minefield froze

Comment 39

[joseph_01]

Any updates?

Comment 40

[timeless]

so, your stacks are wandering further and further form the initial problem. it's very hard to do much with them as they aren't consistent.

The original problem was a crash in nvidia's video driver. If you repeated that, I could send it to an nvidia engineer.

Your latest hang just looks like sockets waiting, it's possible i haven't added enough lock inspection to my cookbook (possible). It's also possible that something has ruined your networking stack, but i don't see any hints of that.

attachment 455862 [details] looks like it might be an expensive web page, but there's no other interesting indications.

Comment 41

[joseph_01]

Could it be a possible problem with Adobe's Shockwave player? It crashes from time to time because it's on one of the tabs I have open in Minefield all the time.  I've updated Shockwave(yet again).

Should I try another stacktrace?

Comment 42

[timeless]

yeah, a couple more stack traces, but preferably only ones where you wait for something to crash...

Comment 43

[joseph_01]

Ah, now I'm confused.  I've only been sending ones where EQ2 crashed.  You want me to send one when I'm running EQ2 and it hasn't crashed?

Comment 44

[timeless]

oh, oops, err.

can you run eq2 under windbg? i need the stack from whichever process crashes, if it's eq2, then that's where the stack of interest is.

Comment 45

[joseph_01]

Attachment: Latest Debug Log 10 August 2010; ran Windbg on Everquest2.exe

Ah, I'm guessing you want me to run the debugger on the EQ2 exe instead of Firefox?  When I try windbg on EQ2, the debugger complains alot about Symbol File could not be found; ah well you'll see here with this trace.

Comment 46

[timeless]

joseph: yeah, symbol file not found is ok/expected. I can still learn quite a lot from the log.

ok, so the thing i was missing is that EQ2 *uses* gecko. Your log quickly told me that (others told me I should have known).

So we have basically two geckos running around. The fact that one gets unhappy when the other does something doesn't surprise me quite as much.

fwiw, this is interesting:
Unloaded modules:
67640000 67f93000   nvd3dum.dll

btodur: is your library doing something interesting? (especially with two nearly identical clients running around and one unloading the library)

joseph: I believe there's an updated version of nvidia's drivers. It'd be great if you tried them. Try this:

http://www.nvidia.com/object/quadro-winxp-x32-259.12-whql-driver.html

crowder: do you still have contacts for EQ?

Comment 47

[joseph_01]

TImeless, that driver's for another video card. I have a Geforce 7600 GT card and I updated its drivers (below) shortly after they came out after 19th July.

http://www.nvidia.com/object/win7-winvista-64bit-258.96-whql-driver.html

Comment 48

[joseph_01]

Uhh, I take that back. I did download them, but did not update.... Updating now.

Comment 49

[joseph_01]

So far so good!  *knock on wood*

Comment 50

[joseph_01]

Attachment: Latest Debug 17 August 2010; EQ2 crashes, Windbg on Everquest2.exe

Hmm, EQ2 was running fine since the 13th (when I updated the video driver) until today. Now, it will repeatedly hang after loading. EQ2 hasn't updated itself since the 4th of August.

Comment 51

[joseph_01]

Think I've discovered the issue with the plugin-container.  If I there is an Adobe Flash plugin running in any of my tabs in Minefield, there is a corresponding plugin-container.exe running. If I kill that before launching Everquest2, then EQ2 runs fine without any crashes.

Comment 52

[timeless]

yeah, more or less that's mostly expected.

basically flash and everquest would be the heavy graphics (nvidia) users, and nvidia probably has a bug in their code.

we need btodur@nvidia to comment. there's very little i can do (i don't have sources to any of eq2, flash or nvidia).

Comment 53

[B Todur]

A crash dump could help with the debugging. The latest crash call stacks point to everquest2. (nvidia driver does not seem to be loaded). Perhaps you should start with EQ2 first. (the nvidia driver is intensively tested for multiple client cases..)

Comment 54

[Brian Crowder]

I've tried contacting some former colleagues to get more info from the EQ2 side with (so far) little success.  I'll try again today.

Comment 55

[joseph_01]

Please Let me know what I can to do help. I tried posting this bug in EQ2 forum's but no devs answered, and all I got was replies from 2 players who said I should search my computer for faulty ram, virus, rootkit, damaged registry, and upgrade to Win 7. First 4, I did check. Upgrading to Win 7 is a no go until I get a new computer in a year or two.

Comment 56

[joseph_01]

This can be closed. Minefield 4.07bpre seems to be working fine with EQ2 along with NVIDIA driver version 8.17.12.5896.  Thank you all for your help, I do appreciate all your efforts on this matter!