Discussion :

[Papy214]

Bonjour à tou(te)s

J'ai un problème avec regsvr32 et un vieil OCX développé en Delphi 7.
Le client n'arrive pas à l'installer, que ce soit avec "Inno Setup" ou manuellement en ligne de commande (en admin évidemment j'ai fais le test moi-même en accès distant).

Chez le client, sur un (même plusieurs) Windows 7 ou 8 en 64 bits, regsvr32 renvoie une erreur indiquant que KernelBase.dll a provoqué une erreur.

Nom de l’application défaillante regsvr32.exe, version : 6.1.7600.16385, horodatage : 0x4a5bca28
Nom du module défaillant : KERNELBASE.dll, version : 6.1.7600.16385, horodatage : 0x4a5bdbdf
Code d’exception : 0x0eedfade
Décalage d’erreur : 0x0000b727
ID du processus défaillant : 0xdf0
Heure de début de l’application défaillante : 0x01d3181c7f57bb0c
Chemin d’accès de l’application défaillante : c:\Windows\SysWOW64\regsvr32.exe
Chemin d’accès du module défaillant: C:\Windows\syswow64\KERNELBASE.dll
ID de rapport : bd580bf0-840f-11e7-8721-080027b54ba2

Le souci est que les tests ici se passent sans problème. J'ai fais l'essai sur mon poste Windows 8 pro 64 bits, ça passe sans erreur.
Même réussite sur une VM Windows 7 ,pro 64 bits.

Seule différence que je vois pour l'instant est que le client utilise des versions "home" contrairement à nous.

Pour voir si Delphi pouvait être en cause, j'ai fais un OCX rapide avec Tokyo et je lui ai demandé de tester avec regsvr32.
Réponse: Enregistrement et désenregistrement réussi.

Du coup, je sèche.
Si ça venait de regsvr32, l'enregistrement de la version Tokyo ne devrait pas passer non plus.
Si ça venait de D7, l'enregistrement ne devrait pas réussir sur mon poste.

Avec Google, j'ai trouvé différents post sur l'erreur mais uniquement à l'exécution d'un sotf écrit en D7.
Rien qui soit en rapport avec regsvr32.

Est-ce que l'un de vous aurait eu ce problème ou aurait une idée sur la façon de trouver la cause du crash ?

[SergioMaster]

Bonjour,

j'ai toujours eu un doute avec REGSVR32
en effet si sur un OS 32 bits c'est clair pour un 64 bits je patauge dans la semoule surtout si la Dll est 32 bits
je m'explique si la DLL est 32 bits (ce qui est le cas avec D7) alors sur un OS 64 bits elle doit être mise dans SYSWOW64 (bonjour la confusion)
pour l'installer il faut alors utiliser regsvr32.exe situé dans ce même SYSWOW64 même nom et pourtant pas même effets (comme si MS n'aurait pas pu nommer différemment ces 2 exe !)

comme indiqué ici

Chemin d’accès de l’application défaillante : c:\Windows\SysWOW64\regsvr32.exe
Chemin d’accès du module défaillant: C:\Windows\syswow64\KERNELBASE.dll

Seule différence que je vois pour l'instant est que le client utilise des versions "home" contrairement à nous.

c'est peut être une explication tirée par les cheveux mais MS n'est pas à ça prêt ! as-tu essayé de copier ces 2 fichiers à partir d'une version pro ?
vérifie aussi les versions ce ces deux fichiers cela peut être un erreur faite par le client

[Papy214]

J'ai bien utilisé la version dans syswow64 en mettant le chemin complet à regsvr32.
J'ai aussi essayé de d'aller dans le répertoire et de donner le chemin complet vers l'OCX.
ça n'a rien changé.

Pour tester les fichiers pro de mon poste chez le client, il faudra que j'attende la semaine prochaine. Il est absent pour la semaine.
Le problème, c'est que mon ocx version Tokyo, même s'il n'implémente aucune fonction, ne pose pas de problème chez le client.
Si ça plantait aussi, je pencherais alors vers un problème système.

[Papy214]

Bon, reprise des hostilités ...

Je pense que j'ai compris d'où vient le problème.
Sur mon poste et mes VM où Delphi est installé, aucune erreur.
Sur une VM toute propre du client, crash !
Idem sur le poste d'un collègue qui ne sait même pas ce qu'est Delphi : crash !

Conclusion, il manque un fichier qui doit s'installer avec Delphi.
Problème : trouver lequel ! :-(

[Papy214]

Victoire ! le regsvr32 cherchait gds32.dll parce que l'ocx utilise Firebird.
Il n'y a pourtant aucune liaison statique dansle code mais il semble que ça le perturbe quand même.

Problème résolu !