#define ForceBreakpoint() __asm int 3

#ifdef _BREAKONASSERT
#define Assert(isTrue) _Assert( TEXT(__FILE__), __LINE__, (isTrue) ); ForceBreakpoint()

// cludge for getting the line number as a string
#define STRINGIZE(x) #x
// expands x then STRINGIZEs it
#define EXPAND(x) STRINGIZE(x)
// stringize line number by first expanding it
#define LINE_STR EXPAND(__LINE__)

// hacky callstack trace on exception
#define TRY(funcName) static string _message = TEXT(__FILE__) ## TEXT("(") ## 				TEXT(LINE_STR) ## TEXT(")") ## TEXT(" : stack unwinding in ") 				## TEXT(#funcName) ## TEXT("\n"); try {
#define CATCH } catch(...) { CallStackTrace.push_back( _message ); throw; }

// set to decent initial size to avoid bad_alloc throw
std::vector<string> CallStackTrace(2048);

• @err if the return value of GetLastError()


• @err,hr is the error message which is associated with @err


• p,n (p is a pointer, n is a literal constant (neither a symbolic one not a variable)) treats the pointer p as if it was an array of n entries, ie instead of displaying only the entry when you expand it. example: myvector._MyFirst,5 will display the 5 first entries of myvector (myvector is a std::vector<>).


• @clk is the clock. I read somewhere on the net that since watch are evaulated from top to bottom, you can do simple profiling while debugging your code by adding two watches: "@clk" and then "@clk = 0"


• if you are into asm, great news: the registers can be viewed from the watch window - just add the name of the register (eax, ecx, ...)


• postfixing a variable name with ,wm will treat this variable name as a windows message (ie it will display WM_COMMAND instead of 273)

Quote:

# Run the program in the debugger and do what you did to make the program crash again. The debugger should catch it this time, telling you that it has halted the program because "an unhandled exception of type 0xc0000005 has occurred: Access Violation" and a memory address. # Look at the memory address reported. If it's 0x00000000, or a very low value like 0x0000000B, then we're probably looking at a null pointer dereferencing. If it's a higher value like 0x00455CD2, then we're probably looking at a pointer corruption bug. # There are a few other special codes to look out for as well - values close to 0xCDCDCDCD, 0xCCCCCCCC or 0xBAADF00D indicate an uninitialised variable, while values close to 0xDDDDDDDD and 0xFEEEFEEE indicate recently deleted variables. If you see these in a pointer, it doesn't mean that the pointer is pointing to uninitialised or deleted memory - it means that the pointer itself is uninitialised or has been deleted. The other one to watch out for is 0xFDFDFDFD - it can indicate that you're reading past the beginning or end of a buffer.

Quote:

Original post by FBMachine The asm instruction int 3 when the program is attached to the debugger causes

Quote:

Original post by tksuoran Quote: Original post by FBMachine The asm instruction int 3 when the program is attached to the debugger causes Or you could simply use DebugBreak().

Quote:

Original post by soconne I found this section EXTREMELY useful. Quote: # Run the program in the debugger and do what you did to make the program crash again. The debugger should catch it this time, telling you that it has halted the program because "an unhandled exception of type 0xc0000005 has occurred: Access Violation" and a memory address. # Look at the memory address reported. If it's 0x00000000, or a very low value like 0x0000000B, then we're probably looking at a null pointer dereferencing. If it's a higher value like 0x00455CD2, then we're probably looking at a pointer corruption bug. # There are a few other special codes to look out for as well - values close to 0xCDCDCDCD, 0xCCCCCCCC or 0xBAADF00D indicate an uninitialised variable, while values close to 0xDDDDDDDD and 0xFEEEFEEE indicate recently deleted variables. If you see these in a pointer, it doesn't mean that the pointer is pointing to uninitialised or deleted memory - it means that the pointer itself is uninitialised or has been deleted. The other one to watch out for is 0xFDFDFDFD - it can indicate that you're reading past the beginning or end of a buffer.