Discussion :

[Négrier]

Contexte :
Poste client : Windows 10 21H2
Poste serveur : Windows Server 2016
Delphi XE7

Je lance depuis mon poste client deux jobs sur le serveur qui :
.lancent un exécutable
.cet exécutable charge dynamiquement une DLL

Les traitements sont abondamment tracés

J'observe que la DLL
est bien chargée par l'exécutable lancé dans le premier job
n'est pas chargée par l'exécutable lancé dans le second job (GetLastError renvoie 126)

j'ai vu un article MS qui traite d'un sujet voisin
lié aux droits d'accès des jobs sur les DLL mais le fait est que je n'ai pas de problème avec le premier job

voilà si cela parle à quelqu'un....

[ALWEBER]

Sans garanties (et éventuellement si tu peux regénérer ta DLL) en faire un copie sous un autre nom car le 1er chargement bloque le fichier DLL le temps de son utilisation

[ShaiLeTroll]

ERROR_MOD_NOT_FOUND

126 (0x7E)

Le module spécifié est introuvable.


As-tu un Process Attach ou Thread attach dans le Main de la DLL ?

As-tu un cloisonnement mémoire des variables mémoires, est-ce le process partage son gestionnaire de mémoire ?

[Négrier]

La DLL (codée en C++) charge des librairies de l'environnement scientifique SCILAB.

Hier l'ensemble des éléments de l'installation SCILAB résidait sur le disque local du serveur.

Aujourd'hui j'ai tenté de charger une installation SCILAB faite sur un disque réseau (auquel j'accède depuis
mon poste client et depuis le poste serveur) à partir du Job n°2 et désormais la DLL est chargée
correctement par tous les jobs !

L'article référencé dans mon premier post est relatif à l'erreur STATUS_DLL_NOT_FOUND (différence de celle
que j'ai eue) mais je me demandais si mon problème n'était pas lié à des histoires de droits d'accès...

Cet article fournit une solution de contournement pour un problème où la fonction LoadLibrary retourne STATUS_DLL_NOT_FOUND erreur sur le thread d’emprunt d’identité dans Windows.

S’applique à : Windows Server 2019, Windows Server 2016, Windows 10 - toutes les éditions

[ShaiLeTroll]

En réseau, déjà que les Exe en Citrix en réseau cela crée des copies mémoire, des verrous sur le fichier ... ça va être peu fiable comme méthode car le temps d'accès réseau est lent par rapport à un accès local.

En Citrix, c'est comme un bureau à distance, mais c'est encore pire un Exe sur un poste A avec une DLL sur poste B, je devine une installation centralisé pour simplifier le déploiement et peut-être économiser des licences.

La DLL étant codé en C++, elle utilise donc son propre gestionnaire de mémoire, et es-tu sûr que cette utilisation est prévue, autorisée voire pas empêché ?
Tu peux très bien codé qu'un seul process s'attache à la DLL, même un seul thread à la fois.


Comment montes-tu le disque ?
Genre un WNetAddConnection1, 2 ou 3 ?

Si cette technique corrige le problème, surement parce qu'il fait plusieurs copies mémoire de la DLL issue du réseau au lieu d'un seul exemplaire de la DLL locale partagée par plusieurs process.

[Négrier]

-La direction informatique de notre organisation met en place et gère les disques réseau.
-Les jobs sont lancés à travers le client MS : HPC Pack 2016 Job Manager.
-lorsque j'exécute l'application sur mon poste , avec chargement de la DLL et lancement du Scilab à la suite, l'ensemble fonctionne convenablement.
-Actuellement l'ensemble (EXE et DLLs) est en WIN64.
-Aucune licence payante n'est nécessaire ni sur l'exe ni sur cette version Scilab (5.4.1)

-j'ai refait de nombreux tests hier en essayant de charger alternativement une première puis une deuxième installation Scilab selon la parité du numéro de job : les résultats sont très erratiques

[anapurna]

Salut

peut tu faire des logs sur les path utilisé
il manque peut être une information sur scilab

[Négrier]

Je viens de refaire un test avec huit jobs qui référencent alternativement deux installations différentes de Scilab sur deux disques réseau différents et ça fonctionne bien.

Merci de vos conseils et avis.

Je clos la discussion.