Pourquoi ne COM CoInitializeSecurity échouer dans ma DLL?

Je suis actuellement étudiant VSHADOW.EXE 3.0 à partir de la MS Windows SDK 6.1. J'ai fait une version qui peut être compilé dans une DLL que seules les exportations nouvellement écrite fonction qui s'attend à la ligne de commande, comme une chaîne de caractères, tokenizes et appelle ensuite la vieille wmain. La DLL n'est pas un serveur COM.

Il fonctionne exactement comme l'ancienne lors de la compilation comme un EXE, mais ne fonctionne pas lors de la compilation comme un DLL parce que cet appel échoue:

 CoInitializeSecurity(NULL, -1, NULL, NULL, 
                      RPC_C_AUTHN_LEVEL_PKT_PRIVACY, 
                      RPC_C_IMP_LEVEL_IDENTIFY, 
                      NULL, EOAC_NONE, NULL);

qui échoue avec HRESULT erreur 0x80010119 (RPC_E_TOO_LATE, de Sécurité doit être initialisé avant de toutes les interfaces sont insérés ou unmarshalled. Il ne peut pas être changé une fois initialisée.)

- Je exécuter la fonction exportée à partir d'un programme VB6 où la fonction est importé avec Declare Function vss Lib vshadow.dll ....

Le message d'erreur signifie que le programme VB6 déjà appelé CoInitializeSecurity? Que puis-je faire contre l'erreur?

Aussi, j'ai une autre question: pourquoi sont exactement les valeurs de sécurité RPC_C_AUTHN_LEVEL_PKT_PRIVACY et RPC_C_IMP_LEVEL_IDENTIFY choisi? Quel serait l'impact d'autres paramètres?

OriginalL'auteur Felix Dombek | 2011-04-14

  1. 12

    Il ya un couple de COM standard des appels qui ne pas appartiennent dans une DLL. Comme CoInitializeEx(), l'appel qui initialise COM pour un thread. La DLL n'est pas propre au fil, il est impuissant à remplacer l'appartement de l'état que le fichier EXE sélectionné.

    CoInitializeSecurity() en est une autre, c'est le travail de l'EXE pour l'appeler. Seulement il sait les bonnes valeurs à transmettre, c'est celui qui détermine la politique de sécurité. Une DLL ne peut pas, il ne sait rien au sujet du processus client.

    OK, j'ai besoin de quelques précisions ... (1) quelles sont les valeurs propres ne l'EXE et la DLL n'a pas? Si le projet compilé en un fichier EXE utilise exactement les mêmes valeurs que la DLL, pourquoi ne sont-ils pas correct? Il n'y a pas encore d'un IDENTIFIANT unique dans le CoInitializeSecurity paramètres ... (2) avez-vous des idées de comment je pourrais l'adresse de ce problème et engager les clichés instantanés de volume à partir d'une DLL? L'état actuel de la DLL n'est intermédiaires; je suis le seul à pratiquer à écrire un général VSS DLL.
    C'est assez simple, la DLL peut être utilisé par plusieurs processus. C'est la processus qui détermine le contexte de sécurité dont il a besoin. Je vous recommande fortement de vous oublier, COM de sécurité est laid et sans grande importance dans la non-DCOM scénarios.
    Eh bien, mon patron m'a dit "à écrire une DLL qui peut créer des clichés instantanés de volume" ... et j'ai entendu parler de Dll qui peuvent ce faire, il doit y avoir un moyen!
    Ainsi, faire votre patron heureux et écrire une DLL qui le fait. Laisser à l'administrateur du système pour exécuter n'importe quel processus qui utilise votre serveur de privilèges suffisants.
    Vous êtes simplement en regardant le code réutilisable, MSFT comprend dans tous leurs exemples de code. Les arguments passés ne fait pas de changer quoi que ce soit à partir de la valeur par défaut. Encore une fois, tant que c'est votre travail pour que de fournir une DLL de sécurité n'est pas votre préoccupation. Je suis à la signature, bonne chance avec elle.

    OriginalL'auteur Hans Passant