Acesse a violação ao executar o aplicativo nativo C ++ que usa DLL construída A /CLR

Question

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.

Answer 1

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.