Ошибка блокировки загрузчика

Общая идея блокировки загрузчика: Система запускает код в DllMain внутри блокировки (как в блокировке синхронизации). Следовательно, выполнение нетривиального кода внутри DllMain «запрашивает тупик», как описано здесь.

Вопрос в том, почему вы пытаетесь запустить код внутри DllMain? Важно ли, чтобы этот код выполнялся внутри контекста DllMain, или вы можете создать новый поток и запустить в нем код, не дожидаясь завершения выполнения кода внутри DllMain?

Я считаю, что проблема с управляемым кодом, в частности, заключается в том, что запуск управляемого кода может включать загрузку CLR и тому подобное, и неизвестно, что там может произойти, что приведет к тупиковой ситуации ... Я бы не прислушался к совету «отключить это предупреждение» "на вашем месте, потому что, скорее всего, вы обнаружите, что ваши приложения неожиданно зависают при некоторых сценариях.

вам нужно перейти в меню «Отладка» -> «Исключения», открыть «Помощники по управляемой отладке», найти «LoaderLock» и снять флажок.

Эта проблема возникает из-за способа, которым отладчик в Visual Studio запускает управляемые приложения, использующие классы Microsoft Foundation версии 8.0 в одном или нескольких файлах DLL.

Прочтите внимательно: http://msdn.microsoft.com/en-us/library/aa290048(vs.71).aspx

Нажмите ctr d + e Затем выберите узел помощников по управляемой отладке. Затем снял флажок с LoaderLock.

Надеюсь, что это поможет вам.

Недавно я получил эту ошибку при создании экземпляра COM-объекта, написанного в машинном коде:

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

Это привело к описанной ошибке. Возникло исключение «LoaderLock обнаружен».

Я преодолел эту ошибку, создав экземпляр объекта в дополнительном потоке:

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

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

ОБНОВЛЕНИЕ ДЛЯ .NET 4.0 И БОЛЕЕ НЕДАВНИХ Фреймворков

Это старый вопрос, который задавали во времена .Net 2.0, когда поддержка библиотек DLL смешанного режима имела серьезные проблемы с инициализацией, склонные к случайным тупикам. Начиная с .Net 4.0, инициализация библиотек DLL смешанного режима изменилась. Теперь есть два отдельных этапа инициализации:

1. Собственная инициализация, вызываемая в точке входа DLL, которая включает встроенную настройку времени выполнения C++ и выполнение вашего метода DllMain.
2. Управляемая инициализация, автоматически выполняемая загрузчиком системы.

Поскольку шаг №2 выполняется вне Loader Lock, взаимоблокировок нет. Подробности описаны в Инициализация смешанных сборок.

Чтобы гарантировать, что ваша сборка в смешанном режиме может быть загружена из собственного исполняемого файла, единственное, что вам нужно проверить, - это то, что метод DllMain объявлен как собственный код. #pragma unmanaged может здесь помочь:

#pragma unmanaged

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

Также важно, чтобы любой код, который DllMain может вызывать прямо или косвенно, также был неуправляемым. Имеет смысл ограничить тип функциональности, используемой DllMain, чтобы вы отслеживали весь код, доступный из DllMain, и обеспечивали его компиляцию с #pragma unmanaged.

Компилятор немного помогает, предупреждая C4747, если он обнаруживает, что DllMain не объявлен как неуправляемый:

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

Однако компилятор не будет генерировать никаких предупреждений, если DllMain косвенно вызывает какую-либо другую управляемую функцию, поэтому вам нужно убедиться, что этого никогда не произойдет, иначе ваше приложение может случайным образом заблокироваться.

Я создаю C++ CLR DLL (MSVS2015), которая должна вызывать неуправляемую DLL и определять неуправляемый код. Я использую #pragma managed и #pragma unmanaged, чтобы контролировать, в каком режиме он находится для данной области кода.

В моем случае я просто поставил #pragma unmanaged перед DllMain (), и это решило проблему. Похоже, он думал, что мне нужна управляемая версия DllMain ().

напомните тем Пользователи VS2017, что вам нужно отключить «помощник по исключению» вместо «помощник по исключениям» (до VS2017), чтобы предотвратить ошибку блокировки загрузчика, путь установки которой - Отладка-> Исключение. Просто побежал к этой проблеме и потратил 2 часа на поиск решений ...

Путь настройки в моем экземпляре Visual Studio 2017: Отладка -> Windows -> Параметры исключений. «Окно» настроек исключения появилось в нижней группе вкладок (в отличие от отдельного окна), и мне потребовалось время, чтобы это заметить. Ищите "загрузчик".