.Net 4 constantly wasting one CPU core on StrongNameSignatureVerification

.net, cpu-usage, strongname

Solution

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.

Problem

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?

Original source