Odd problem

It's possible but I doubt it.
If you right click on the dlls without symbols, you get the option to download the symbols from MS symbol server. Once you've done this, look at your entire stack trace for a dll you do recognize. Specifically, one of the 11 dlls you said you are loading yourself. It's almost certain the culprit is one of those.

You could also use another tool like Process Monitor to help debug this. Do you have any global variables in your code? Their constructors run before main(), and a bug in such a constructor could cause something like this.

I do have some global vars. I don't know how any of them can cause a freezeup.
[/quote]
It depends. It is a good idea to minimise the amount of complex code that runs before main, and a better idea to eliminate it entirely.

None of them are included in main.cpp, as I've commented out the include, so none of them should affect the 'short' version.
[/quote]
#include doesn't matter here. It only affects global declaration visibility in other translation units - not global definitions in the final executable.

Edit: Oh what the .... ! I just ran release version, with the truncated main.cpp, and it ran fine! I quickly uncommented the rest, and... back to the same problem. This now points to something caused by the code.. but the exact same code won't run in debug. Basically: In debug, no version of main.cpp runs. In release the 'short' version that only spits a single line runs, but the full doesnt. I also stopped it mid-run in release mode, only to see that it says no symbols were loaded for kernel32.dll......
[/quote]
Compilers are allowed remove unused global variables - even if this means that constructors with side effects won't run. I suspect that in Release mode, the optimiser is doing this to one or more of your global variables.

<snip>
Compilers are allowed remove unused global variables - even if this means that constructors with side effects won't run. I suspect that in Release mode, the optimiser is doing this to one or more of your global variables.

Here's one more thing you could do to help track down the issue: When it's stopped in the debugger look at the threads window, and check the call stack for each thread. Because it's stopped on a WaitForSingleObject there's probably more than one thread involved here.

My guess would be that it's getting deadlocked on the Windows DLL loader lock.

On 9/7/2011 at 1:59 PM, MilchoPenchev said:

//#include "Game.h"
//#include "stdlib.h"
#include <iostream>
int main(int argc, char* argv[])
{
    std::cout << "MAIN IS ON!\n";
    // Create a Game object
//  Game *pGame = new Game();
//  // start the Game
//  int error = pGame->Start();
//  if ( error != 0)
//  {
//      std::cout << "Game could not start...\n";
//      system("pause");
//  }
//  return error;
}

Ok, now that you've resolved the issue, I think it's ok for me to be a jerk and point out that your main() (when un-commented-out) has a resource leak. ;^)

Ok, now that you've resolved the issue, I think it's ok for me to be a jerk and point out that your main() (when un-commented-out) has a resource leak. ;^)