.Net 4 constantly wasting one CPU core on StrongNameSignatureVerification

Question

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?

Plummy

Have you seen that? msdn.microsoft.com/en-us/library/cc713694.aspx – Depressor

@SimonMourier - yes, from my understanding this disables the 'bypass' thereby causing all assemblies to be subject to strong name signature verification, kind of the opposite of what I'm after. – Plummy

Oh, sorry, you're right. What about this: ryangerard.net/post/8768827919/… – Depressor

That could be a very last resort as it would require disabling verification on every machine the code is deployed on. We're not actually getting any strong name errors and are unsure which (if any) DLLs the verification is spending all its time on so disabling verification is not straightforward. – Plummy

Would it be possible to get a more accurate stack frame to have more information on what's going on? For example if you debug the process with Visual Studio or Windbg, but with Microsoft symbols loaded configured properly? (support.microsoft.com/kb/311503) – Depressor

I also have this issue and I see the same kind of stack. I tried to put the sym server into process explorer directly but fat chance. – Imperforate

Answer 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.

Gantrisin

Thanks Hans - great spot! Can I assume that the assembly names are correct? – Plummy

Yes, they are correct. Only mscorlib is on the stack, the rest are CLR and operating system executables. – Gantrisin

For the record, after loading symbols correctly as described by Hans I could see that the problem was related to a bug in NLog's asynchronous logging code (github.com/NLog/NLog/issues/162). – Plummy

Answer 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

Albumenize