Pourquoi ne puis-je pas tester le code retour sous Windows 7?

Question

J'ai un programme très compliqué qui échoue, et je l'ai simplifié à cet ensemble de test avec un fichier batch et un programme C.

Mon programme C utilise ExitProcess pour renvoyer le niveau d'erreur à un fichier de traitement par lots. Parfois, sur Windows 7 (Microsoft Windows [Version 6.1.7600]), le niveau d'erreur n'est pas interprété correctement.

Je pense que cela devrait fonctionner pour toujours. Sous Windows XP, il semble fonctionner éternellement. Sur deux machines Windows 7 dual-core différentes (une 64-bit 32 bits) il échoue en quelques minutes.

Je ne peux pas imaginer que je fasse quelque chose de mal, mais au cas où il y aurait quelque chose d'amusant à propos de ExitProcess sur Windows 7, j'ai pensé que je demanderais. Y a-t-il quelque chose que j'ai fait illégalement?

fichier batch pour test.bat cmd.exe:

@ECHO OFF 
SET I=0 
:pass 
SET /A I=I+1 
Title %I% 
start/wait level250 
if errorlevel 251 goto fail 
if errorlevel 250 goto pass 
:fail 

Programme level250.c:

#include "windows.h" 

static volatile int Terminate = 0; 

static unsigned __stdcall TestThread(void * unused) 
    { 
    Terminate = 1; 
    return 0; 
    } 

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpszCmdLine, int nCmdShow) 
    { 
    CreateThread(NULL, 0, TestThread, NULL, 0, NULL); 

    while (Terminate == 0) Sleep(1); 
    ExitProcess(250); 
    } 

Ma version du compilateur et appel sont:

Microsoft (R) Compilateur d'optimisation C/C++ 32 bits Version 12.00.8804 pour 80 x 86

Droit d'auteur (C) Microsoft Corp 1984-1998. Tous les droits sont réservés.

cl/MT level250.c

Autres informations: J'ai également essayé de courir sous TCC JPSoft et obtenir le même comportement que l'utilisation de CMD. J'utilise un programme .c droit, pas .cpp. Je ne vois aucun échec dans une seule version filetée. Je mets les sources et les binaires sur http://jcook.info/win7fail et le fichier zip MD5 est 579F4FB15FC7C1EA454E30FDEF97C16B et CRC32 est C27CB73D.

EDIT Après des suggestions, j'ai encore modifié le cas de test et toujours voir les échecs. Dans notre application actuelle, il y a des centaines de threads. Certains threads sortent avec divers codes de retour significatifs, certains sont exécutés pour toujours et certains sont bloqués dans les appels du système d'exploitation ou les DLL et sont difficiles (voire impossibles) à tuer.

#include "windows.h" 

static unsigned __stdcall TestThread(void * unused) 
    { 
    return 0; 
    } 

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpszCmdLine, int nCmdShow) 
    { 
    CreateThread(NULL, 0, TestThread, NULL, 0, NULL); 
    return(250); 
    } 

Answer 1

Imprimer ce que le code de retour fait est. Il n'y a aucune garantie que si quelque chose ne va pas, vous obtiendrez les 251 et 250 que vous attendez, comme une erreur de segmentation ou d'autres erreurs dont vous n'êtes pas conscient. En outre, je ne peux pas voir où vous retournez 251 dans votre code. Méfiez-vous des codes de sortie élevés, je crois 255 est limite portable, sur certains systèmes il peut être inférieur à 64, ou < = 127. (Cela peut être hors de propos vu que vous utilisez évidemment Windows, mais il vaut la peine de noter.)

Essayez également d'invoquer un débogueur ou de charger un core dump lors de la mort inattendue du processus.

Answer 2

Il semble retourner le résultat du thread dans les temps où il échoue. J'ai changé la valeur de retour du fil à 37 et ajouté echo %errorlevel% à la fin du fichier de commandes. Quand il s'est arrêté sur mon PC, il a imprimé 37. Donc il semble qu'il y ait une sorte de problème de synchronisation.Pour résoudre ce problème, je l'ai changé le code principal à ce qui suit:

HANDLE h = CreateThread(NULL, 0, TestThread, NULL, 0, NULL); 
while (Terminate == 0) Sleep(1); 
WaitForSingleObject(h, INFINITE); 
ExitProcess(250); 

La documentation ExitProcess dit clairement que le code de sortie est « pour le processus et toutes les discussions ». Donc, il semblerait qu'il y ait un bug, cependant, s'appuyer sur ExitProcess pour tuer tous les threads ne semble pas être le meilleur plan. Donc, attendre leur fin est probablement une ligne de conduite raisonnable.

J'ai construit le programme et reproduit le problème avec VC6 (la version que vous avez utilisé je crois), VS2005, et VS2008. Je l'ai couru, par curiosité, sur un ordinateur portable win7 à 2 cœurs et un ordinateur de bureau win7 à 4 cœurs. Il ne se reproduisait pas sur une machine XP hyperthreaded plus ancienne, mais cela ne veut pas dire que ça ne finirait pas par échouer; peut-être qu'il fallait juste courir plus longtemps là-bas. Ce serait un peu de kludge, mais peut-être une solution de contournement serait de stocker le code de sortie dans une variable globale dans l'application et de renvoyer cette valeur de tous les threads. Ensuite, dans la situation où ce problème/bug se produit, le code de sortie de l'application serait toujours la valeur souhaitée.