Acesse a violação ao executar o aplicativo nativo C ++ que usa DLL construída A /CLR
-
27-09-2019 - |
Pergunta
Estou reorganizando um aplicativo legado misto (gerenciado e não gerenciado) para que o segmento de aplicativos principal seja o MFC não gerenciado e que chamará uma DLL C ++ compilada com o sinalizador /CLR que preencherá a comunicação entre os gerenciados (DLLs C#) e o código não gerenciado . Infelizmente, minha alteração resultou em uma violação de acesso que ocorre antes que o aplicativo initInstance () seja chamado. Isso torna muito difícil depurar. A única informação que recebo é o seguinte rastreamento da pilha.
> 64006108()
ntdll.dll!_ZwCreateMutant@16() + 0xc bytes
kernel32.dll!_CreateMutexW@12() + 0x7a bytes
Então, aqui estão alguns sceanrios que eu tentei.
-LIGADO EXCEÇÕES-> VIBRAS DE VIBRAÇÃO-> C0000005 Violação de acesso para quebrar quando jogado. Ainda assim, o maior detalhe que recebo é do rastreamento da pilha acima. Eu tentei o aplicativo com F10, mas ele falha antes que quaisquer pontos de interrupção sejam atingidos e falhem com o rastreamento da pilha acima.
- Eu extrai a DLL da ponte para que ela tenha apenas um método que retorne um bool e esse método é codificado para retornar apenas false (nenhum código C# chamado).
bool DllPassthrough::IsFailed() { return false; }
Se a DLL forçada for compilada com o sinalizador /CLR, o aplicativo falhará. Se for compilado sem o sinalizador /CLR, o aplicativo será executado.
- Eu criei um aplicativo STUB MFC usando o assistente do Visual Studio para aplicações de multidocumentos e ligue para dllpassthrough :: isfailed (). Isso é bem -sucedido mesmo com o sinalizador /CLR usado para compilar a DLL.
- Eu tentei fazer uma biblioteca manual no WinMm.lib, conforme descrito na nota seguinte Acesse a violação ao usar C ++/CLI. O aplicativo ainda falha.
Então, minhas perguntas são como resolver o problema? Quaisquer dicas, estratégias ou incidentes anteriores. E, não, como posso obter mais informações sobre qual segmento de código ou biblioteca está causando a exceção de acesso? Se eu tentar soluções alternativas mais envolvidas, como fazer chamadas de bibliotecas, gostaria de reduzi -las às bibliotecas que fracassam.
Obrigado. BTW, estamos usando o Visual Studio 2008 e o projeto está sendo construído na estrutura .NET 2.0 para as seções gerenciadas.
Solução
Eu acredito que resolvo meu problema. Ao remover sistematicamente cada biblioteca de referência e comentando as chamadas para essa biblioteca específica no código do aplicativo (não gerenciado), finalmente removi a biblioteca de problemas e consegui o programa para executar. É uma maneira de força bruta de diagnosticar o problema e, felizmente, não precisei remover muitas bibliotecas para resolvê -lo. Eu ainda ficaria curioso se alguém tivesse um comentário se a biblioteca pudesse ter sido identificada pelo depurador.
Portanto, a próxima etapa é mover essas chamadas de biblioteca para o código gerenciado e transmitir as informações de volta para o lado não gerenciado através da minha DLL da ponte. Aliás, reintegrei o Winmm.lib no projeto e ele ainda funciona.