Erro de bloqueio do carregador

Estou construindo em dll C ++, escrevendo código em C #.

Recebo um erro, dizendo

LoaderLock foi detectado Mensagem: Tentativa de execução gerenciada dentro do bloqueio do carregador do SO. Não tente executar código gerenciado dentro de um DllMain ou função de inicialização de imagem, pois isso pode causar o travamento do aplicativo.

Eu tentei pesquisar o que esse erro significa exatamente, mas estou desenhando artigos inúteis, a maioria dizendo que é apenas um aviso, e devo desligar isso no Visual Studio. As outras soluções parecem ser devido ao iTunes, ou este problema que ocorre durante a programação com DirectX. Meu problema não está relacionado a nenhum deles.

Alguém pode explicar o que isso realmente significa?

você precisa ir para o menu Depurar -> Exceções, abrir os Assistentes de depuração gerenciados, encontrar LoaderLock e desmarcar

A ideia geral do bloqueio do carregador: O sistema executa o código em DllMain dentro de um bloqueio (como em - bloqueio de sincronização). Portanto, executar um código não trivial dentro do DllMain é "pedir um deadlock", conforme descrito aqui .

A questão é: por que você está tentando executar o código dentro do DllMain? É crucial que esse código seja executado dentro do contexto de DllMain ou você pode gerar um novo thread e executar o código nele, e não esperar que o código termine a execução dentro de DllMain?

Acredito que o problema com o código gerenciado, especificamente, é que a execução do código gerenciado pode envolver o carregamento do CLR e coisas semelhantes e não há como saber o que poderia acontecer lá que resultaria em um deadlock ... Eu não daria ouvidos ao conselho de "desabilitar este aviso "se eu fosse você, porque muito provavelmente você descobrirá que seus aplicativos travam inesperadamente em alguns cenários.

ATUALIZAÇÃO PARA .NET 4.0 E MAIS FRAMEWORKS RECENTES

Essa é uma pergunta antiga feita na época do .Net 2.0, quando o suporte para DLLs de modo misto apresentava sérios problemas de inicialização, sujeitos a deadlocks aleatórios. A partir do .Net 4.0, a inicialização de DLLs de modo misto foi alterada. Agora, existem dois estágios separados de inicialização:

1. Inicialização nativa, chamada no ponto de entrada da DLL, que inclui configuração nativa em tempo de execução C ++ e execução de seu método DllMain.
2. Inicialização gerenciada, executada automaticamente pelo carregador do sistema.

Como a etapa 2 é executada fora do Loader Lock, não há deadlocks. Os detalhes são descritos em Inicialização de montagens mistas .

Para garantir que seu assembly de modo misto possa ser carregado de um executável nativo, a única coisa que você precisa verificar é se o método DllMain é declarado como código nativo. #pragma unmanagedpoderia ajudar aqui:

#pragma unmanaged

BOOL APIENTRY DllMain(HMODULE hModule,
    DWORD  ul_reason_for_call,
    LPVOID lpReserved
    )
{
    ... // your implementation here
}

Também é importante que qualquer código que DllMain possa chamar direta ou indiretamente também não seja gerenciado. Faz sentido limitar o tipo de funcionalidade usada pelo DllMain para que você rastreie todo o código acessível a partir do DllMain e garanta que foi compilado com ele #pragma unmanaged.

O compilador ajuda um pouco, avisando C4747 se detectar que DllMain não foi declarado como não gerenciado:

1>  Generating Code...
1>E:\src\mixedmodedll\dllmain.cpp : warning C4747: Calling managed 'DllMain': Managed code may not be run under loader lock, including the DLL entrypoint and calls reached from the DLL entrypoint

No entanto, o compilador não gerará nenhum aviso se DllMain chamar indiretamente alguma outra função gerenciada, portanto, você precisa garantir que isso nunca aconteça, caso contrário, seu aplicativo pode travar aleatoriamente.

Pressione ctr d + e Em seguida, gaste o nó Assistentes de depuração gerenciada. Em seguida, desmarque o LoaderLock.

Espero que isso ajude você.

lembre os usuários do VS2017 de que você precisa desabilitar o " auxiliar de exceção " em vez do " assistente de exceção " (antes do VS2017) para evitar o erro de bloqueio do carregador, cujo caminho de configuração é Depurar-> Exceção . Corri para esse problema e perdi 2 horas procurando soluções ...

Recentemente, recebi este erro ao criar uma instância de um objeto COM escrito em código nativo:

m_ComObject = Activator.CreateInstance(Type.GetTypeFromProgID("Fancy.McDancy"));

Isso levou ao erro descrito. Um "LoaderLock foi detectado" - exceção foi lançada.

Superei esse erro criando a instância do objeto em um thread extra:

ThreadStart threadRef = new ThreadStart(delegate { m_ComObject = Activator.CreateInstance(Type.GetTypeFromProgID("Fancy.McDancy")); });
Thread myThread = new Thread(threadRef);

myThread.Start();
myThread.Join(); // for synchronization

Estou construindo uma DLL C ++ CLR (MSVS2015) que precisa fazer chamadas para uma DLL não gerenciada e definir o código não gerenciado. Eu uso #pragma gerenciado e #pragma não gerenciado para controlar em que modo está para uma determinada área do código.

No meu caso, simplesmente coloquei #pragma unmanaged na frente do meu DllMain () e isso resolveu o problema. Parecia que eu queria uma versão gerenciada de DllMain ().

Esse problema ocorre devido à maneira como o depurador no Visual Studio executa aplicativos gerenciados que usam o Microsoft Foundation Classes versão 8.0 em um ou mais arquivos DLL.

Faça uma leitura completa em: http://msdn.microsoft.com/en-us/library/aa290048(vs.71).aspx

O caminho de configuração em minha instância do Visual Studio 2017 é Debug -> Windows -> Configurações de exceção. A "janela" de configurações de exceção apareceu no grupo da guia inferior (ao contrário de uma janela separada), demorei um pouco para perceber. Procure por "carregador".