First-chance exception in myprog.exe (MFC42D.DLL): 0xC0000005: Access Violation.

Bonjour,

J'ai beau triturer toutes les options, chercher sur le net, je ne comprend pas pourquoi mon programme (en fait c'est pas le mien mais j'en reprend un qui marche pourtant) ne fonctionne pas en debug :

First-chance exception in myprog.exe (MFC42D.DLL): 0xC0000005: Access Violation.
Il s'arrête dans le WINMAIN.cpp ici :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

// App global initializations (rare) if (pApp != NULL && !pApp->InitApplication()) goto InitFailure; // Perform specific initializations if (!pThread->InitInstance()) { if (pThread->m_pMainWnd != NULL) { TRACE0("Warning: Destroying non-NULL m_pMainWnd\n"); pThread->m_pMainWnd->DestroyWindow(); } nReturnCode = pThread->ExitInstance(); goto InitFailure; } nReturnCode = pThread->Run();

---

Merci de me dire quelles options changer (le code doit fonctionner puisque l'exe en release fonctionne) pour pouvoir le faire fonctionner en debug.
:tagcode:

Citation:

---

Envoyé par stof

Bonjour,

J'ai beau triturer toutes les options, chercher sur le net, je ne comprend pas pourquoi mon programme (en fait c'est pas le mien mais j'en reprend un qui marche pourtant) ne fonctionne pas en debug :


Merci de me dire quelles options changer (le code doit fonctionner puisque l'exe en release fonctionne) pour pouvoir le faire fonctionner en debug.

---

0xC0000005: Access Violation signale un bug, en debug ce probléme devrait être facile à résoudre.
ton argument n'est pas valide, ce n'est pas parce qu'un programme semble fonctionner dans un mode qu'il est exempt de bug.

Bonjour,

Certes mais si je fais un main vide, ça plante quand-même dès le début donc j'ai même pas le temps de trouver un bug dans les fichiers du programme qu'il est déjà arrêté

Des idées?

Je rejoins Farscape, si ton programme plante, c'est forcément une problème de ton code avant d'être un problème d'options Debug/Release.

Il pointe sur quoi pThread?

Ben pThread est NULL c'est pour ça qu'il y a cette erreur, mais moi je ne sais pas débugger des fichier Windows...

pThread vient de AfxGetThread qui cherche
CWinThread* pThread = pState->m_pCurrentWinThread;

mais je ne sais pas pourquoi ça fait ça.

Ben tu as alors ta réponse, si ton AfxGetThread() te renvoie NULL, c'est que tu n'es pas dans un thread. Si tu veux un pointeur sur l'application utilise plutôt AfxGetApp().

Citation:

---

Envoyé par stof

mais je ne sais pas pourquoi ça fait ça.

---

un conseil : avant de chercher pourquoi ça plante, cherche à comprendre ce que fait le programme.

Argh, mais ce n'est pas dans mon fichier ce code, c'est dans WINMAIN.CPP...

(d'ailleurs vc'est bien ce que fait la fonction AfxGetThread d'appeler ensuite cette fonction AfxGetApp() si pThread est NULL.

Mais qu'est-ce que je fais là-dedans! Pourquoi ce simple début de main pose problème?

Mais dans ton code quand tu l'exécutes en DEBUG, y'a bien un moment où tu appelles la méthode de WINMAIN.cpp qui te fait planter??? D'ailleurs c'est quelle fonction?
Au moment du plantage, remonte la pile des appels pour voir laquelle de tes fonctions génère le plantage.

Mais le main (je supprime tout ce qui est fait dedans) c'est :
int main()
{
return 0;
}

C'est bien en remontant la pile des appels que je finis dans WINMAIN.CPP.

Au debut il y a :KERNEL32!
Puis :
WinMainCRTStartup

Code:

---

1 2 3 4 5 6 7 8 9

mainret = WinMain( #endif /* WPRFLAG */ GetModuleHandle(NULL), NULL, lpszCommandLine, StartupInfo.dwFlags & STARTF_USESHOWWINDOW ? StartupInfo.wShowWindow : SW_SHOWDEFAULT );

---

Puis
WinMain
Puis AfxWinMain

Pffffffff... je désespère.

Quand tu dis qu'il marchait avant, c'était toi qui le faisait marcher? C'était sur la même machine? Sous quelle IDE es-tu?

Il marche quand je produit l'exécutable et qu'un batch l'appelle ensuite mais je n'arrive pas à le faire fonctionner en debug sous Visual.

Ce n'est pas une question de code puisque je fais un main vide et j'ai le problème.
C'est des histoires à la c... d'options à mon avis, les debug Multithread DLL, ce genre de chose.

Moi je ne connais que la programmation en C, les outils comme ça ça me dépasse complètement.PS: Visual 6.0 sous Windows NT mais je ne pense pas que ça soit important pour mon problème.

Bon, et bien je ne suis pas plus avancé que sur les autres sites. :(

Même problème ici.
Je vais rajouter des informations, parce que je pense que beaucoup de gens n'ont pas compris le fond du problème: le programme plante avant qu'aucune ligne de code dans le programme lui-même ne soit exécutée. Voici la pile que j'ai récupérée après un crash:

Code:

---

1 2 3 4

[1] AfxWinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00132da8, int 1) line 39 + 3 bytes [2] WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00000000, char * 0x00132da8, int 1) line 30 [3] WinMainCRTStartup() line 198 + 54 bytes [4] KERNEL32! 7c4e87f5()

---

[1] MFC\SRC\WINMAIN.CPP

Code:

---

1 2 3 4 5 6 7 8 9 10 11

// Perform specific initializations --> if (!pThread->InitInstance()) { if (pThread->m_pMainWnd != NULL) { TRACE0("Warning: Destroying non-NULL m_pMainWnd\n"); pThread->m_pMainWnd->DestroyWindow(); } nReturnCode = pThread->ExitInstance(); goto InitFailure; }

---

[2] MFC\SRC\APPMODUL.CPP

Code:

---

1 2 3 4 5 6 7

extern "C" int WINAPI _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow) { // call shared/exported WinMain return AfxWinMain(hInstance, hPrevInstance, lpCmdLine, nCmdShow); --> }

---

[3] Quelque part dans le code Microsoft, beaucoup d'assembleur, réclamez si vous voulez que je vous l'envoie dans la face :P
[4] idem




Comme vous pouvez le voir, le programme n'a pas encore été exécuté, on se trouve encore dans les routines d'initialisation Made In Microsoft. La dernière fois que j'avais eu un problème de ce genre, je n'avais en fait pas déclaré d'instance unique pour la class CWinApp. Le problème est que dans ce contexte, je ne vois pas trop comment créer ce machin (il est déjà sensé y avoir une fonction main).
Pour information, mon système est Visual Studio 6.0 sous Windows 2000, et j'utilise SDL 1.2.4 .

T'as vérifiés les versions de tes dépendances (MFC, CRT,...)?

Je ne pense pas que ça ait de rapport: j'ai récupéré un vieux projet utilisant SDL qui marchait à ma connaissance. Je l'ai compilé et exécuté avec exactement le même environnement, et il a démarré sans crasher. Donc plutôt une histoire d'option perdue dans un coin du projet à trouver à mon avis... Qui est partant pour une partie de cache-cache? :roll:

Citation:

---

Envoyé par fafner2000

Je ne pense pas que ça ait de rapport

---

Tu en es sûr?
Tu postes sur un forum d'entraide pour que des personnes bien intentionnées te donne des idées et t'aident à résoudre un problème. Quand on te propose quelque chose, si l'idée te plaît pas, tu balayes de la main en attendant autre chose. Pas très judicieux je trouve... :nono:
Allez, ça te prends 2s, regarde les dépendances de ton exécutable ou de ta dll et vérifie qu'il voit bien toutes les librairies nécessaires.
C'est peut-être pas ça le problème, mais au moins tu auras éliminé une source d'erreur possible.

Bon courage

si tu ton projet n'est pas gros, tu n'as qu'a le poster en .zip
(vire le .ncb ,.pch etc ).
ça nous permettra de raisonner sur des éléments concrets ...

Citation:

---

Envoyé par spoutspout

Tu en es sûr?
Tu postes sur un forum d'entraide pour que des personnes bien intentionnées te donne des idées et t'aident à résoudre un problème. Quand on te propose quelque chose, si l'idée te plaît pas, tu balayes de la main en attendant autre chose. Pas très judicieux je trouve... :nono:
Allez, ça te prends 2s, regarde les dépendances de ton exécutable ou de ta dll et vérifie qu'il voit bien toutes les librairies nécessaires.
C'est peut-être pas ça le problème, mais au moins tu auras éliminé une source d'erreur possible.

---

Ah là là, je postais surtout pour donner des informations supplémentaires, pas spécifiquement pour avoir de l'aide (du moins pas encore, je suis encore en train de chercher), et je me fais taper sur les doigts :roll: J'avais donné une raison (bonne à mon avis, mais je peux me tromper il est vrai) pourquoi je ne pensais pas que ce soit un problème de version de librairies ;) Enfin puisque tu insistes je vais jeter un coup d'oeil, ça coûte pas cher comme tu dis :D
Concernant le problème en lui-même, je pense avoir trouvé l'origine du problème, enfin en quelque sorte... Le problème ne se produit que quand je compile avec SDL 1.2.4 , mais pas quand je compile le même projet avec SDL 1.2.11 . Bizarrement, une fois le projet compilé la version de la librairie SDL.dll n'a pas d'importance, le plantage n'aura de rapport qu'avec la version avec laquelle le projet a été compilé. Si je compile avec la version 1.2.4 , je peux essayer de faire tourner le programme avec la version 1.2.4 ou 1.2.11 de la dll, ça ne marchera pas. Si je compile avec la version 1.2.11 , je peux faire tourner le programme avec la version 1.2.4 ou 1.2.11 de la dll , ça marchera dans les 2 cas. D'où mon idée que ce n'est finalement pas un problème d'option perdue dans un coin, mais plutôt une histoire de vieille version de développement de SDL. Upgrader la version de développement de SDL devrait donc corriger le problème.
En ce qui me concerne, je suis bloqué avec la version 1.2.4 pour diverses raisons, je sens que le boss va être hyper content :aie: