LoadLibraryW renvoie Nullptr, et getlasterror () renvoie 3221225619

Question

Décrire les problèmes que j'ai eues prendrait trop de temps, mais le problème à la fin est:

1. LoadLibraryW échoue (renvoie Nullptr) lorsqu'il est donné un chemin valide.

2. Le moniteur de processus n'enregistre pas d'échecs suspects, ni même quelque chose de différent de lorsqu'il réussit à charger la DLL (ce qu'il peut dans un autre contexte).

3. La DLL n'a pas de dépendances non-système.

4. ... et pire de tous, le code d'erreur Windows renvoyé par Getlasterror est le 3221225619.

En supposant que le 3221225619 n'est pas un code d'erreur valide, qu'est-ce qui pourrait se passer si mal que Windows n'a même pas de code d'erreur pour cela?

ÉDITER:

Je pense que certaines personnes ont voulu plus de détails sur l'échec lui-même:

• Il ne semble pas être l'entrée - il est identique dans la version de travail et d'échec, et LoadLibraryW a déclaré avec succès "le fichier n'existe pas" lorsque la chaîne d'entrée a été mutilée. L'entrée actuelle l'a codé en dur, laissant peu de place pour l'erreur.
• La DLL est compilée dans la version et le code d'appel dans le débogage. Je fais cela depuis 18 mois sans problème, mais on ne sait jamais.
• Le package Process Monitor rapporte environ 30 opérations internes fonctionnant dans LoadLibraryW, y compris CreateFile, LoadImage, RegoPenKey. Ceux-ci sont identique pour l'appel de travail et l'appel défaillant, jusqu'à la taille des fichiers et les emplacements de mémoire.
• Il n'y a pas de corruption de mémoire évidente dans l'objet C ++ l'appelant, et comme je l'ai dit, Process Monitor donne la même adresse d'image de base dans les deux cas.
• L'échec est 100% cohérent - même temps, même endroit à chaque fois.

Answer 1

Désolé, ce n'est pas exactement une réponse, mais le problème a été résolu.

Pour commencer, je viens de remarquer une question similaire ici: Erreur C ++ LoadLibrary () 3765269347. Je pense que celui-ci donne plus de détails et vaut le détour si vous êtes dans une position similaire à ce que j'étais.

Mes remerciements à @whozcraig, @danieldaranas et à tous ceux qui ont fait des commentaires utiles. Pour d'autres personnes qui lisent ceci, il y a un bon article sur Hresult qui développe leurs points sur Wikipedia: http://en.wikipedia.org/wiki/hresult.

Dans mon cas, le problème a disparu aussi mystérieusement qu'il est apparu. J'ai créé une classe C ++ pour appeler la DLL régulièrement. Mon effort d'origine a chargé la DLL immédiatement avant le premier appel et l'a mis en cache en mémoire. C'est la même chose en principe à la façon dont cela a fonctionné pendant plus d'un an. Cela a abouti à l'erreur mystérieuse ci-dessus.

Je l'ai refactorisé pour charger la DLL pendant la construction, mais pour en extraire la fonction au moment de l'exécution. Cela fonctionne apparemment et est probablement une meilleure façon de le faire (charger la DLL pendant la construction, la libérant pendant la destruction). Comme il se passe très peu de choses entre la construction et le premier appel à la DLL, je ne vois pas pourquoi une méthode devrait produire une erreur de système d'exploitation, et l'autre ne le fait pas.