Debugging a Release Build?
I've had this sort of thing happen to me in the past, and for me it's usually caused by variables not being properly initialised. When run through the debugger in VS, it will generally automatically initialise your uninitialised variables, but when you run the .exe independently, this won't occur. I don't know if this is your problem, but it may help.
I forgot one important piece of info on MiniDumps. You will need to locate dbghelp.dll and either stick that in your library search path, or copy it to the directory that contains your project's EXE. The MiniDump code uses dbghelp.dll to build the .DMP file.
Author
Thanks for all the suggestions!!
I'll get to work trying those out:)
And the crash that I'm getting is the fairly standard WindowsXP "...has encountered a problem and needs to close" With a Send or Do Not Send error report.
I'll get to work trying those out:)
And the crash that I'm getting is the fairly standard WindowsXP "...has encountered a problem and needs to close" With a Send or Do Not Send error report.
Author
I'm having a problem with that MiniDump code you posted the link too. I get a compile error saying it can't find "StdAfx.h"
I've been using _heapchk(), and have found that there's a heap corruption happening as I load the new map. I'm working on tracking down exactly where it happens
I checked that Generate Debug Info was turned on for Release builds, but I'm having a bit of a problem with I use Attach to Process and then try to step through with the debugger. In some places I can't get information on what's contained in the variables and/or it seems to skip over whole sections of code instead of steping over or into each function like I want.
example:
I've been using _heapchk(), and have found that there's a heap corruption happening as I load the new map. I'm working on tracking down exactly where it happens
I checked that Generate Debug Info was turned on for Release builds, but I'm having a bit of a problem with I use Attach to Process and then try to step through with the debugger. In some places I can't get information on what's contained in the variables and/or it seems to skip over whole sections of code instead of steping over or into each function like I want.
example:
ErrorMessage CGameMap::LoadFile(tstring filename, CItemManager *ItemManager){ //<<<<Instruction pointer is here. And I press F10 to Step Over ErrorMessage message; tstring itemfilename, TempItemName; tifstream Itemfile; COORD TempItemPos; //If there are any creatures currently loaded, delete them. ClearCreatures(); //It should be here next...but it's not it's down about 20 more lines //clear any items that might be on the map ClearItems(); //If string does not contain .bmp add it if(filename.find(_T(".bmp")) == npos) filename += _T(".bmp"); message = loadfrombitmap(filename); //Output error message if there was a problem if(Failed(message)) { switch(message) { case emBitMapDidNotLoad: { tstringstream ss; ss << filename << " Does not exist."; throw exFatal(ss.str().c_str(), message); } break; case emGeneralError: { tstringstream ss; ss << filename << " Contains undefined errors."; throw exFatal(ss.str().c_str(), message); } break; case emBitMapColorFailure: { tstringstream ss; ss << filename << " Contains invalid colors."; throw exFatal(ss.str().c_str(), message); } break; } } //load items if(filename.find(_T(".bmp")) != npos) { filename.erase(filename.find(_T(".bmp"))); } itemfilename = filename; itemfilename += _T("_items.txt"); Itemfile.open(itemfilename.c_str()); if(Itemfile) { while(Itemfile >> TempItemPos.X >> TempItemPos.Y >> TempItemName) { DWORD TempID; TempID = ItemManager->CreateItem(TempItemName); ItemManager->ChangeOwner(TempID, TempItemPos); InsertItemID(TempID, TempItemPos); //<<<< It jumps all the way down here } Itemfile.close(); } return message;}
Author
I tried that, it almost works after I added assert.h and windows.h, but it still can't find the LTCrashHandler type and I couldn't figure out what header it was in.
Author
Yay! I found it. There was a rare bug in my BitMap loading function that could cause one of the arrays to be overrun by 3 bytes. I still don't see why it didn't show up when I ran the game inside VS, but maybe VS does some check of array boundry checking?
Thanks again for everyone's help!!
Thanks again for everyone's help!!
Hmm, change all references of LTCrashHandler to CrashHandler and that should fix that.
Glad you found the bug!
Glad you found the bug!
>but maybe VS does some check of array boundry checking?
On the project properties page, check
Configuration Properties/C/C++/Code Generation/
Basic Runtime Checks and Buffer security check
On the project properties page, check
Configuration Properties/C/C++/Code Generation/
Basic Runtime Checks and Buffer security check
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
