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

Я строю на C ++ dll, написав код на C #.

Я получаю сообщение об ошибке

LoaderLock был обнаружен. Сообщение: Попытка управляемого выполнения внутри блокировки загрузчика ОС. Не пытайтесь запускать управляемый код внутри функции инициализации DllMain или изображения, поскольку это может привести к зависанию приложения.

Я попытался выяснить, что именно означает эта ошибка, но рисую бессмысленные статьи, в основном говоря, что это всего лишь предупреждение, и я должен отключить его в Visual Studio. Другие решения, похоже, связаны с ITunes или этой проблемой, возникающей при программировании с помощью DirectX. Моя проблема ни с чем не связана.

Кто-нибудь может объяснить, что это на самом деле означает?

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

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

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

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

ОБНОВЛЕНИЕ ДЛЯ .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 косвенно вызывает какую-либо другую управляемую функцию, поэтому вам нужно убедиться, что этого никогда не произойдет, иначе ваше приложение может случайно заблокироваться.

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

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

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

Недавно я получил эту ошибку при создании экземпляра 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

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

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

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

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

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