Можно ли заставить WinDBG найти mscordacwks.dll в хранилище символов?

Вопрос

Существует множество ручных способов заставить WinDBG найти mscordacwks.dll без хранилища символов (поместить файл куда-нибудь в путь, поместить его в ту же папку, что и windbg.exe, поместить в папку Framework\v, указав путь в Использование WinDBG .cordll -lp c:\dacFolder и т. д.), но все они только исправляют это для меня. Мне нужно исправить это более широко для всех, кто использует мой магазин символов.

Возможные решения, которые я могу себе представить:

  • WinDBG должен проверять хранилище символов, используя имя подпапки mscordacwks.dll вместо имени папки mscorwks.dll.
  • SymStore.exe необходимо добавить mscordacwks.dll в имя подпапки mscorwks.dll, чтобы WinDBG обнаружил его при просмотре.

Q: Возможно ли что-то из этого, или есть другой способ, которым я не думаю, чтобы решить проблему?

Фон

При анализе процесса.NET я столкнулся с (по-видимому, распространенной) проблемой, заключающейся в том, что psscor2 (и sosex) не смогли найти соответствующий файл mscordacwks.dll на моем компьютере. Ошибка в WinDBG:

Failed to load data access DLL, 0x80004005 
Verify that 1) you have a recent build of the debugger (6.2.14 or newer) 
            2) the file mscordacwks.dll that matches your version of mscorwks.dll is 
                in the version directory 
            3) or, if you are debugging a dump file, verify that the file 
                mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path. 
            4) you are debugging on the same architecture as the dump file. 
                For example, an IA64 dump file must be debugged on an IA64 
                machine.

You can also run the debugger command .cordll to control the debugger's 
load of mscordacwks.dll.  .cordll -ve -u -l will do a verbose reload. 
If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable 
path is pointing to mscorwks.dll as well.

Есть множество SO вопросов на это и множество хороших ответов, практически все из которых в конечном счете ссылаются на выдающийся пост в блоге Дуга Стюарта, Что такое mscordacwks.dll?,

Благодаря этому я исправил ситуацию, получив правильный файл mscordacwks.dll и разместив его здесь:

"C:\Symbols\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll\4E1545829a3000\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll"

где я знал, что WinDBG будет смотреть, потому что я ранее пробовал это с !sym noisy,

Итак, все готово, но я должен был поместить его в этот путь физически, а не добавлять его на свой сервер символов через обычный symstore.exe механизм. Так как мой магазин символов используется не только мной, я должен сделать это правильно для всех, кто использует магазин.

И это проблема. Когда я добавляю с помощью symstore.exe вместо того, чтобы идти по вышеуказанному пути, он идет в:

"C:\Symbols\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll\4E1545CB1bd000\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll"

Единственная разница в том, что имя подпапки 4E1545CB1bd000 здесь вместо 4E1545829a3000 что WinDBG ищет.

Причина этого заключается в том, что при добавлении двоичного файла в хранилище символов symstore.exe использует PE двоичного файла для получения метки времени изображения и размера изображения. В случае этого конкретного.dll, dumpbin.exe /headers mscordacwks.dll показывает, что это:

  • метка времени изображения: 0x4E1545CB (Чт 07 июля 01:36:11 2011)
  • Размер изображения: 0x1BD000

Следовательно, имя подпапки 4E1545CB1BD000,

WinDBG, с другой стороны, ищет подпапку, основанную на временной метке изображения и размере изображения mscorwks.dll, а не mscordacwks.dll, поскольку первая загружается в процесс, а не вторая. WinDBG не может знать временную метку и размер модуля DAC, потому что этот модуль не находится в дампе процесса.

В качестве дополнительной проверки этого объяснения, dumpbin.exe /headers mscorwks.dll показывает:

  • метка времени изображения: 0x4E154582 (Чт 07 июля 01:34:58 2011)
  • Размер изображения: 0x9A3000

который вы можете увидеть добавить в имя подпапки 4E1545829A3000,

Зная об этом, теперь стало намного понятнее, почему все эти многочисленные версии mscordacwks.dll, с которыми люди продолжают сталкиваться, отсутствуют на серверах символов Microsoft. Я уверен, что они там, просто WinDBG и psscor2 не могут их найти, потому что они выбирают неправильное имя подпапки. Почему это даже мешает искать путь к символам, мне не понятно, потому что он гарантированно никогда не найдет его!

