Bug programme Delphi sur certains XP

Version imprimable

08/12/2006, 09h58
Philippe85

1 pièce(s) jointe(s)

Bug programme Delphi sur certains XP

Y a t il des DLL ou autre à déployer en sus d'un programme Delphi Win32 et où ?

Après moult recherche dans la doc, sur le net, tests et invocations diverses, je poste ma première question ici en espérant ne pas faire d'impair.

Mon programme en Delphi 2005 est distribué, et ne posais aucun problème sous 2000 et antérieur, et XP jusqu'à présent. Le programme est en téléchargement si besoin, et source joint. Le programme utilise peu de composants de la VCL, et normalement une seule DLL distribuée : Midas. Et l'installation est minimale, mettre le programme, sa dll, son fichier d'aide dans un même répertoire, peu importe où.

Un des utilisateurs (La Réunion) ayant des problèmes sous XP, et après test sur des machines persos j'en ai trouvé une qui reproduit la même panne. Sous XP, dès le démarrage du programme Erreur EAccessViolation ou Runtime error 216 suivant les machines. J'ai essayé de trouver les dépendances, tracer avec un vieux TurboDebugger et n'ose raconter le reste ...

A la fin, j'installe Delphi 2005 sur le poste pour le debugger, et là le programme fonctionne sans modification. Quelques tests plus tard, il semble que si midas.dll n'est pas dans system32, cela ne fonctionne pas sur ce poste. Mais c'est pas suffisant pour mon dépannage, car après avoir mis midas dans le bon répertoire chez mon utilisateur la panne persiste.:cry:

Donc une curiosité, il semble que sous certains XP, la recherche de DLL ne se fait pas dans le répertoire du programme.

La question est donc connaissez vous d'autres éléments indispensable à installer avec le programme principal et donc à redistribuer, voire d'autre piste même comme façon de chercher l'erreur.

Merci
08/12/2006, 21h33
LadyWasky

Ne serait-ce tout simplement pas une histoire de droits administrateurs ou autres sur la machine ?

En tout cas je jette un oeil et te tiens au courant.

En tout cas, bienvenue sur notre forum. ;)

PS : aurais-tu les .dfm et le .dpr ? parce que sans ça, ça va être coton pour débugguer...:roll:

Edit : j'ai essayé ton exécutable sur ma machine, j'ai ouvert un fichier texte au hasard baltazar, et il n'a pas planté.
09/12/2006, 12h05
edam

normalement si une dll manque le system vous informe en vs donnant directement son nom
12/12/2006, 15h48
Drezounet

Est ce que l'utilisateur possede un P4 HyperThreadé ?

Car si c'est le cas, un message sur la FAQ en parle :
http://www.developpez.com/delphi/faq...timeerror216p4

Moi j'ai le meme probleme, mais les choses données pour corriger l'erreur ne fonctionnent pas chez moi... c'est depuis que j'ai rajouté des composants ADO dynamique qu'il crash
12/12/2006, 16h01
LadyWasky

Oui et chez microsoft et ailleurs, il semblerez que la cause puisse aussi être :
- un problême de disque dur
- un problème de carte graphique (GeForce 4mx)
- Un problème de spyware ou plus particulièrement le Trojan SubSeven
http://support.microsoft.com/kb/259279
- Un problême de pilote de souris
http://support.microsoft.com/kb/189989

Comme je n'ai pas réussi à faire planter ton programme chez moi, ça m'a l'air tout bon coté code ;)
12/12/2006, 17h22
Drezounet

J'ai reussit a corriger mon erreur de runtime. Elle etait liée à un free() situé dans du code finalize alors que l'objet n'avais pas été instancié. :P
13/12/2006, 08h22
Philippe85

1 pièce(s) jointe(s)

Citation:

Envoyé par waskol

Ne serait-ce tout simplement pas une histoire de droits administrateurs ou autres sur la machine ?

En tout cas je jette un oeil et te tiens au courant.

En tout cas, bienvenue sur notre forum. ;)

PS : aurais-tu les .dfm et le .dpr ? parce que sans ça, ça va être coton pour débugguer...:roll:

Edit : j'ai essayé ton exécutable sur ma machine, j'ai ouvert un fichier texte au hasard baltazar, et il n'a pas planté.

Non, il ne s'agit pas de droit administrateur. Sur mon PC (domicile) je suis administrateur et j'avais le même problème.
Et cela ressemble plus à des DLL manquantes et/ou des inscriptions dans la base de registre et/ou un nème utilitaire Microsoft, car les problèmes rentre dans l'ordre quand j'installe Delphi sur le poste. Mon idée première était plus dans les éléments à redistribuer bpl, BDE ...
Mais je sèche autant sur la méthode comment debugger un programme sur un poste X sans installer Delphi.

Ci - joint les fichiers oubliés dfm et dpr.
13/12/2006, 08h27
Philippe85

Citation:

Envoyé par edam

normalement si une dll manque le system vous informe en vs donnant directement son nom

Justement non, un des tests a été de renommer midas.dll dans system32 et le programme fait exactement la même chose Runtime error 216, sans indiquer quoique ce soit de plus. Mais, ce n'est pas suffisant car en copiant la dll dans systeme32 sur le poste en panne, le problème persiste.

Merci
13/12/2006, 08h41
Linkin

Pour l'histoire de Midas.dll, j'ai inclus MidasLib dans les uses pour éviter d'avoir à la distribuer.
13/12/2006, 10h48
dd16

Normalement, lorsqu'il s'agit du Midas.dll, il faut l'enregistrer au niveau system en utilisant RegSvr32. :
ouvrir une commande dos
se placer dans le repertoire où se situe le fichier
taper regsvr32 midas.dll

C'est suffisant pour inscrire en base de registre où se trouve la bibliothèque et ca peut débloquer le probleme.
13/12/2006, 11h12
LadyWasky

Citation:

Envoyé par dd16

Normalement, lorsqu'il s'agit du Midas.dll, il faut l'enregistrer au niveau system en utilisant RegSvr32. :
ouvrir une commande dos
se placer dans le repertoire où se situe le fichier
taper regsvr32 midas.dll

C'est suffisant pour inscrire en base de registre où se trouve la bibliothèque et ca peut débloquer le probleme.

+1
bien vu, j'opte aussi pour ça ;)
13/12/2006, 11h51
Philippe85

Merci à tous et solution

La résolution de mon probléme, est l'inclusion de MidasLib dans le projet. Là le programme fonctionne, sans auncun problème et cela est la solution probablement la plus simple (pas de procédure d'installation, ni de désisntallation, pas de contrainte de droits jamais facile en milieu professionnel).

Sur le fond, il s'agit effectivement de différence de recherche de DLL entre les versions de Windows, même entre des XP de meme type (XP Home).

Il semble que l'ordre de recherche des DLL, entre chemin de l'appli, PATH, et base de registre ne soit pas le même entre les versions. Pour certains la présence de la dll dans le répertoire ou dans le répertoire système ad-hoc est suffisant, pour d'autre Windows il faut que la dll soit dans la base de registre (regsvr32 midas.dll).

L'installation de Delphi sur le poste résolvait le problème car delphi installe proprement midas.dll

Merci à tous pour vos réponses