Les objets COM sont-ils responsables de conserver leur propre module en mémoire?

Question

Supposons que vous procédiez comme suit:

1) Chargez foo.dll à l'aide de LoadLibrary.

2) Obtenir un pointeur sur une fonction en utilisant GetProcAddress.

3) Invoquer la fonction, en vous donnant une référence à un objet COM implémenté dans ce module.

4) Gratuit foo.dll en appelant FreeLibrary.

5) Appelez une méthode sur l'objet COM.

Voulez-vous que l'étape 5 réussisse et ne fonctionne pas? En d'autres termes, l'objet COM est-il lui-même chargé d'appeler LoadLibrary (à nouveau) pour incrémenter le nombre de références que Windows conserve pour chaque module, garantissant ainsi qu'il ne survit pas au module?

Answer 1

Je m'attendrais à un AV. Même si ça n'a pas été le cas aujourd'hui, c'est probablement un accident qui attend de se produire. Pour un cas comme celui-ci, où un objet COM est renvoyé via une exportation DLL personnalisée, l'objet COM ne doit pas incrémenter le nombre de références de la DLL - tant que l'application utilise des ressources d'une DLL, elle explicitement chargé, il incombe à l'application de conserver cette DLL chargée.

Pour les objets COM in-proc créés via la route CoCreateInstance normale, la DLL exportera généralement DllCanUnloadNow, qui doit renvoyer S_FALSE tant qu'il existe des références en attente.

Cependant, rien n'empêche l'objet COM d'incrémenter le compte de référence de la DLL via LoadLibrary - il n'y a rien d'illégal ou dangereux à faire.

Answer 2

Certainement pas. Le nombre de références du module est maintenu par les méthodes normales d'utilisation - ce que vous faites est une porte dérobée dans le schéma d'exécution. Normalement, vous utilisez CoCreateInstance et ainsi de suite pour créer vos objets - ce sont des wrapper qui appellent CoGetClassObject et DllGetClassObject. CoGetClassObject appelle CoLoadLibrary qui maintient un compte de référence sur la DLL. En outre, vous pouvez appeler LockServer sur l'objet de classe pour maintenir un nombre de références sur l'objet de classe pour les performances, mais cela n'est pas nécessaire pour s'assurer que la DLL reste chargée.