The first thing I typically do is try stepping through a debugger in order to get a feel for what values are being passed to and returned from functions while program execution, but since you say running from within VC++ seems to make it run just fine, you'll have to subscribe to an equivalent form of the printf school of debugging. If you have some logging mechanism in place, just start adding debug log messages... log things like functions being called, parameters passed to functions, return values returned from functions (especially library calls... usually this can give you some indication what to look more closely at). Granted putting in debug log messages will change the runtime behavior of your program, it's still better than nothing (unless of course it alters the runtime behaviour in such a way that the bug goes away... those are particularly nasty bugs to catch). One other thing you may want to try, and I haven't done this so I'm not too keen on how its done, is run the game and attach a remote debugger to the instance of your game. You can then set watchpoints and/or breakpoints, which may or may not give you some idea of what's going wrong. Without anymore specific details on the nature of your bug and whether it consistently happens, it is hard to give anymore specific or helpful advice.

In my experience, it's one of these:
1. The debugger initializes values to some non-zero value, while the release one might not..
2. The debugger is slower, meaning the program runs slower, and takes longer to start. Right now I just can't figure out the scenario when I ran into this, but I do know it has happend.. Especially when dealing with threads this might happend (does any of your freeware libraries use threads?).

The first step is use whatever debugger you use, make it crash, then get a backtrace on what caused it. Then you can find out how to solve it.

I find it's easier to adopt good practices of the sort that make this class of bugs vanishingly rare. (This includes a lot of mostly simple things like using standard library containers and have specific idioms for using for-loops, declaring variables in a proper scope and near first use and initializing them with their first value; the occasional Boost widget; applying YAGNI - probably one of the most common sources of problems is needlessly making containers of pointers-to-object where containers of objects would suffice; refactoring the code to remove redundancy; etc. etc.)