Bonjour Erasorz

Je la ferme par l'icone de menu qui fait faire Close(This) à la MDI principale

Oui

Quelques SetProfileString, 2 destroy de classe (une de ClientSideContext et une relié à une DLL servant aux notifications MOS de l'appli), quelques appels à une fonction de traçage dans la log, une GarbageCollect() que j'ai laissé pour l'instant et un StandardClose().

Le StandardClose() fait des SetProfileString et 5 If IsValid(Object) Then Destroy Object

Dernière modification par John77 (05-03-2013 13:45:13)

Oui, en faisant Shift+F1 dessus me suis rendu compte que c'était une user function, dsl.

Le StandardClose() fait des SetProfileString et 5 If IsValid(Object) Then Destroy Object, les Objects étant reliés à des DLL

Non, pas de Return explicite, la valeur de retour étant "none"

J'ai suivi cette piste toute l'après-midi mais il n'y a rien dans le destructor de la plupart des objets et le fait de les commenter me fait planter plus systématiquement.
Pour 2 d'entres eux, il y a un LoadLibraryA dans le constructor et un FreeLibrary dans le destructor (pour DEV.DLL et NOTIFICATION.DLL)

Les FreeLibrary pourraient-ils être la cause de mes problèmes?

Juste pour info, j'ai trouvé ça:

Préconisation du support Microsoft sur l'utilisation de Freelibrary

Peut-être qu'en remplaçant les LoadLibraryA par des LoadlibraryEx avec l'argument préconisé, tu n'auras plus le problème?

LOAD_LIBRARY_AS_DATAFILE=2

http://msdn.microsoft.com/en-us/library … 85%29.aspx

buck a écrit:

Bonjour,

Des crash intermittents en utilisant des fonctions de l'API externe, je pense que ton problème est tout simplement celui-la :
http://pbadonf.fr/forum/viewtopic.php?pid=29272

D'un autre côté, LoadLibrary n'a pas besoin de buffer, juste du nom de la dll...

John77 a écrit:

C'est quand même dommage qu'il n'y ait rien pour monitorer ces crashs et pouvoir comprendre ce qu'il se passe vraiment.

Ben si, il y a le debugger si l'assembleur ne te fait pas peur . Si tu as un Visual Studio installé sur le poste où ça plante, lorsqu'un message "L'application a cessé de fonctionner..." apparaît, la fenêtre a un bouton supplémentaire qui permet de "débugger" l'application fautive (en fait de débugger, ça permet de charger l'appli dans le debugger et se placer sur la ligne fautive).

Si tu n'as pas visual studio, OllyDbg peut le remplacer tout aussi bien pour la seule partie trace / debug. Comme tu n'as pas le code source de PB sous la main (si tu l'as tu m'intéresses ) tu ne pourras voir que des instruction en assembleur mais tu peux voir à quelle adresse ça plante, pour quel motif (access violation est classique, on cherche à lire / écrire à une adresse impossible), et l'affichage de la pile d'appel (partie en bas / droite de la fenêtre "cpu" reste intéressante car on peut parfois voir les appels qui ont précédé.

Dans cet exemple, ce sont les lignes en rouge qui sont intéressantes : on y voit des appels de fonctions successifs, et c'est lors d'un appel à WideCharToMultiByte que le plantage se passe (pendant ue conversion de texte unicode -> ansi. Dans ce cas là, Olly me montre même les paramètres d'appel de la fonction.


Un Dependency Walker en mode trace peut parfois aider (si c'est l'appel à une fonction de l'api pour la gestion des dll) mais ce n'est pas le meilleur outil.

Bon, j'ai réussis mais je reste perplexe devant le résultat



Unhandled exception at 0x10bf6145 in PB115.EXE: 0xC0000005: Access violation reading location 0x00000000.

Arf! pas vraiment parlant le truc et je ne connais pas bien VStudio

Il me donne le même nom écrit en haut de ma précédente image à côté de Stack Frame: PBSHR115.DLL

Merci beaucoup pour ces précisions Seki

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