LoadLibraryW devuelve nullptr y GetLastError() devuelve 3221225619

Question

Describir los problemas que he tenido llevaría demasiado tiempo, pero el problema principal es:

1. LoadLibraryW falla (devuelve nullptr) cuando se le proporciona una ruta válida.

2. Process Monitor no registra fallas sospechosas, ni nada diferente de cuando logra cargar la dll (lo que puede hacer en otro contexto).

3. El dll no tiene dependencias que no sean del sistema.

4. ...y lo peor de todo es que el código de error de Windows devuelto por GetLastError es 3221225619.

Suponiendo que 3221225619 no es un código de error válido, ¿qué podría estar saliendo tan mal que Windows ni siquiera tiene un código de error?

EDITAR:

Creo que algunas personas han querido más detalles sobre el fallo en sí:

• No parece ser la entrada: es idéntica en la versión funcional y fallida, y LoadLibraryW ha declarado exitosamente "el archivo no existe" cuando la cadena de entrada ha sido mutilada.La entrada actual lo tiene codificado, lo que deja poco margen de error.
• El dll se compila en Release y el código de llamada en Debug.Llevo 18 meses haciendo esto sin problema, pero nunca se sabe.
• El paquete Process Monitor informa alrededor de 30 operaciones internas que se ejecutan dentro de LoadLibraryW, incluidas CreateFile, LoadImage y RegOpenKey.Estos son idéntico para la llamada de trabajo y la llamada fallida, hasta el tamaño de los archivos y las ubicaciones de la memoria.
• No hay una corrupción obvia de la memoria en el objeto C++ que lo llama y, como dije, Process Monitor proporciona la misma dirección de imagen base en ambos casos.
• El fallo es 100% consistente: siempre al mismo tiempo y en el mismo lugar.

Answer 1

Lo siento, esto no es exactamente Una respuesta, pero el problema se ha resuelto.

Para empezar, acabo de notar una pregunta similar aquí: C ++ LoadLibrary () Error 3765269347. Creo que este da más detalles y vale la pena echarle un vistazo si estás en una posición similar a lo que era.

Mi agradecimiento a @whozcraig, @danlarinaranas y a todos los que hicieron comentarios útiles. Para otras personas que leen esto, hay un buen artículo sobre Hresult que se expande en sus puntos en Wikipedia: http://en.wikipedia.org/wiki/hresult.

En mi caso, el problema ha desaparecido tan misteriosamente como surgió. He creado una clase C ++ para llamar a la DLL regularmente. Mi esfuerzo original cargó la DLL inmediatamente antes de la primera llamada, y la almacenó en caché en la memoria. Esto es lo mismo en principio de cómo ha funcionado durante más de un año. Esto dio como resultado el misterioso error anterior.

Lo he refactorizado para cargar la DLL durante la construcción, pero solo extraer la función de ella en el momento de ejecución. Aparentemente, esto funciona, y es probablemente una mejor manera de hacerlo (cargar la DLL durante la construcción, liberarlo durante la destrucción). Como hay muy poco entre la construcción y la primera llamada a la DLL, no puedo ver por qué un método debería producir un error del sistema operativo, y el otro no.