LoadLibraryw Retorna Nullptr e GetLasterRor () Retorna 3221225619

Question

Descrever os problemas que tenho demorado muito, mas o problema no final afiado é:

1. O loadlibraryw falha (retorna nullptr) quando recebe um caminho válido.

2. O Monitor do Processo registra não falhas suspeitas, ou mesmo qualquer coisa diferente de quando conseguir carregar a DLL (que pode em outro contexto).

3. A DLL não possui dependências não-sistemas.

4. ... e o pior de tudo, o código de erro do Windows retornado pelo GetLasterRor é 3221225619.

Supondo que 3221225619 não seja um código de erro válido, o que poderia estar dando tão errado que o Windows nem sequer tem um código de erro para isso?

EDITAR:

Eu acho que algumas pessoas queriam mais detalhes sobre o próprio fracasso:

• Não parece ser a entrada - é idêntica na versão de trabalho e falha, e o loadlibraryw declarou com sucesso "o arquivo não existe" quando a sequência de entrada foi mutilada. A entrada atual é codificada, deixando pouco espaço para erro.
• A DLL é compilada no lançamento e o código de chamada no Debug. Faço isso há 18 meses sem problemas, mas você nunca sabe.
• O Pacote de Monitor do Process relata cerca de 30 operações internas em execução no LoadLibraryw, incluindo createfile, loadImage, RegopenKey. Estes são idêntico Para a chamada de trabalho e a chamada falhada, até os tamanhos dos arquivos e os locais da memória.
• Não há corrupção óbvia de memória no objeto C ++ chamando -o e, como eu disse, o Monitor do Process fornece o mesmo endereço de imagem base nos dois casos.
• O fracasso é 100% consistente - o mesmo tempo, o mesmo local sempre.

Answer 1

Desculpe, isso não é exatamente uma resposta, mas o problema foi resolvido.

Para começar, acabei de notar uma pergunta semelhante aqui: C ++ Loadlibrary () Erro 3765269347. Eu acho que este dá mais detalhes e vale a pena dar uma olhada se você estiver em uma posição semelhante ao que eu era.

Meus agradecimentos a @whozcraig, @danieldaranas e todos os outros que fizeram comentários úteis. Para outras pessoas lendo isso, há um bom artigo sobre o HRESULT que se expande em seus pontos na Wikipedia: http://en.wikipedia.org/wiki/hresult.

No meu caso, o problema desapareceu tão misteriosamente quanto surgiu. Eu criei uma classe C ++ para chamar a DLL regularmente. Meu esforço original carregou a DLL imediatamente antes da primeira chamada e em cache na memória. É o mesmo em princípio de como funciona por mais de um ano. Isso resultou no misterioso erro acima.

Eu o refatorei para carregar a DLL durante a construção, mas para extrair apenas a função dele no tempo de execução. Aparentemente, isso funciona e provavelmente é uma maneira melhor de fazê -lo (carregando a DLL durante a construção, liberando -a durante a destruição). Como há muito pouco acontecendo entre a construção e a primeira chamada para a DLL, não consigo ver por que um método deve produzir um erro do sistema operacional e o outro não.