Кто-нибудь сталкивался с разрывом отладчика INT 3 в mscorwks.dll? - PullRequest
4 голосов
/ 24 ноября 2008

Мы размещаем среду выполнения .NET как часть программы Win32, и в последнее время она начала последовательно ломаться по определенному адресу, в mscorwks.dll.

По указанному адресу находится байт 0xCC, который является инструкцией INT 3, которая запускает отладчик.

Кто-нибудь еще видел это?

Я не вижу достаточно информации в dll, чтобы точно знать, где она находится, функция или источник, но ее точно нет ни в одной из наших библиотек.

Стек вызовов выглядит следующим образом (это из Delphi 2007):

:7a04f02a ; C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
:7a052fc6 ; C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
:7a053e72 ; C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
:7a03b970 ; C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
:7a00351e ; C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
:7a0255e0 ; C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
:79e71e6d ; C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
:7e42b372 USER32.MoveWindow + 0xd4
:7e4565b7 USER32.GetRawInputDeviceInfoW + 0x5f
:7e42ce7c USER32.SetLayeredWindowAttributes + 0x6a

Адрес, на котором происходит сбой, - 0x7A04F029, разборка в памяти выглядит следующим образом:

7A04F020 call $7a14be35
7A04F025 cmp [esi],ebx
7A04F027 jz $7a04f02a
7A04F029 int 3                      <-- here's the culprit
7A04F02A mov byte ptr [ebp-$04],$02
7A04F02E lea ecx,[ebp-$00000224]
7A04F034 call $79e82214

От него достаточно легко избавиться, просто каждый раз исправляйте этот байт в памяти с помощью 0x90 (NOP), но в следующий раз, когда мы запускаем отладчик, dll, конечно, перезагружается.

У меня есть полумрака, чтобы попытаться исправить сам файл, но я не уверен, что это тоже хорошая идея. Я проверил, что байт CC является частью dll, нашел шаблон окружающего байта с помощью шестнадцатеричного редактора.

Любые советы, как это исправить? Кто-нибудь еще видел это?

решаемые

Как уже упоминалось в ответах, это была проблема LoaderLock. Библиотека DLL, которая была встроена в Win32, должна была предоставить пару функций для нашей системы .NET, не привязанную к тому, как мы размещаем среду выполнения .NET. Проект включал в себя несколько модулей, которые содержали функции, которые должны были быть представлены, но, к сожалению, также добавили много-много кода, который был полезен в приложении, но не для этой DLL.

Разделение необходимых мне функций уменьшило размер DLL с 7 МБ до примерно 100 КБ, а также избавилось от LoaderLock.

Ответы [ 2 ]

2 голосов
/ 24 ноября 2008

Здесь обсуждается похожая проблема здесь . Самая интересная часть это:

Mscorwks.dll - это просто мессенджер. Он говорит вам, что обнаружил блокировку загрузчика. Это ваш код, который вызвал его.

0 голосов
/ 24 ноября 2008

Вы должны быть в состоянии получить символы для mscorwks - у меня есть несколько версий здесь, поэтому MS Symserv определенно служил им в прошлом.

Это может помочь понять, что происходит немного больше.

Из-за того, что у вас есть трассировка в USER32.dll, я подозреваю, что у вас уже настроены некоторые символы, но если нет, то это может помочь: http://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx

Я сам не пользуюсь Delphi, но, полагаю, он использует dbghelp.dll для работы с символами / PDB, поэтому его можно настроить с помощью symserv, даже если у него нет явного пользовательского интерфейса для помощи.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...