C-based console app crashes when run from cmd.exe, runs fine in VS2008 debugger?

Question

Not sure what's going on here.
I have an Windows console app written in C. When I run it from within VS2008, it runs fine. If I run it from the cmd.exe prompt, it crashes, usually in malloc(). I am guessing it is a race condition due to a mismatched CRT library.

The app is simple.
It calls into the WinHttp layer to send a GET request to a website, then slurps up the reply. That part seems to work fine, but after WinHttpReadData, the program calls printf() to print out the data received, and that is where the malloc crash often occurs.

But only outside the debugger. ????

I am compiling from the command line.

c:\vc9\bin\cl.exe /Zi /DEBUG -Ic:\vc9\Include 
             -IC:\WindowsSDK\v6.1\Include  HttpGet.c 
             -link /debug /out:HttpGet.exe /SUBSYSTEM:CONSOLE  /LIBPATH:c:\vc9\Lib
              /LIBPATH:C:\WindowsSDK\v6.1\Lib  WinHttp.lib

I see the results above if I compile with /MT, or nothing. If I compile with /MD, then it hangs when run in the debugger, on a call to free(), and it crashes in cmd.exe (same as with /MT).

run in             result: /MT            result: /MD
---------          ------------           -----------
VS2008 debugger    runs fine              hang in free() (at the end)
cmd.exe            crash in malloc        crash in malloc
"VC cmd prompt"    crash or hang(spin)    ??

Some questions -

1. Is the different behavior because of the PATH available within VS2008?

2. Could the cause be that I don't have the VC90 runtime installed on my machine?

3. I thought that by linking statically (/MT) I wouldn't have the requirement of needing the VC90 runtime to be installed?

4. I still don't understand /NODEFAULTLIB. Is that relevant?

I am used to makefiles and compilers, and I know C. I don't know C++ which is why I write in C. But I don't understand all the vagaries of the CRT on Windows. Can someone clear up this mystery?

Answer 1

Typically when I've seen something work in the debugger but nowhere else, it's due to uninitialized memory. The debugger is "nice enough" to clear memory for you, as if that is doing you a favor.

The second possibility is a buffer overrun, and the debugger is causing the memory location of your mallocs to move around enough to avoid it. I would suspect this one given your failure is showing up during a malloc; you might be corrupting the malloc chain.

Another possibility that stands out is some sort of race condition, and the debugger is changing the timing enough to let you get away with it.