Emulator

I don't have this problem since the issue 4152 was fixed : http://code.google.com/p/dolphin-emu/issues/detail?id=4152

Well it doesn't crash when you hit stop. It crashes when you close the program after you hit stop. shrug

Ok, but it works fine for me, with r7594 x64 or with the previous latest x64 build : any error message when I close Dolphin

Same OS (Win 7 x64), same problem. Happens on the lastest revision R7594 (and also on Lectrode's builds, but that is expected). Running the x64 version on a Acer Timeline X 5820TG Laptop:

Intel i5-480M 2.66GHz (up to 2.93GHz)
6GB Ram
AMD Radeon HD 6550M (1GB Ram)

"Dolphin has stopped working"
"Windows is checking for a solution to the problem"

Closes instantly after the close button is pushed.

Does this happen with any specific configuration only or every time? (i.e. different video backend, dual core enabled, ...)
Uncheck all hacks in the graphics config dialog BUT Check "Disable EFB copies" and "Disable External Frame Buffer".

Happens no matter what settings, it results in a crash. Just tried with all hacks off except those two options but it's still crashing.

Also tried with both DX9 and DX11, and the same result occurs.

win 7 ultimate x64
Pentium E5200 O/C @ 3,5GHz
ati/amd hd 4890
4GB DDR2 1066

Dolphin :

general : http://s3.noelshack.com/1/1/1-42b724910.jpg

D3D 11 :
http://s3.noelshack.com/1/1/2-cd1ab4ab64.jpg
http://s3.noelshack.com/1/1/2-c2f844cd40.jpg
http://s3.noelshack.com/1/1/3-a921408c29.jpg
http://s3.noelshack.com/1/1/4-97d4b7fe12.jpg
http://s3.noelshack.com/1/1/5-beaa605297.jpg

I just played about 40 min on FFCC and nothing when I close Dolphin

Every 64 bit released of dolphin since a long time now and any have this problem with these settings

very strange ^^

It's hard to tell the cause of a crash like this if you just say it crashes without providing some debugging information... (even harder for me, as I don't have a x64 OS)

Can anyone with this issue provide a back-trace of the crash coming from the "exceptioninfo.txt" file (bottom-most entry) or from a C++ debugger such as VS2010?

Make sure to tell us which revision/build the "exceptioninfo.txt" file comes from, as you'll likely just get function addresses instead of function names (which require the presence of a PDB file with symbols in order to appear).

Well, I don't have a debugger. Eh, I do have an ancient copy of Visual C++ 6.0 lying around, but I have no idea how to use it. I'd be happy to if someone gave me instructions.

In the meantime, windows has some information, albet very little. I'll include it here.

http://img192.imageshack.us/img192/2352/windowsdebuginfo.png

As for configurations, it has always happened regardless of configurations at the time.

I can creat debug-fast/debug build. but I can got this error/bug with win 7 x64 sp1 ,

Just to reinterate, I'm willing to run debug stuff in order to help you guys figure this out, just need someone to give me a few pointers...

To compile Dolphin, VS2010/Visual C++ 2010 is the only option at this point. To download the source code, you'll need TortoiseSVN as well. See Windows_Build for the official instructions.

If you can't compile Dolphin for some reason, try using this Debug build with symbols (not source code) included: http://www.mediafire.com/?r3j3camsjk7i2g9

