.Net 4不断在StrongNameSignatureVerification上浪费一个CPU核

我们有一个在.NET4、Windows2008R2上运行的混合模式汇编应用程序（MFC+WinForms），它在一个线程上持续使用100%的cpu

使用ProcessExplorer，我们可以在繁忙线程上看到以下堆栈。我们还可以看到另外10个线程仅使用0.01%的CPU运行clr.dll！strong名称签名

旋转线程不会阻止应用程序的其余部分运行，但会浪费CPU时间

繁忙线程的堆栈跟踪如下所示：

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.dll！strong名称签名签名+0x164d9

这和你想象的不一样。标识符右侧的数字很重要，它给出了超出StrongNameSignatureVerification函数地址已知位置的字节数。这是91353字节，太多了。从中可以看出，它不是执行StrongNameSignatureVerification，而是执行StrongNameSignatureVerification，函数没有那么长。堆栈跟踪中的其余标识符同样不可靠

问题是调试器没有用于这些DLL的PDB文件。它只能发现导出函数的地址，对其中的所有函数了解不够。如果偏移量小于约0x100字节，则只能信任显示的名称。给予或接受

您需要获取这些PDB文件，以了解实际情况。这需要启用Microsoft Symbol服务器。开始调试时，调试器将从该服务器下载所需的PDB文件。现在，您将获得更可靠的符号，从而更好地了解代码真正执行的内容

---

启用符号服务器是很容易的，MSDN页。

< P>您可以考虑使用VisualStudio中的分析工具来识别代码中可能导致此问题的热点。要获取.net CLR的符号支持，请参阅此链接

---

你看到了吗@SimonMourier-是的，据我所知，这会禁用“旁路”，从而导致所有程序集都要接受强名称签名验证，这与我所追求的正好相反。哦，对不起，你说得对。这是怎么回事：这可能是最后的手段，因为它需要在部署代码的每台机器上禁用验证。我们实际上没有收到任何强名称错误，也不确定验证将所有时间都花在哪些DLL（如果有）上，因此禁用验证并不简单。是否有可能获得更准确的堆栈帧，以获得更多关于发生了什么的信息？例如，如果使用Visual Studio或Windbg调试进程，但正确配置加载的Microsoft符号？谢谢你，汉斯-好极了！我可以假定程序集名称是正确的吗？是的，它们是正确的。堆栈上只有mscorlib，其余的是CLR和操作系统可执行文件。根据记录，在按照Hans的描述正确加载符号后，我可以看出问题与NLog的异步日志代码（）中的错误有关。