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

Question

我们有一个在 .Net 4、Windows 2008 R2 上运行的混合模式程序集应用程序 (MFC+WinForms)，它在一个线程上不断使用 100% 的 CPU。

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

旋转线程不会阻止应用程序的其余部分运行，但会浪费 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.sll!StrongNameSignatureVerification CPU consumption虽然线程似乎已经变冷了。

我们不签署我们的程序集并且愿意信任它们，有没有办法完全禁用强名称验证？

Answer 1

clr.dll!StrongNameSignatureVerification+0x164d9

这不会像你认为的那样做。标识符右侧的数字很重要，它给出了经过 StrongNameSignatureVerification 函数地址的已知位置的字节数。那是 91353 个字节，很多。你唯一能看出的是它是 不是 执行 StrongNameSignatureVerification，该函数几乎没有那么长。堆栈跟踪中的其余标识符同样不可靠。

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

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

启用符号服务器很容易，MSDN 页面 is here .