MFC Crash on exit

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.

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.

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:

Code:

---

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

---

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

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.

Quote:

---

Originally Posted by 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

---

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

Quote:

---

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.

Quote:

---

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

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.

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.

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

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

Quote:

---

Originally Posted by Paul McKenzie

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

Originally Posted by 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 :)

---

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.

Quote:

---

Originally Posted by Kibble

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.

Quote:

---

Originally Posted by Kibble

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

Quote:

---

Originally Posted by RoboTact

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.

Something that others may have overlooked is your destructors.

Make sure your derived class destructors are declared virtual so the base class destructors are correctly called.

As a general rule, I make all of my destructors virtual so that I don't run into this type of problem.

So, in short, change all of your class destructors to virtual, and see what happens.

Hope this helps,

- Nigel

Quote:

---

Originally Posted by NigelQ

As a general rule, I make all of my destructors virtual so that I don't run into this type of problem.
- Nigel

---

Really, even classes which are not used polymorphically?

Thanks for the tip nigel, but I'm pretty sure all of my classes that need it have virtual destructors.

However, I seem to have made a breakthrough, at least it seems to prevent the crash some of the time. In my CView derived class, if I add this:

Code:

---

        if(GetMainWnd()->GetActiveView() == this)
                GetMainWnd()->SetActiveView(NULL);

---

in the destructor, it doesn't crash every time I exit.
(GetMainWnd() just casts the result of AfxGetMainWnd() to a CMDIFrameWnd)

This doesn't make any sense to me. Shouldn't MFC's CView destructor be doing this for me? I have a feeling this is just covering up another problem.

A complete stack trace with symbols can also help people give you hints. Use the symbol server, if you do not have .NET then you need to grab windbg or if you installed the debugging tools for the Platform SDK then it should be in one of it's install dirs.

http://msdn.microsoft.com/library/de...mbolserver.asp

http://msdn.microsoft.com/library/de...g_debugger.asp

Also make sure there is nothing getting sent to the debug output window...Like 'heap errors' etc.

Hmm, I wonder if you're trying to access one of the view(s) during the shutdown process, which is accessing some invalid memory. Could you set a flag once the shutdown has been issued and see if your OnUpdate handlers are being called after the flag is set? Also check anything outside the views that might be indirectly accessing a view.

souldog, you're right, the virtual destructors are not needed unless the class is referenced in a polymorphic way, but there are instances when this type of access is difficult to spot.

If we look at the example of Kibble here, if his derived view's destructor is not declared virtual, all kinds of problems exist when the view and main frame objects are being cast and recast to other types. As a rule yes, I still try to make all of my destructors virtual to avoid the issue - I'll live with the added expense.

- Nigel

Unfortuantely I'm using Visual Studio 6, I'm downloading the part of the SDK with windbg now.

Quote:

---

if his derived view's destructor is not declared virtual

---

It is, and has to be, because CObject's destructor has got to be virtual.

Nothing is showing up in the output window, except of course the Access Violation.

Quote:

---

Hmm, I wonder if you're trying to access one of the view(s) during the shutdown process, which is accessing some invalid memory. Could you set a flag once the shutdown has been issued and see if your OnUpdate handlers are being called after the flag is set? Also check anything outside the views that might be indirectly accessing a view.

---

This is most likely my problem, however I'm fairly sure that I'm not doing it. I can check more, but I can't think of anything of mine that would be doing that. Could it be that I'm not destroying something where I should be? edit: Of course it could be, but is there something that I need to destroy? I kind of assumed MFC would destory the document and view on exit.

Sorry about all of this I'm a bit of an MFC newbie, just trying to make an editor for my game engine.

OK! I have discovered the cause of the crash. I was handling WM_SETFOCUS, which looked like this:

Code:

---

void CRtsEdView::OnSetFocus(CWnd * pOldWnd)
{
    CView::OnSetFocus(pOldWnd);

    GetMainWnd()->SetActiveView(this);
}

---

HOWEVER, apparently that code was necessary to maintain the active view (is the active view member of CFrameWnd not maintained by MFC, I have to maintain it?). Now some of my UI elements don't function properly because they depend on the active view being set to the correct view. I suppose I could try to handle OnKillFocus as well and SetActiveView(NULL) in that handler, if the active view is 'this'. This all seems pretty hackish to me though, shouldn't the CFrameWnd/CMDIFrameWnd be maintaining this member?

