application se bloque console-C lorsqu'il est exécuté de cmd.exe, fonctionne très bien dans le débogueur VS2008?

Question

Je ne sais pas ce qui se passe ici.
J'ai une application console Windows écrit en C. Lorsque je le lance à partir de VS2008, il fonctionne très bien. Si je le lance à partir de l'invite cmd.exe, il se bloque, le plus souvent dans malloc (). Je suppose que c'est une condition de course en raison d'une bibliothèque CRT ne correspondent pas.

L'application est simple.
Il appelle dans la couche winhttp pour envoyer une requête GET à un site Web, slurps puis la réponse. Cette partie semble fonctionner très bien, mais après WinHttpReadData, le programme appelle printf () pour imprimer les données reçues, et qui est l'endroit où l'accident malloc se produit souvent.

Mais seulement en dehors le débogueur. ????

Je suis compilerai de la ligne de commande.

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

Je vois les résultats ci-dessus si je compilez avec / MT, ou rien. Si je compilez avec / MD, puis il se bloque lorsqu'il est exécuté dans le débogueur, un appel à libérer (), et il se bloque dans cmd.exe (comme avec / 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)    ?? 

Quelques questions -

1. Le comportement différent en raison de la voie disponible au sein VS2008?

2. Peut-être la cause que je n'ai pas le temps d'exécution de vc90 installé sur ma machine?

3. Je pensais que en liant statiquement (/ MT) Je ne serais pas l'exigence d'avoir besoin l'exécution de vc90 à être installé?

4. Je ne comprends toujours pas / NODEFAULTLIB. Est-ce pertinent?

Je suis habitué à makefiles et compilateurs, et je sais que C. Je ne sais pas C ++ qui est la raison pour laquelle je vous écris en C. Mais je ne comprends pas tous les caprices du CRT sur Windows. Quelqu'un peut-il éclaircir ce mystère?

Answer 1

En général quand je l'ai vu le travail de quelque chose dans le débogueur, mais nulle part ailleurs, il est dû à la mémoire non initialisée. Le débogueur est « assez bien » pour effacer la mémoire pour vous, comme si cela vous fait une faveur.

La seconde possibilité est un dépassement de mémoire tampon, et le débogueur est à l'origine de l'emplacement de mémoire de votre mallocs pour se déplacer autour d'assez pour l'éviter. Je soupçonne que celui-ci compte tenu de votre échec est montrant au cours d'une malloc; vous pourriez corrompre la chaîne malloc.

Une autre possibilité qui se démarque est une sorte de condition de course, et le débogueur est en train de changer suffisamment temps pour vous permettre de sortir avec elle.