Enregistrement dll COM

Version imprimable

29/03/2017, 09h40
dus

Enregistrement dll COM

Bonjour,

Je viens de migrer une appli C++ non managé de VS2005 à 2015. Tout s'est relativement bien passé, excepté pour une dll COM.
Je précise que tous les projets sont configurés en v140_xp.
La dll en question compile correctement, est générée en configuration release x86, s'enregistre correctement sur le poste windows 7 64 bits sur lequel VS2015 est installé, l'appli y fonctionne correctement.
Sur un poste XP 32 bits qui représente la cible principale sur laquelle l'appli sera déployée, pas moyen d'enregistrer la dll.
Message de Regsvr32 : LoadLibrary a echoué - L'accès à cet emplacement de la mémoire n'est pas valide.

Dependency walker ne remarque aucune dépendance manquante.
J'ai bien installé le redistributable de VC2015.

Si je remplace la dll COM en question par sa version précédente compilée sous 2005, que j'installe le redistributable VC2005, l'enregistrement fonctionne, et l'appli tourne.

J'ai beau faire le tour des propriétés du projet, je ne remarque rien de transcendant...

Une idée ?
29/03/2017, 10h36
bacelar

Question con, elle est bien 32bits, votre Dll ?
29/03/2017, 10h52
dus

Oui oui, c'est la première chose que j'ai vérifié.
29/03/2017, 11h42
Médinoc
Un test intéressant serait de tenter toi-même un LoadLibrary() de la DLL en question dans un programme.
Et aussi, vérifier si elle ne fait rien de bizarre dans:
- son DllMain(),
- Les constructeurs de ses objets en variables globales (appelés par _DllMainCrtStartup() avant l'appel à DllMain())
  Y compris, vérifier que tu n'as pas d'objets globaux dépendant d'autres objets globaux...
29/03/2017, 11h48
dus

Je viens de voir dans les propriétés du projet, au niveau des valeurs héritées du préprocesseur la valeur _USING_V110_SDK_. Celle-ci n’apparaît pas dans les autres projets de l'appli.
Malgré le fait que Dependency walker n'indique pas de dépendance à MFC110 mais à MFC140, j'ai tenté d'installer le redistributable VC 2012 sur la cible XP... pour voir..., mais le problème reste entier.

Je viens de générer un exe avec le code suivant :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 HINSTANCE hInstLib; hInstLib = LoadLibrary(TEXT("COM_Client_SAF_NVGT.dll")); if (hInstLib == NULL) { DWORD dwError = GetLastError(); CString sTemp; sTemp.Format(_T("%i"), dwError); GetDlgItem(IDC_EDIT1)->SetWindowTextW(sTemp); } else GetDlgItem(IDC_EDIT1)->SetWindowTextW(_T("LoadLibrary OK"));
J'ai le message LoadLibrary OK sur le poste W7 64 bits et sur le poste XP 32 bits.
:calim2:

29/03/2017, 15h39
bacelar

OK pour le DllMain et les globales, maintenant, il se passe quoi si vous appelez la fonction "DllRegisterServer" de la Dll après le chargement de celle-ci ?
https://msdn.microsoft.com/fr-fr/lib...or=-2147217396
29/03/2017, 17h21
Médinoc

Ah, maintenant j'ai une bonne idée du problème:
Cette page m'a suggéré une erreur de Prévention de l'Exécution des Données (DEP). Notamment sachant que des vieilles versions d'ATL n'étaient pas compatibles DEP parce qu'elles utilisaient des "thunks" (petits bouts de code exécutables) alloués dynamiquement dans un tas qui n'avait pas le flag HEAP_CREATE_ENABLE_EXECUTE.
Si la DEP est en mode "Uniquement pour les programmes essentiels Windows et les services", ça expliquerait que regsvr32 (étant signé Microsoft et compilé avec /NXCOMPAT) plante dessus alors qu'un programme à toi ne plante pas...

Code:

1
2
3
4
5
6
7
8
 
regServer_t regServer = (regServer_t)GetProcAddress(diaLib, "DllRegisterServer");
if( regServer == NULL )
{
     FreeLibrary(diaLib);
     return;
}
HRESULT hr = regServer();

résultat : hr = S_OK (0L)

29/03/2017, 18h04
dus

2 pièce(s) jointe(s)

Le DEP est effectivement positionné sur "Activer la prévention d'exécution des données pour les programmes et les services Windows uniquement"

Si je positionne sur le deuxième choix avec la gestion des exception et que j'ajoute Regsvr32.exe comme exception :

Pièce jointe 258970

après reboot, j'obtiens....

Pièce jointe 258978

P....., j'y croyais...
29/03/2017, 18h09
Médinoc

Qu'est-ce qui se passe si tu actives /NXCOMPAT dans les options d'édition de liens avancées de ton programme de test?
29/03/2017, 18h11
dus

ça doit être activé par défaut quand on créée un nouveau projet car c'est déjà activé.
29/03/2017, 19h01
bacelar

Citation:

résultat : hr = S_OK (0L)

Votre Dll est donc correctement enregistrée maintenant ?

Si oui, votre programme est compatible avec votre Dll mais pas "Regsvr32.exe".
Sinon, votre Dll nous trolle. :aie:

Pour éviter de chasser le dahu, moi, je collerai un breakpoint dans "DllRegisterServer" (via un 'int 3' si nécessaire) et je configurerai mon débogueur pour s'arrêter dès la détection d'accès foireux de la mémoire.

Ça sera bien plus simple avec le code source du problème.
30/03/2017, 09h17
dus

Non seulement elle est correctement enregistrée, mais en plus elle fait ce que je lui demande...

Citation:

Pour éviter de chasser le dahu, moi, je collerai un breakpoint dans "DllRegisterServer" (via un 'int 3' si nécessaire) et je configurerai mon débogueur pour s'arrêter dès la détection d'accès foireux de la mémoire.

ça implique d'installer VS2015 sur la cible XP ? Je ne suis pas sûr de la compatibilité.
30/03/2017, 10h03
Médinoc

Tu peux aussi essayer le Remote Debugger, si ça existe toujours...
30/03/2017, 10h34
dus

Je confirme : Visual Studio 2015 incompatible avec XP :
https://www.visualstudio.com/fr-fr/p...equirements-vs

Remote debugger impossible avec XP:
https://www.visualstudio.com/fr-fr/p...mpatibility-vs

Je vais essayer de creuser avec WinDbg, mais je pense que j'aurais des difficultés à connecter la cible au web pour obtenir les symboles (la politique du réseau d'entreprise ne veut plus entendre parler de XP)
30/03/2017, 10h41
dus

