Violation d'accès en écriture

Code:

---

Exception de première chance à 0x58b83216 dans JomPred.exe:0xC0000005: Violation d'accès lors de l'écriture à l'emplacement 0x00463014.

---

comment déterminer ce qui provoque cette erreur :oops:

En utilisant le débogueur.

pinaise, j'aurais demandé, j'aurais pas eu mieux ^^

je m'attendais plus à un style d'erreur commun qui génère ce message... genre une aide sur l'orientation de la recherche...

Code:

---

1 2 3

CCommandLineInfo cmdInfo; ParseCommandLine(cmdInfo); if (!ProcessShellCommand(cmdInfo)) return FALSE;

---

je n'ai pas le warning juste avant le if, et je l'ai apres.... j'imagine que j'y peux pas grand chose alors (j'ai essayé pendant 30mn de tracer, mais ça passe dans une 20 aine de fichier annexe .cpp ou .asm qui ne m'aident pas beaucoup)

tu compiles et link ton projet en mode debug .
tu lances ton projet en mode debug trace .(F5)
et tu debug l'erreur en remontant la pile des appels jusqu'a ton code qui provoque l'erreur.
voir aussi faq:
http://c.developpez.com/faq/vc/?page...gPointeurValue

:D

je l'ai fait (voir juste au dessus), meme qu'apres, comme dit plus haut, avec F11 je me balade dans des dizaines de fichier

je parlais plus du style d'erreur courante qui pourrait générer ce warning


un peu comme dans un dialog dérivant de CDialog, si on omet this->DestroyWindow(), on peut avoir des Warning: calling DestroyWindow in CDialog::~CDialog -- OnDestroy or PostNcDestroy in derived class will not be called

enfin bref, apparemment c'est un truc "quelque part" qui ne change rien à mon projet et que j'arrive pas à détecter, donc bon....

on va le dire autrement.
si tu lances ton programme en Debug trace ,tu as l'erreur 0xC0005 oui ou non ?

le message que j'ai mis plus haut arrive juste après le passage de la fonction citée

je compile pratiquement que en DEBUG. Je génère une Release par soir, et c'est tout. En général le debug active le tracage et dump pour repérer les trucs comme les memory leaks, alors pkoa compiler en release tant que c'est pas fini ;)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

// Inscrire les modèles de document de l'application. Ces modèles // lient les documents, fenêtres frame et vues entre eux CSingleDocTemplate* pDocTemplate; pDocTemplate = new CSingleDocTemplate( IDR_MAINFRAME, RUNTIME_CLASS(CJomPredDoc), RUNTIME_CLASS(CMainFrame), // fenêtre frame SDI principale RUNTIME_CLASS(CJomPredView)); if (!pDocTemplate) return FALSE; AddDocTemplate(pDocTemplate);   // ############################## // LIGNE DE COMMANDE DE LANCEMENT // ############################## // Analyser la ligne de commande pour les commandes shell standard, DDE, ouverture de fichiers CCommandLineInfo cmdInfo; ParseCommandLine(cmdInfo);   // Distribue les commandes spécifiées dans la ligne de commande. Retourne la valeur FALSE si // l'application a été démarrée avec /RegServer, /Register, /Unregserver ou /Unregister. if (!ProcessShellCommand(cmdInfo)) return FALSE; // ##############################   // on cache de base la fenêtre pour que le splash soit affiché seul à l'écran m_pMainWnd->ShowWindow(SW_HIDE); m_pMainWnd->UpdateWindow();

---

un point d'arret sur :
if (!ProcessShellCommand(cmdInfo)) return FALSE;

la fenetre de sortie : aucune erreur

je presse ensuite F10 pour passer au 2e point d'arret (le showwindow qui cache la fenetre principale pour laisser le splashscreen)

la fenetre de sortie : erreur violation bidule


bref, c'est donc dans if (!ProcessShellCommand(cmdInfo)) return FALSE; ou les lignes de commentaire ou quelque chose en parallele qu'il y a une erreur

mais le F11 sur le 1er point m'envoie balader dans des fichiers comme appui2.cpp, afxstate.cpp, afxtls.cpp, etc... bref, meme s'il y avait une erreur la dedans, ça ne serait du qu'à quelque chose de mon programme... (genre une variable appelé depuis ces fonctions)

la seule chose que je vois c'est que j'ai giclé les menus New, Open etc cie (je ne traite pas fichier), et que la ligne de commande faisait peut être appel à quelque chose que j'ai mal nettoyé...

mais rien de grave je suppose

si ça plante sur ProcessShellCommand
verifie ta view .
met un point d'arret dans le constructeur.
puis OnInitialUpdate.
et trace pas a pas.
verifie aussi la construction de ta mainframe.
n'empeche que :
ça serait pas mal d'avoir aussi la ligne de code sur laquelle l'assertion apparait....