Alright, sorry for so many posts. I seem to have solved it by simply maintaining my own active view and document pointers, and not ever calling the SetActiveView MFC member function. I assume MFC was trying to do something with this pointer, yet it doesn't maintain it? that seems pretty obnoxious to me, I must be doing something else wrong.

Quote:

---

Originally Posted by NigelQ

If we look at the example of Kibble here, if his derived view's destructor is not declared virtual, all kinds of problems exist when the view and main frame objects are being cast and recast to other types. As a rule yes, I still try to make all of my destructors virtual to avoid the issue - I'll live with the added expense.
- Nigel

---

Correct me if I am wrong, but if the base class has a virtual destructor then any derived class will have an implied virtual destructor, even if you don't explicitly declare
it that way. In other words it does not matter if you don't declare the destructor
virtual, although it is good documentation.

You know, I have been coding for 10 yrs now, I never use debug or diagnostic tools, why, because in C++ it's usually a memory problem.

What I have found works great for debugging and how I debug is I use:

CString msg
msg.Format (" Accessing code sectiong %s, %d, %c", somestring, someint, somechar);
AfxMessageBox(mst);


.. and I place messageboxes and track variable till I find where the code starts hanging, then fix the problem.

Obvioulsy some pointer is not accessedd properly, or some device context is not being released.

Use AfxMessageBox, and track down where the code executes properly just before bombing then you can breakit down better.


... hope that helps.

Quote:

---

Originally Posted by souldog

Correct me if I am wrong, but if the base class has a virtual destructor then any derived class will have an implied virtual destructor, even if you don't explicitly declare
it that way. In other words it does not matter if you don't declare the destructor
virtual, although it is good documentation.

---

You are right, not just destructors but all virtual functions. In this case, CObject has a virtual destructor, which CView is a descendant of.

Quote:

---

Originally Posted by Kibble

Alright, sorry for so many posts. I seem to have solved it by simply maintaining my own active view and document pointers, and not ever calling the SetActiveView MFC member function. I assume MFC was trying to do something with this pointer, yet it doesn't maintain it? that seems pretty obnoxious to me, I must be doing something else wrong.

---

I have to say that I do the same thing, I manage the views myself, although I am using a SDI application with several views. (I always just ignore the document
anyway)

Oh and if you are using an MDI, then I think you want to be using
MDIActivate(CMDIChildWnd* blah);

So you activate the child frame window.

I think the framework will keep track of the active view for you

Quote:

---

Originally Posted by ADSOFT

You know, I have been coding for 10 yrs now, I never use debug or diagnostic tools, why, because in C++ it's usually a memory problem.

.

---

You probably shouldn't be admitting that.
;) :D

Quote:

---

Originally Posted by ADSOFT

You know, I have been coding for 10 yrs now, I never use debug or diagnostic tools, why, because in C++ it's usually a memory problem.

What I have found works great for debugging and how I debug is I use:

CString msg
msg.Format (" Accessing code sectiong %s, %d, %c", somestring, someint, somechar);
AfxMessageBox(mst);

---

These things may have helped you, but they are not recommended for debugging memory related issues and window procedure/messaging issues.

1) The CString class allocates memory. If you've corrupted the heap before you declare the CString, you are accessing an invalid heap to create the CString.

2) AfxMessageBox() -- If you are having an issue with messaging in your window procedure, AfxMessageBox() (or even the API MessageBox) function may invoke behavior of your application that is undesired.

To circumvent both these problems, you may want to use a locally defined char buffer, sprintf(), and use OutputDebugString instead of AfxMessageBox.

Code:

---

{
  char sz[100]; // or whatever you feel is large enough for your message
  sprintf(sz, "%d", whatever);
  OutputDebugString( sz ):
}

---

This is what I use, and has the least impact on a possible memory access bug or messaging issue.

Regards,

Paul McKenzie

Hmmmm... I always use _CrtDbgReport(...) or one of the macros _RPT#

I tried replacing some things with the MDIActivate function, I still had some trouble. My manually maintained pointers do what I need, and don't cause a crash, so I'm going to stick with them. Thanks for the help everyone.

Quote:

---

Originally Posted by souldog

You probably shouldn't be admitting that.
;) :D

---

Your right, honest is not always the best policy, but AfxMessageBox, printf (for console apps) and getch(), have always worked for me.


What is cool about AfxMessageBox and any function where you can stop the computer program and display variables is 90 % of debug. Of course it doesn't help for memory leaks.




I seen people dislplay all kinds of error messages and talk about debugers, and I just think, well obviously I have to put my AfxMessageBox somewhere before that happens and work it back.

..... I think you get the point :) :)