Alternatively, since you said that Release 2.0 x64 (which is r5350 AFAIK) does not exhibit this issue whereas r6882 x64 does, it would mean that the revision that caused this issue to appear is between r5351 and r6882. Try narrowing that down by testing a few older builds (Mamario's builds of r65XX, of r60XX, of r57XX, of r55XX, etc...).

(For the record, issue 4202 is about a crash that occurs in USP10.dll as well. Should I merge issue 4202 into this issue instead?)

i seem to have this issue again aswell 64bit build any new build in 7000 series, seems like the emulator isnt clearing memory or something

Wellll, I would rather not have to build a version of dolphin just to show what this error is. It seems quite involved... So, running a debug build definitely sounds more appealing. However, the debug build you gave me appears to be a 32bit build (win32). The error only occurs in 64bit builds of dolphin, so that debug build can't recreate the error. I'll need a x64 debug build.

If I go the debug build route, are any additional programs and things needed, or will the debug build alone be able to give you enough information?

Where is the exceptioninfo.txt file? I believe it is supposed to be in "dolphin directory\User\Dump\Debug" Unfortunately... I can't find one. A search of the directory also didn't turn up an exceptioninfo.txt file. You mentioned something: "Unless the hard-coded paths seem to break it". I think that might be happening here. Where would I have to put it to eliminate that possibility?

Of course there is the possibility that the way it is crashing on exit is preventing an exceptioninfo file from being created, but uh, one thing at a time I guess.

Anyway, I tried "narrowing down to a few revisions" procedure. What I did was run the rev straight from extraction, I didn't change settings or move over saves or anything, and ran windwaker and melee. In a curious note, a revision before 2.0 (r5350) had the error! Here's the results.

r4696 x64 - Error
r5003 x64 - No error
2.0 (r5350) x64 - No error
r5515 - No error
r5749 - No error
r6002 x64 - Error

I have dialup, so downloading and testing all these builds is a chore. I'm posting what I have so you can respond to the exceptioninfo.txt question. Hopefully I can find the revision that broke it soon.

Whenever a crash occurs, Dolphin should append an exception record into an "exceptioninfo.txt" file that's located in the same folder as DolphinD.exe. This file is created when it does not exist already.

Example of "exceptioninfo.ini" file for a build without symbols: http://pastebin.com/NkPkdN1M
Another (different) example, this time for a build with symbols: http://pastebin.com/G3ZkA4ri

If the crash of r4696 x64 does not occur in USP10.dll (as recent builds seem to indicate), then that crash is likely due to an old, different issue. Thus, the "culprit" would be in the r5750-r6002 range.

(Maybe finding out the revision that caused your problem to appear is going to remind us/me of a particular commit or issue)

Well, it doesn't make an exceptioninfo.txt. I looked where you said, and it's just not there. Not in the debug build you sent me, not any of the tons of builds I have tried. Something about how it crashes must prevent it from creating an exceptioninfo.txt. shrug

Going back to revision testing, I have been making alot of progress. I retested r4696 on a whim, and I wasn't able to repeat the problem. So, worried about the accuracy of my testing, I went through and retested all of the revisions I have, and they all still crashed, with absolute consistency. So... I'm calling it a fluke, and labeling r4696 as not having the error. Anyway, I found the rev that breaks first, and uh, it's a little melodramatic. r5913. I was expecting some sort of ah HA! big change to the code type deal, but this is all just, nothing that would have anything to do with this. shrug. Yea well, I'm not a coder, so maybe it is an ahha! moment. So, here's the full list of tested revisions.

r4696 x64 - No Error
r5003 x64 - No error
r5350 x64 - No error
r5515 x64 - No error
r5749 x64 - No error
r5850 x64 - No error
r5899 x64 - No error
r5907 x64 - No Error
r5911 x64 - No Error
r5912 x64 - No Error
r5913 x64 - Error
r5915 x64 - Error
r5925 x64 - Error
r5949 x64 - Error
r6002 x64 - Error
r6882 x64 - Error
r7128 x64 - Error
r7422 x64 - Error
r7538 x64 - Error
r7443 x64 - Error
r7594 x64 - Error

I should note that all the ones that I looked at the crash details on, listed USP10.dll as the "culprit". And thanks for the patience in working with me on this; this isn't a very common issue, and even then not exactly a big problem.

With you guys busy and all on v3.0, I didn't want to bump this and bug you guys too much. But hey, 3.0 is here. Sooo... I have the revision that caused appears to have caused it. Is that enough information, or do I need to install Visual C++ 2010 and get some debug information?

Finding the exact revision is a big step already; and I hope it isnt a wxw problem.

I'm getting alot of crashing on closing games on recent builds. Not sure if it's related to this or the problem has gotten worse. Happens alot now with DX11.

Unhandled Exception
Code: 0xC0000005
Call stack info:
Dolphin!0x004D8692 : ?

Unfortunately I can not reproduce this crash on exit issue with any graphics backend on windows. That makes it rather difficult for me to fix the issue, as it is not an issue for me. So I will have to rely on debugging information from someone that has the issue and can provide such information.

j4ck.fr0st: Do you have this issue? Can you find anything more about what is going on?

Same issue here, but it seems to occur after playing for some time, as I can't replicate it without being in game for a while. Might have something to do with cleaning out memory after exiting the game?

I'll upload a clean ExceptionInfo.txt the next time it happens (I'm also seeing issue 4568 a lot, so I want to try and get ONLY this particular crash if at all possible.)

Some days before, I had the same problem. It crashed even if I played for secs.
Now, I think the crash has dissapeared.

The only setting that I remember to have changed, is to turn on the Nvidia 3D Vision, but setting it to start hidden. I'm not sure if that was the problem.

its something to do with compatability mode, i had this issue, windwos 7 set some compatability mode (didnt tell me what it did at all though) and it was fixed for a while but its came back

I have reproduced this issue in Visual Studio 2010 using the the 3.0-71-dirty source.

System Stats:
Windows 7 x64
Core 2 Duo 6600@2.4ghz
Nvidia Geforce 260GTX

Everytime I close Dolphin the execption is thrown. I have traced the issue to the destruction of the windows in window.cpp. The WM_NCDESTROY message is sent after a window's child windows have been destroyed. This message is not processed in the message switch and is passed to CallWindowProc where the exception is being thrown. If WM_NCDESTORY is handled by DefWindowProc, then the application exits gracefully. I'm not sure why this issue is not present across all Windows builds.

What is the protocol for getting the bug assigned to me, code review, and submission?

Submit a patch here for review. If it looks good you may be added as a committer.

After looking at the code, there is a comment that DefWindowProc needs to be called after the WM_DESTORY message has been received. I noticed that on exit after the WM_DESTORY message, the CallWindowProc is being called on sub-classed windows. This causes improper destruction of the main window which is why the exception is thrown. By enforcing what was originally in the comment that DefWindowProc needs to be called, the application exits without error and the WM_NCDESTROY message does not need to be handled.

Attached is the proposed fix.

fwiw, r5913 == rb175397cb7c7c236e3e35e2eb57b769af8c9808d

This is still not fixed. Please could this be looked into? It's really annoying.

Bumping this issue isn't going to get it fixed any faster.