Discussion :

[jlbrd]

Bonjour,

Sur le poste de certains utilisateurs, des fichiers .mdmp sont générés en grands nombre (plusieurs par minute parfois) et comme ils sont volumineux (263Mo) le disque des utilisateurs se rempli rapidement. Le nom des fichiers contient "MSVCRT" en plus du nom de mon application et de l'horodatage.

J'ai trouvé après recherche que ces fichiers sont des dump de débogage générés après un crash. Il me semble qu'ils ne ME servent à rien car on pourrait les ouvrir mais les sources correspondant (à msvcrt.dll à priori) ne sont pas disponibles. A noter que l'application ne plante pas. Lorsque c'est le cas et que c'est causé par un bug de l'application, un dump de débogage est généré par l'application elle même mais c'est tout autre chose:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
	// Code d'initialisation du projet
	QUAND EXCEPTION
		nomDump est une chaîne = fRepDonnéesUtilisateur() + ["\"] + RéseauUtilisateur()+"-"+ DateDuJour()+"-"+Gauche(Maintenant(), 4)+".wdump"
		dbgSauveDumpDébogage(nomDump)
		FinProgramme("Une erreur est survenue dans l'application. Afin que le problème soit analysé,", ...
		"merci de transmettre à l'équipe de développement le fichier ci-dessous :", nomDump)
	FIN

Si quelqu'un à une idée, merci

[R&B]

Bonjour

Proposer systématiquement un dump de débogage sur les exceptions est une bonne idée... mais compte tenu de leur volume il faut aussi prévoir de ne pas engorger le disque.
Il est alors sage aussi de prévoir un nettoyage de ces fichiers une fois devenus inutiles (suppression après un mois d'ancienneté).

Pour le msvcrt, il semble s'agir d'un problème de résolution du nom réseau sur ces postes. Il faut soit réparer la dll sur le poste soit trouver une autre identification du fichier (qui est soit dit en passant doublon avec la localisation).

Une solution consisterait à afficher une fenêtre et ne générer le dump que si l'utilisateur décide de le transmettre...

[jlbrd]

Bonjour,

Les dump de débogage générés sur les exceptions pourraient effectivement être volumineux mais ce n'est pas le cas car dès qu'un dump m'est transmis le bug est corrigé afin de régler le problème. Ces dump sont donc en fait assez rares. Je n'en n'ai pas reçu depuis des mois.

Ici le problème est différent : ce n'est pas un plantage du programme lui même. Cela semble plutôt se produire lors de l'appel par une DLL de Windev d'une DLL de windows, msvcrt.dll à priori dans le cas présent. C'est Windows lui même qui rattrape le problème et le programme ne plante pas.

En fait la solution m'a été donnée par le support technique. J'avais dans le code d'ouverture du projet:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

dbgInfo(dbgActiveDumpSystème)

et je crois que c'est la source de mon problème.

Pour le msvcrt, il semble s'agir d'un problème de résolution du nom réseau sur ces postes. Il faut soit réparer la dll sur le poste soit trouver une autre identification du fichier (qui est soit dit en passant doublon avec la localisation).

Je ne comprends pas trop ce que tu veux dire