Que de temps perdu pour une dll sous-traitée il y presque 10 ans, sur laquelle j'ai dû corriger au plus 2 pauvres bugs depuis.
Je me demande si je ne vais pas la sortir de la chaîne de compilation et utiliser la version compilée sous 2005.

Par expérience, avez vous déjà rencontré des problèmes avec des softs qui utilisent des dlls compilées sous différents environnements ?
30/03/2017, 19h44
bacelar

Citation:

Envoyé par dus

Non seulement elle est correctement enregistrée, mais en plus elle fait ce que je lui demande...

Si je comprends bien, c'est "Regsvr32.exe" qui "déconne".

Déjà, pour la solution tactique, vous pouvez peut-être utiliser votre programme "bidule" à la place de "Regsvr32.exe" au moment de l’installation, ni vu ni connu je t'embrouille. :aie:

Après, intellectuellement parlant, c'est peu satisfaisant, mais on a dit "tactique". :aie:

Une solution peut-être plus légère c'est d'utiliser des outils comme AutoDumpPlus (ADPlus) pour avoir un dump au moment de la violation d'accès.
https://blogs.msdn.microsoft.com/web...us-executable/

Si vous avez bien les .pdb correspondant à la Dll et que vous rapatriez les dumps sur votre machine de DEV correctement configurer pour récupérer les symboles de M$, vous pourrez tranquillement utiliser VS pour voir où ça merde.
31/03/2017, 11h20
dus

2 pièce(s) jointe(s)

Bonjour,

J'ai utilisé WinDbg pour obtenir les deux fichiers joints, Pièce jointe 259559 Pièce jointe 259564
Le premier correspond à l'enregistrement de la dll sous 2005 qui se passe correctement et le second celui qui déconne.

Pour ceux qui ne connaissent pas WinDbg, la commande p dans le prompt correspond à un pas à pas principal et la commande t à un pas à pas détaillé.

J'ai écrit dans le fichier au moment des messages soit d'erreur, soit de succès. Aucune différence notable à cet endroit là (c'est en fin de fichier)

Aucun dump de Dr watson généré, et rien dans son log non plus, sûrement pour la simple raison qu'il n'y a pas de crash.
31/03/2017, 16h57
bacelar

Sauf erreur de ma part, ce qui est débogué, c'est "CMD.EXE".
Clairement, pour lui, une erreur ou pas, cela ne change rien.

WinDbg, c'est assez violent, surtout sans les symboles.
Pensez à mettre les .pdb de vos Dll dans la machine de test, pour avoir des informations précises lors du débugging de ces Dll.
(voir même les sources des Dll)

Il faut que WinDbg s'attache à "Regsvr32.exe" plutôt qu'à "CMD.EXE".

Mais bon, je pense que l'approche ADPlus serait plus simple bien que moins flexible.
ADPlus permet de faire des dump à des moments particuliers de l'exécution de certain programme.
Et une violation d'accès mémoire est un moment très très particulier de l'exécution de "Regsvr32.exe".

Avec le dump, que vous pouvez ouvrir sur une autre machine pour avoir tous les outils nécessaires, vous pourrez "voir l'instant" de la violation d'accès mémoire.

Citation:

Aucun dump de Dr watson généré, et rien dans son log non plus, sûrement pour la simple raison qu'il n'y a pas de crash.

C'est la limitation de DrWatson que les outils comme gflags et autres ADPlus comblent.
31/03/2017, 17h32
dus

J'avais pas tilté que c'était cmd.exe qui était debuggé. J'ai utilisé un .bat car je ne vois pas comment lancer regsvr32 avec un argument par le biais de WinDbg.
WinDbg je connais un peu pour avoir analysé des crash dumps avec.

ADPlus je connais pas du tout mais je vais essayer de creuser.

Merci à vous pour le temps passé.
31/03/2017, 18h13
bacelar

ADPlus, c'est juste un script VBS qui configure tout un tas d'outils pour générer des dumps aux moments qui vont bien.