Problème de chargement de DLL SSL

Je suis confronté à un problème étrange avec SSL.
Un de mes programmes déclenche une erreur systématique sur les postes de mes collègues mais pas sur le mien.
Il s'agit d'un logiciel qui génère un PDF et l'envoie sur un site WEB en https avec le composant TIdHTTP.
Au déclenchement de l'envoi, les autres postes reçoivent le message:
"Impossible de charger la bibliothèque SSL"
Ils ont pourtant les mêmes fichiers que moi au même endroit sur leur poste.
Sur mon poste, aucun problème !

La chose étrange c'est que j'ai tenté re renommer les dll dans la répertoire où se trouve l'exe et ça fonctionne quand même. Ce qui me parait normal vu que de versions des dll concernées, j'en ai plusieurs sur mon poste et que Windows doit forcément en trouver une dans les différents chemins possibles.

Maintenant, la question est : pourquoi 2 installations identiques sur 2 postes différents ne fonctionnent pas de la même manière. Sur mon poste, aucune erreur, sur les autres (testés sur 3 différents), erreur.
Pourquoi mon programme ne peut pas charger ces dll alors qu'elles sont sous son nez (même répertoire).

Pour essayer de comprendre, j'ai demandé au collègue de donner tous les droits à tout le monde sur le dossier et même de lancer le programme en mode administrateur, cela ne change rien.

La seule différence entre eux et moi c'est que mon poste "Delphi" est encore sous Windows 8.1 et eux sont en W10. Est-ce que ça pourrait venir de là ?

Toute idée sera bonne à prendre parce que là je ne sais plus trop quoi faire pour débloquer la situation :-(

Essaye de forcer IdOpenSSLSetLibPath avant l'appel à LoadOpenSSLLibrary (normalement c'est uniquement à partir du moment où un objet qui requiert le SSL en a besoin) lors de la création d'un TIdSSLContext par le TIdSSLIOHandlerSocketOpenSSL (une fois la connexion TCP IP ouverte, cela utilise la DLL pour le Hanshake et c'est là que se produit l'exception)

Je me suis greffer sur IdSSLOpenSSLHeaders.GetCryptLibHandle pour utiliser PEM_read_bio_PUBKEY qui n'était pas déclaré dans ma version de Indy




Pour ton exe, vérifie le dossier de démarrage si cela utilise un raccourci, cela peut influencer les chemins relatifs, en général, je préfère toujours utiliser explicitement Application.ExeName pour localiser le dossier de l'exe que me baser sur le CurrentDir.

Tous les developpeurs compilent sur la même architecture ? 32 vs 64 ?
DPROJ identique (les variables d'environnement bien utile pour partager le même DPROJ mais des chemins différents sur chaque poste)
En débogage, Delphi est tout de même assez intrusif en particulier pour l'environnement hérité (il est 32 bits encore le IDE ?)

J'ai testé, toujours le même problème. C'est à n'y rien comprendre.
J'ai même fait un simple bout de code de test dans une appli autonome, ça fonctionne chez moi et pas chez les autres.
Pour la différence entre Windows 8 et 10, j'ai essayé le même programme de test sur mon poste à la maison. Ça fonctionne mais la même chose bloque toujours chez les autres.
J'ai pensé à un effet de l'antivirus mais on a le même.
Comme tout le monde, j'ai souvent été confronté à des casse-têtes mais celui-là il est assez gratiné :-(

Bonjour,
tu oublies aussi le 32/64 bits ce qui complexifie un peu plus le problème

Tous les postes sont en 64.
Les dll sont bien les bonnes versions et le code est bien la version 32 bits générée par Delphi.
Et niveau code, je peux difficilement faire plus court pour tester.

Code:

---

1 2 3 4 5 6

IdOpenSSLSetLibPath(TPath.GetDirectoryName(Application.ExeName)); if LoadOpenSSLLibrary then ShowMessage('Librairies SSL chargées') else raise Exception.Create('Les librairies SSL ne peuvent être chargées');

---

Au moins en faisant ça, ça m'a permit de voir que le programme complet n'est pas en cause.

Et, puisque les programmes sont en 32 bits, les Dlls sont bien en 32 bits ?

Pièce jointe 630239

Citation:

---

Envoyé par Papy214

Pièce jointe 630239

---

on ne voit pas si elle est 32 ou 64 bits là dessus, j'utilise CCF Explorer pour ça
Pièce jointe 630240

Pièce jointe 630244

J'ai récupéré l'erreur avec GetLastError. Voilà le résultat pour chaque DLL :

Erreur : 0 (renvoyé par SafeLoadLibrary)
Code erreur Windows: 126
Message erreur Windows: Le module spécifié est introuvable

Erreur : 0 (renvoyé par SafeLoadLibrary)
Code erreur Windows: 126
Message erreur Windows: Le module spécifié est introuvable

Bonjour,

De mon coté j'utilise Process Monitor (progmon) pour pister le chargement des DLL.
L'ordre de recherches et paths peuvent te donner des pistes

https://learn.microsoft.com/en-us/sysinternals/downloads/procmon


Pascal

Application.ExeName renvoie le bon chemin ?

Les chemins sont bons, ça a été vérifié.

Par contre, en regardant avec CCF explorer (Merci Paul), je vois certaines dépendances de DLL qui se trouvent sur mon poste et sans doute sur ceux de mes collègues.
Comme j'ai dû installer plusieurs versions de "Visual C++ Redistributable for Visual Studio" au bureau et chez moi, ce que les autre n'ont sans doute pas fait.

Exemple: C:\WINDOWS\SysWOW64\MSVCR100.dll

Si une des dll indiquées dans "Dependency Walker" de CCF sont manquantes, le problème pourrait-il venir de là ?

Mon collègue vient de me dire qu'il n'a pas cette dll

C'était bien ça ! J'ai fait rajouter msvcr100.dll à côté des dll OpenSSL et ça fonctionne.

Oufffffffff ...........

Merci tout de même à vous tous et à CCF Explorer :-)

Télécharge cette de https://indy.fulgan.com/SSL/
Normalement, la dépendance n'est pas nécessaire, du moins pour les récentes ...1.0.2q
la 1.0.1m 32bits

Cette dépendance n'est pas normal, ça doit être une version foireuse !

Effectivement, la 1.0.2u n'affiche pas de dépendances à la dll en question.
Je vais pouvoir éviter de diffuser une dll microsoft dans mon setup.
Merci

Citation:

---

Envoyé par ShaiLeTroll

Télécharge cette de https://indy.fulgan.com/SSL/
Normalement, la dépendance n'est pas nécessaire, du moins pour les récentes ...1.0.2q
la 1.0.1m 32bits

Cette dépendance n'est pas normal, ça doit être une version foireuse !

---

Tout va bien avec la version "u" !

Mais sur le site, seule une lettre différencie les mêmes versions1.0.2.
Saurais-tu à quoi correspondent ces lettres étant donné que chaque archive a la même date ? :question:

faut le voir comme un numéro 1.0.2.21

m = 13
q = 17
u = 21