.NET 4中不断对StrongNameSignatureVerification浪费一颗CPU核心 [英] .Net 4 constantly wasting one CPU core on StrongNameSignatureVerification

查看:1094
本文介绍了.NET 4中不断对StrongNameSignatureVerification浪费一颗CPU核心的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们有一个混合模式组件的应用程序(MFC +的WinForms)在.NET 4中运行时,Windows 2008 R2中经常使用100%的CPU在一个线程。

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

纺纱线未prevent应用从静止运行,但浪费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
 

唯一类似的帐户我已经能够找到的是这样一个问题:<一href="http://stackoverflow.com/questions/7303315/clr-sllstrongnamesignatureverification-cpu-consumption">clr.sll!StrongNameSignatureVerification CPU消耗虽然线程似乎已经凉了。

我们不签我们的组件,并愿意信任他们,有没有办法完全禁用强名称验证?

解决方案
  

clr.dll!StrongNameSignatureVerification + 0x164d9

这并没有做什么,你认为它。在标识符的权利的数目是重要的,给出了以往StrongNameSignatureVerification函数地址的已知位置的字节数。这是91353字节,这是一个很大。你可以从那个唯一的一点是,它的不可以执行StrongNameSignatureVerification,该功能没有这么长。在堆栈跟踪的标识符的其余部分也同样不可靠。

的问题是,调试器不具有PDB文件为这些DLL。它只能发现的导出函数的地址,它不知道有足够的了解其间的所有功能。你只能相信显示的名称,如果偏移小于约0x100的字节。给予或采取。

您将需要获得这些PDB文件就知道什么是真正回事。这需要启用Microsoft符号服务器。调试器将来自该服务器在开始调试时下载所需的PDB文件。现在你会得到更可靠的符号,让您真正执行什么code更好的洞察力。

启用符号服务器很容易,在MSDN页的在这里

We have a mixed mode assembly application (MFC+WinForms) running on .Net 4, Windows 2008 R2 that constantly uses 100% cpu on one thread.

Using ProcessExplorer we see the following stack on the busy thread. We can also see another 10 threads using just 0.01% CPU that are running clr.dll!StrongNameSignatureVerification.

The spinning thread doesn't prevent the rest of the application from running but wastes CPU time.

The stack trace of the busy thread is as follows:

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

The only similar account I've been able to find is in this question: clr.sll!StrongNameSignatureVerification CPU consumption though the thread seems to have gone cold.

We don't sign our assemblies and are willing to trust them, is there a way to completely disable the strong name verification?

解决方案

clr.dll!StrongNameSignatureVerification+0x164d9

This does not do what you think it does. The number at the right of the identifier is important, that gives the number of bytes past the known location of the StrongNameSignatureVerification function address. That's 91353 bytes, that is a lot. The only thing you can tell from that is that it is not executing StrongNameSignatureVerification, the function is not nearly that long. The rest of the identifiers in the stack trace are equally unreliable.

The problem is that the debugger doesn't have a PDB file for these DLLs. It can only discover the address of exported functions, it doesn't know enough about all the functions in between. You can only trust the displayed name if the offset is less than about 0x100 bytes. Give or take.

You will need to get these PDB files to know what is really going on. That requires enabling the Microsoft Symbol Server. The debugger will download the required PDB files from that server when you start debugging. You'll now get much more reliable symbols, giving you much better insight in what code is really executing.

Enabling the symbol server is easy, the MSDN page is here.

这篇关于.NET 4中不断对StrongNameSignatureVerification浪费一颗CPU核心的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