.Net 4 постоянно тратит одно ядро процессора на StrongNameSignatureVerification

У нас есть приложение для сборки в смешанном режиме (MFC + WinForms), работающее на .Net 4, Windows 2008 R2, которое постоянно использует 100% ЦП в одном потоке.

Используя ProcessExplorer, мы видим следующий стек в занятом потоке. Мы также можем видеть еще 10 потоков, использующих только 0,01% ЦП, которые работают с clr.dll! StrongNameSignatureVerification.

Вращающаяся нить нене позволяет остальной части приложения работать, но тратит впустую процессорное время.

Трассировка стека занятого потока выглядит следующим образом:

ntoskrnl.exe!IoAcquireRemoveLockEx+0xe7
ntoskrnl.exe!memset+0x22a
ntoskrnl.exe!KeWaitForSingleObject+0x2cb
ntoskrnl.exe!KeDetachProcess+0x120d
ntoskrnl.exe!PsReturnProcessNonPagedPoolQuota+0x3a3
ntoskrnl.exe!CcSetDirtyPinnedData+0x433
mscorlib.ni.dll+0x2b066a
mscorlib.ni.dll+0x2317ac
mscorlib.ni.dll+0x2b066a
mscorlib.ni.dll+0x2317ac
mscorlib.ni.dll+0x26ccf7
mscorlib.ni.dll+0x237fc4
mscorlib.ni.dll+0x26cc3c
clr.dll+0x21bb
clr.dll!CoUninitializeEE+0xee9b
clr.dll!CoUninitializeEE+0x11463
clr.dll!CoUninitializeEE+0x114dc
clr.dll!CoUninitializeEE+0x1154b
clr.dll!StrongNameErrorInfo+0xa638
clr.dll!StrongNameSignatureVerification+0x144fb
clr.dll!StrongNameSignatureVerification+0x1457d
clr.dll!StrongNameSignatureVerification+0x14638
clr.dll!StrongNameSignatureVerification+0x146d2
clr.dll!StrongNameErrorInfo+0x9977
clr.dll!StrongNameErrorInfo+0xa5bc
clr.dll!StrongNameErrorInfo+0xa553
clr.dll!StrongNameErrorInfo+0xa517
clr.dll!StrongNameErrorInfo+0xa151
clr.dll!StrongNameErrorInfo+0x9501
clr.dll!StrongNameErrorInfo+0xad67
clr.dll!StrongNameSignatureVerification+0x164d9
ntdll.dll!RtlCreateUserProcess+0x8c
ntdll.dll!RtlCreateProcessParameters+0x4e

Единственный подобный аккаунт, который яудалось найти вот в этом вопросе:clr.sll! StrongNameSignatureVerification Загрузка процессора хотя нить, кажется, остыла.

Мы неt подписать наши сборки и готовы доверять им, есть ли способ полностью отключить проверку строгого имени?

 chillitom25 февр. 2013 г., 16:47
Это может быть последним средством, поскольку для этого потребуется отключить проверку на каждой машине, на которой развернут код. Мы'на самом деле не получают ошибок со строгими именами и не уверены, на какие (если они есть) библиотеки DLL тратит все свое время, поэтому отключение проверки не является простым делом.
 Simon Mourier25 февр. 2013 г., 14:34
Ой, прости, тыверно. Как насчет этого:ryangerard.net/post/8768827919/...
 Simon Mourier25 февр. 2013 г., 18:26
Можно ли получить более точный кадр стека, чтобы получить больше информации о том, чтопроисходит? Например, если вы отлаживаете процесс с помощью Visual Studio или Windbg, но правильно ли настроены загруженные символы Microsoft? (support.microsoft.com/kb/311503)
 chillitom25 февр. 2013 г., 14:23
@SimonMourier - да, из моего понимания это отключаетбайпас тем самым все проверки подлежат строгой проверке подписи, что является противоположностью того, что ям после.
 v.oddou03 мар. 2014 г., 08:50
У меня также есть эта проблема, и я вижу такой же стек. Я пытался поместить sym-сервер в проводник процессов напрямую, но с большой вероятностью.
 Simon Mourier25 февр. 2013 г., 14:14

Ответы на вопрос(2)

Решение Вопроса

clr.dll! StrongNameSignatureVerification + 0x164d9

Это не делает то, что вы думаете, что делает. Важно число справа от идентификатора, которое дает число байтов после известного местоположения адреса функции StrongNameSignatureVerification. Тот's 91353 байта, это много. Единственное, что вы можете сказать, это то, что этоне выполняя StrongNameSignatureVerification, функция не такая длинная. Остальные идентификаторы в трассировке стека одинаково ненадежны.

Проблема в том, что отладчик неу меня нет файла PDB для этих DLL. Он может только обнаружить адрес экспортируемых функций, он нене знаю достаточно обо всех функциях между ними. Вы можете доверять отображаемому имени, только если смещение меньше 0x100 байт. Дай или возьми.

Вам нужно будет получить эти файлы PDB, чтобы знать, что на самом деле происходит. Это требует включения Microsoft Symbol Server. Отладчик загрузит необходимые файлы PDB с этого сервера при запуске отладки. Вы'Теперь я получу гораздо более надежные символы, что поможет вам лучше понять, что на самом деле выполняет код.

Включить сервер символов легко, страница MSDNэто здесь.

 chillitom12 мар. 2014 г., 15:04
Для записи, после правильной загрузки символов, как описано Хансом, я мог видеть, что проблема была связана с ошибкой в NLog 's асинхронный код регистрации (github.com/NLog/NLog/issues/162).
 chillitom04 мар. 2013 г., 10:00
Спасибо Ганс - отличное место! Можно ли предположить, что имена сборок верны?
 Hans Passant04 мар. 2013 г., 13:18
Да, они верны. В стеке находится только mscorlib, остальные - CLR и исполняемые файлы операционной системы.

Вы можете рассмотреть возможность использования инструментов профилирования в Visual Studio для определения горячих точек в вашем коде, которые могут способствовать этой проблеме. Чтобы получить поддержку символов для .net CLR, перейдите по этой ссылке.

http://blogs.msdn.com/b/sburke/archive/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code.aspx

Ваш ответ на вопрос