Так что это мой вызов. Могу ли я как-то заставить symstore.exe добавить mscordacwks.dll, используя информацию PE для mscorwks.dll? Если нет, я что-то упускаю из-за WinDBG и psscor2, возможно, у них есть способ узнать правильную временную метку и размер файла mscordacwks.dll, даже если он не загружен (и способ фактически использовать их вместо mscorwks.dll).)?

Источник

2 ответа

Решение

Так как никакого другого решения не появилось, и мой обходной путь, кажется, справляется со всем хорошо, я просто буду продолжать с этим, и я бы порекомендовал любого другого, кто никогда не хочет видеть раздражающее Failed to load data access DLL, 0x80004005 Ошибка снова сделать то же самое.

Поэтому, чтобы сделать эту работу для вас (и для всех, кто использует ваше хранилище символов, поэтому я очень хочу, чтобы Microsoft сделала это, чтобы избавить нас от многих проблем), просто поместите сжатый файл DAC (mscordacwks.dl_) вручную в правильный путь. в вашем местном магазине SYM.

Вот шаги, которые я выполняю для достижения этой цели:

  1. В WinDBG сделать !sym noisy
  2. В WinDBG сделать .cordll -ve -u -l
  3. В WinDBG делай другое !CLRStack или другая команда psscor2, если необходимо, чтобы она снова загружала символы
  4. Журнал поиска по символам покажет dll, которую он ищет и где он ищет в вашем хранилище символов, показав такие строки: C:\Symbols\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll\4E1545829a3000\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll что указывает на две вещи:
  5. Получив файл, переименуйте его в соответствии с именем, которое ищет WinDBG, например, "mscordacwks_AMD64_AMD64_2.0.50727.4216.dll"
  6. Вручную сожмите этот файл, используя makecab.exe следующим образом: makecab /D CompressionType=LZX /D CompressionMemory=21 mscordacwks_AMD64_AMD64_2.0.50727.4216.dll mscordacwks_AMD64_AMD64_2.0.50727.4216.dl_
  7. Скопируйте этот сжатый файл в ожидаемое место в хранилище символов. (Это вы нашли в шаге 4 выше, поэтому C:\Symbols\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll\4E1545829a3000\mscordacwks_AMD64_AMD64_2.0.50727.4216.dl_ в нашем примере выполнения здесь.)
Источник

Вы должны поместить DLL CLR и связанную DLL mscordacwks в одну и ту же папку и зарегистрировать DLL CLR в symstore. В этом случае symstore добавит clr и mscordacwks dll в хранилище символов.

Что еще более важно, он будет использовать временную метку и размер файла библиотеки DLL для создания подпапки mscordacwks, поэтому windbg может найти библиотеку mscordacwks при отладке дампа.

Имя mscordacwks должно следовать шаблону mscordacwks_ARCH_ARCH_fileversion, иначе symstore не добавит его в хранилище символов.

Я не нашел никакой документации по этой функции, поэтому она может быть удалена в будущем.

Вот команда и вывод symstore:

symstore.exe add /o /f 4.6.1076.00\clr.dll /t clr.dll /s \\mystore\microsoft
SYMSTORE MESSAGE: 0 alternate indexers registered
SYMSTORE MESSAGE: LastId.txt reported id 0
SYMSTORE MESSAGE: History.txt reported id 58228
SYMSTORE MESSAGE: Final id is 0000058228
SYMSTORE MESSAGE: Copying C:\Users\build.robot\symstore\4.6.1076.00\clr.dll to \\mystore\microsoft\clr.dll\56D79ED4990000\clr.dll [Force: T, Compress: F]
SYMSTORE MESSAGE: Copying 4.6.1076.00\mscordacwks_AMD64_AMD64_4.6.1076.00.dll to \\mystore\microsoft\mscordacwks_AMD64_AMD64_4.6.1076.00.dll\56D79ED4990000\mscordacwks_AMD64_AMD64_4.6.1076.00.dll [Force: T, Compress: F]

SYMSTORE: Number of files stored = 2
SYMSTORE: Number of errors = 0
SYMSTORE: Number of files ignored = 0
Источник
Другие вопросы по тегам