views:

381

answers:

3

This is a fairly involved bug, and I've tried looking around to find other sources of help, but for reasons I don't understand, "Program Crashes in Vista" is not the most helpful query.

The issue I'm having is that the program I'm working on - a graphical, multithreaded data visualization software that uses OpenGL and the Windows API - is crashing after WinMain() returns. I've tried stepping through the shutdown routine as well as looking at a stack trace, and the last bit of code that's not assembly is _crtExitProcess, where it crashes in the actual ExitProcess(0) call. After that, the stack trace shows kernel32.dll and four ntdll.dll, which is where it actually crashes.

This bug only occurs on Vista, and the same exact code when run on XP exits normally. I really can't think of anything that would help me debug this problem, and debugging this issue is something I've never really learned. Any help would be appreciated.

+1  A: 

Sounds a little like a problem with a destructor.

Check for objects that are destroyed on shutdown. This will mainly be global or static objects. Look carefully at their destructors for a case of accessing something that is no longer valid. In a multi-threaded environment, it might be a race condition, where an object is destroyed while another thread is still using it.

Try writing a log as objects are destroyed. e.g.

SomeClass::~SomeClass()
{
    WriteLog("Begin ~SomeClass()");
    // do whatever
    WriteLog("End ~SomeClass()");
}

WriteLog() should open the log file, write and then close the file to make sure the file is flushed. Using a Mutex or CriticalSection to avoid conflicts would be a good idea.

Looking at the log after a crash might give you some clues as to what is going on.

If this is one of our destructors, wouldn't it appear in the stack trace? Also, what would the difference between Vista and XP be for this?
Andrei Krotkov
Destructors are quite C++-specific. They will be called from the C++ runtime.
MSalters
+1  A: 

I've done a little digging around, and I've found a couple of posts around that suggest you're not the only one suffering from this:

Particularly, the second one is of interest, where Tom Chm mentions:

We believe we have identified the root cause of our crash, and adding a virtual destructor to our interface class wrapper seems to resolve our problem. But we would like to know the exact cause of the crash to verify that we didn't just sweep the actual problem under the rug.

The problem may be with a destructor somewhere, or lack thereof. If you have a way of attaching a debugger and stepping through the shutdown process, it might be of help.

You might want to read through the whole thread and see if there's something you can learn. That is, if you haven't already found these posts in your searching, of course.

lc
http://support.microsoft.com/kb/941833That seems to very relevant, thank you! We can't run the update on this computer because it's for a client, but this can be something we can tell them to do. The bug looks identical to what we're having.
Andrei Krotkov
Hope you can get it all sorted relatively painlessly - this kind of bug is the hardest to figure out.
lc
A: 

what does the stack trace look like? can you provide an example (just strip everything sensitive w/o sacrifying the vital information)?