Discussion :

[dus]

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 ?

[bacelar]

Question con, elle est bien 32bits, votre Dll ?

[dus]

Oui oui, c'est la première chose que j'ai vérifié.

[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...

[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.

[dus]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[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

[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...

[dus]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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)

[dus]

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 :



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



P....., j'y croyais...

[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?

[dus]

ça doit être activé par défaut quand on créée un nouveau projet car c'est déjà activé.

[bacelar]

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.

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.

[dus]

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

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é.

[Médinoc]

Tu peux aussi essayer le Remote Debugger, si ça existe toujours...

[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)

[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 ?

[bacelar]

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.

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

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.

[dus]

Bonjour,

J'ai utilisé WinDbg pour obtenir les deux fichiers joints, 2005_ok.TXT2015_nok.TXT
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.

[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.

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.