John77 a écrit:

Je viens de récupérer OllyDbg pour relancer le test.
Dois-je installer le Plugin Development Kit?

Merci pour tes efforts, mais je ne sais pas si je vais beaucoup t'avancer

Pour te présenter le décor avec Olly, voici ce que je peux te dire :
- dans la partie haut/gauche (desassembly) la ligne en surbrillance indique l'origine du crash : un test si une adresse mémoire et égale à 0. Il s'agit de l'adresse [eax] (contenue dans le registre eax). Malheureusement dans la liste des registres en haut à droite on ne voit pas eax, mais dans un message précédent tu indiques "Access violation reading location 0x00000000." donc eax = 0. Déréférencer un pointeur nul, un bug classique en C/C++
- dans la partie la plus instructive - la pile d'appel, on voit en haut la dernière fonction dans laquelle on se trouve : PbHeap_free de pbshr115.dll. PB est en train de libérer un bloc mémoir, mais l'adresse de bloc est nul et paf, plantage.
- tu peux voir en remontant la pile (mais en descendant la liste) que PB est bien en train de stopper l'exécution ( PBVM115.rt_stop_run rt = runtime) et je dirais que "conducteur" dont le nom apparaît dans les données de la pile ça doit être ton application.

Maintenant je ne peux que me perdre en conjectures : entre ob_set_runtime et PbHeap_free les fonctions ne sont pas nommées (pas disponibles en dehors de la dll pbshr) et il faudrait que je passe un moment avec un désassembleur pour savoir ce que c'est, mais on peut voir le nom de l'objet compilé w_finding.win (doit correspondre à la fenêtre w_finding) il pourrait être intéressant de vérifier si un objet utilisée dans cette dll (peut-être quelque chose en relation avec les dll que tu essaies de libérer à la fermeture) ne serait pas libéré une fois de trop ?

Il pourrait être intéressant d'ajouter des traces avec OutputDebugString lors du FreeLibrary() pour savoir si la lib est libérée avant ce crash.