WinDbg: копия SOS.dll x86 4.0.30319.237 - PullRequest
       92

WinDbg: копия SOS.dll x86 4.0.30319.237

4 голосов
/ 07 декабря 2011

Я использую WinDbg для просмотра дампа процесса.Дамп был получен на сервере x86 с .NET 4 SP1 (4.0.30319.237).Я пытаюсь выполнить отладку на своем компьютере с архитектурой x64, используя версию WinDbg для x86, но у меня возникает следующая проблема:

0:000> !EEVersion
The version of SOS does not match the version of CLR you are debugging.  Please
load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.0.30319.237
SOS Version: 4.0.30319.239
4.0.30319.237 retail
Workstation mode
SOS Version: 4.0.30319.239 retail build

Поскольку на моем компьютере было установлено последнее исправление безопасности, файл SOS DLL теперьверсия 4.0.30319.239, поэтому я не могу использовать какие-либо расширения CLR в WinDbg.Я подключился к серверам символов Microsoft и получил правильную версию mscordacwks.dll.

Где я могу получить копию SOS.dll версии 4.0.30319.237?

Наилучшее совпадение, которое я получаю онлайнчерез Обновление надежности 1 для .NET Framework 4 .Однако, это не может быть установлено на моем компьютере (и у меня нет второго), поскольку это уже превышено.

Кошмар!

Ответы [ 3 ]

6 голосов
/ 08 декабря 2011

Я почти в такой же ситуации.

0:000> !EEVersion
The version of SOS does not match the version of CLR you are debugging.  Please
load the matching version of SOS for the version of CLR you are debugging.
CLR Version: 4.0.30319.235
SOS Version: 4.0.30319.239
4.0.30319.235 retail
Workstation mode
SOS Version: 4.0.30319.239 retail build

Я скачал и использовал psscor4, он не жалуется, и стек выглядит разумным

0:000> !psscor4.EEVersion
4.0.30319.235 retail
Workstation mode
SOS Version: 4.0.0.4 retail build
0:000> !psscor4.DumpStack
OS Thread Id: 0x874 (0)
Current frame: ntdll!KiFastSystemCallRet
ChildEBP RetAddr  Caller,Callee
002ec6c8 77d16a24 ntdll!NtWaitForSingleObject+0xc 
002ec6cc 758e6f0f mswsock!SockWaitForSingleObject+0x1ba , calling        ntdll!NtWaitForSingleObject
002ec70c 758e65cc mswsock!SockDoConnectReal+0x2c3 , calling    mswsock!SockWaitForSingleObject
002ec77c 71a63267 clr!GetCompileFlags+0x144 , calling clr!_EH_epilog3
002ec780 76ee2f7d ws2_32!WahReferenceContextByHandle+0x63 
002ec7a4 758e5fac mswsock!SockDoConnect+0x3a1 , calling mswsock!SockDoConnectReal
002ec7e4 76a82c6a kernel32!FlushInstructionCache+0x18 , calling     ntdll!ZwFlushInstructionCache

Вы могли быпопробуй!

5 голосов
/ 02 ноября 2012

Если на вашем аналитическом компьютере не установлена ​​точно такая же сборка .NET , которая была запущена на компьютере, на котором был получен дамп, вам действительно нужно больше, чем просто SOS.dll отdump machine.

  1. Получите следующие сборки: sos.dll, mscordacwks.dll и (возможно) mscorwks.dll (если .NET 2) или clr.dll (.NET 4).

  2. Поместите их все в каталог на машине анализа.В приведенных ниже примерах предполагается, что C:\Debug.

  3. Скопируйте, а затем переименуйте машину mscordacwks, чтобы отобразить номер платформы и сборки.Помните, что 64-битный в этом контексте обычно должен называться AMD64, если не из Itanium.

    Примеры:

    mscordacwks_x86_x86_2.0.50727.3625.dll

    или

    mscordacwks_AMD64_AMD64_4.0.30319.269.dll

  4. Откройте WinDbg и добавьте этот каталог в путь выполнения, чтобы найти переименованный mscordacwks.

    Пример: ".exepath + C: \ Debug"

  5. Явно загрузить соответствующий SOS

    Пример: ".load C: \ Debug \ sos"

Счастливая отладка!

5 голосов
/ 07 декабря 2011

Единственный способ исправить это - получить файл SOS.dll с компьютера, сгенерировавшего дамп. У меня такое случалось пару раз, и это было единственное решение, которое сработало для меня. Это действительно раздражает, что MS не устанавливает файлы SOS.dll для всех версий на сервер символов.

...