MFC Crash on exit

[Kibble]

Something I did recently started causing a crash on exit, and I can't figure out what it is. Like the unbelievable retard I am, I just said to myself I'll find it later, and keep working on what I was working on. Now I don't have much of a way to figure out what is causing it, considering the call stack is nothing but MFC42D! xxxxxxxxx with AfxWinMain and such at the bottom. The curious thing is that it only seems to happen when I have a document open (the app is MDI). If there is no document open in the app when closing, it closes fine. I can open, create new, and close all the documents I want without a crash, but as long as there aren't any open when closing, it works fine.

Anything that might cause this would be extremely helpful, since I am stumped short of going through and removing everything until it stops happening.

[cilu]

What kind of crash is it? Is it a memory access violation? Do you get an Debug/Close message? You should run you application in debug mode (F5) and when the crash occurs look into the stack call to see what is causing it.

[Kibble]

Sorry, I can't believe I didn't mention that. It is an Access Violation. however in my first post I said the call stack is full of DLL calls and addresses, nothing useful. the last line of code called in my app is pThread->Run() or something simliar (I am 'overriding' AfxWinMain). Here is the only useful information from the callstack:

... lots of dll calls here, lots and lots.
AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00141ef9, int 0x00000001) line 259 + 19 bytes
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00141ef9, int 0x00000001) line 30
WinMainCRTStartup() line 330 + 54 bytes
KERNEL32! 77e7eb69()

[cilu]

I cannot figure out from that. Perhaps you should post your project here (zip it first).

[Kibble]

Err, it would be tricky, there are 80,000+ lines of code (6,500 of it is the MFC project app, but it would be crippled without the other code), and another 30 megs of content (meshes and textures) to make the app useful.

I wasn't expecting a solution to be handed to me, it will be virtually impossible, I was just hoping someone might have run into something similar before and I could check those things first before tearing the app down piece by piece until it stops happening. I assume I'm fudging some pointers somewhere that MFC tries to free it on exit, but its hard to say.

[Paul McKenzie]

Err, it would be tricky, there are 80,000+ lines of code (6,500 of it is the MFC project app, but it would be crippled without the other code), and another 30 megs of content (meshes and textures) to make the app useful.

I wasn't expecting a solution to be handed to me, it will be virtually impossible, I was just hoping someone might have run into something similar before

You can get a crash on exit with a 10 line program. It has nothing to do with the size of the program.

and I could check those things first

Wrong approach. Always assume your own code is at fault, because 99% of the time, it is. The first thing you do is to find out why it crashes. Once you have that figured out, then you conclude that the solution requires a coding change, or if there is a legitimate bug in some library that you have no control over.

before tearing the app down piece by piece until it stops happening. I assume I'm fudging some pointers somewhere that MFC tries to free it on exit, but its hard to say.

It may not be MFC at all, it could be all in your own code that has nothing to do with MFC.

Regards,

Paul McKenzie

[RoboTact]

If call stack is damaged, try to trace your programm from point before crash to the crash point to determine the cause. Use "Run to cursor" command in debug mode.

[NMTop40]

yeah but it's so easy to make errors with MFC because it has so many rules about having to do things in the right order and call the right function in the right circumstance etc. when it could make life easier and either (1) do itself what it wants you to do or (2) don't allow you to call the second function.

The worst of these is asserting when you delete a window that hasn't been destroyed. (Hey guess what, we can destroy the window ourselves! Have Microsoft never heard of RAII?). And especially when this happens in the call-stack of an exception. Hey, we wanted to catch the exception but no we get some silly debug-assert.

At least with WTL you have access to all the code and can put in these modifications.

[lordkelvan1]

My answer to your thread will probably not help at all, but here goes nothing. I use to get an error (I think it was access violation) whenever I closed my program, with an open document. It actually turns out I had left this thread running in the background, which I did not close when exiting. Of course, my program was pretty simple, and it was SDI, but you never know

[Loada]

Are you using COM i.e. are you calling AfxOleInit() or CoInitialize[Ex]? MFC will crash if there are COM references left outstanding in the current apartment when MFC comes to tidy up (internally it calls the MFC equivalent of CoUninitialize) on application shutdown.

This is a total shot in the dark so apologies if I'm off the mark...

[Kibble]

You can get a crash on exit with a 10 line program. It has nothing to do with the size of the program.

I know, I was responding to the request to post the code, which is not practical.

Wrong approach. Always assume your own code is at fault, because 99% of the time, it is. The first thing you do is to find out why it crashes. Once you have that figured out, then you conclude that the solution requires a coding change, or if there is a legitimate bug in some library that you have no control over.

I already said above that I assume its my problem, what I'm asking is that the symptom appears to be pretty unique (crash only when a document is open, closing the document, then the app works fine) so I was wondering if others had run into the same thing.

It may not be MFC at all, it could be all in your own code that has nothing to do with MFC.

Regards,

Paul McKenzie

It is possible, but the other code has been pounded on for a long time, the MFC app only interfaces with the code and is fairly new. I'm pretty convinced its a problem in my MFC code because of this, and the fact that the call stack is 0% my code.

Are you using COM i.e. are you calling AfxOleInit() or CoInitialize[Ex]? MFC will crash if there are COM references left outstanding in the current apartment when MFC comes to tidy up (internally it calls the MFC equivalent of CoUninitialize) on application shutdown.

This is a total shot in the dark so apologies if I'm off the mark...

Its possible, one of the other projects this MFC app uses is a direct3D renderer, which is COM. I will check this out, maybe MFC is destroying the view after calling this function, and my IDirect3DSwapChain8s are sill alive. This is done in a separate DLL though so I don't know if MFC can see those COM objects.

yeah but it's so easy to make errors with MFC because it has so many rules about having to do things in the right order and call the right function in the right circumstance etc. when it could make life easier and either (1) do itself what it wants you to do or (2) don't allow you to call the second function.

My experience with MFC shows this, which is why I posted such a crappy thread I think I'm just calling something out of order on exit, but I don't know what, I've had less specific crashes and been able to find cookie cutter solutions before.

[Kibble]

My answer to your thread will probably not help at all, but here goes nothing. I use to get an error (I think it was access violation) whenever I closed my program, with an open document. It actually turns out I had left this thread running in the background, which I did not close when exiting. Of course, my program was pretty simple, and it was SDI, but you never know

I only have one place where I use threads, and its not being used. Thanks for trying I think I will just start tearing it down until I find the cause, it is unreasonable of me to expect an answer with the information I've given.

[Kheun]

I think I will just start tearing it down until I find the cause

I used to debug a code using the above method. By identifying the actual flow of the program that causes the bug, I easily eliminate the non-related code and commented out these code and still able to replicate the same error. Finally, I found out that the error is due to buffer overrun that produce an "access violation" error in other not-so-related code.

[RoboTact]

I only have one place where I use threads, and its not being used. Thanks for trying I think I will just start tearing it down until I find the cause, it is unreasonable of me to expect an answer with the information I've given.

Since you have only a one thread, why don't you just trace the closing code to find the cause? Debugger is a useful tool...

[Kibble]

Since you have only a one thread, why don't you just trace the closing code to find the cause? Debugger is a useful tool...

It is faster to do what I'm doing now than try that, in the past when I tried to find problems with MFC code like this, I've stepped right over it without realizing its something MFC doesn't like.