问题
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?
回答1:
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.
回答2:
You might consider using the profiling tools in visual studio to identify hotspots in your code that could be contributing to this problem. To get symbol support for the .net CLR see this link.
http://blogs.msdn.com/b/sburke/archive/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code.aspx
来源：https://stackoverflow.com/questions/14954387/net-4-constantly-wasting-one-cpu-core-on-strongnamesignatureverification