.Net 4 verschwenden ständig einen CPU-Kern auf StrongNameSignatureVerification

Question

Wir haben eine Assembly-Anwendung (MFC + WinForms) im gemischten Modus auf .Net 4, Windows 2008 R2, die ständig 100% CPU in einem Thread verwendet.

Mit ProcessExplorer sehen wir den folgenden Stapel auf dem beschäftigten Thread. Wir können auch weitere 10 Threads mit nur 0,01% CPU sehen, auf denen clr.dll! StrongNameSignatureVerification läuft.

Der sich drehende Thread verhindert nicht, dass der Rest der Anwendung ausgeführt wird, verschwendet jedoch CPU-Zeit.

Der Stack-Trace des Besetzt Thread ist wie folgt:

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 

Das einzige ähnliches Konto finde ich in der Lage bin in dieser Frage ist: clr.sll!StrongNameSignatureVerification CPU consumption obwohl der Faden kalt zu haben scheint verschwunden.

Wir signieren unsere Assemblys nicht und sind bereit, ihnen zu vertrauen. Gibt es eine Möglichkeit, die starke Namensverifizierung vollständig zu deaktivieren?

Answer 1

clr.dll! StrongNameSignatureVerification + 0x164d9

Dies nicht tun, was Sie denken, es tut. Die Nummer auf der rechten Seite des Bezeichners ist wichtig und gibt die Anzahl der Bytes nach der bekannten Position der StrongNameSignatureVerification-Funktionsadresse an. Das sind 91353 Bytes, das ist viel. Das einzige, was Sie daran erkennen können, ist, dass es nicht StrongNameSignatureVerification ausführen, die Funktion ist nicht annähernd so lang. Der Rest der Identifikatoren in der Stapelüberwachung ist gleichermaßen unzuverlässig.

Das Problem besteht darin, dass der Debugger keine PDB-Datei für diese DLLs hat. Es kann nur die Adresse der exportierten Funktionen ermitteln, es weiß nicht genug über alle Funktionen dazwischen. Sie können dem angezeigten Namen nur dann vertrauen, wenn der Offset weniger als ca. 0x100 Byte beträgt. Geben oder nehmen.

Sie müssen diese PDB-Dateien erhalten, um zu wissen, was wirklich vor sich geht. Dazu muss der Microsoft Symbol Server aktiviert werden. Der Debugger lädt die erforderlichen PDB-Dateien von diesem Server herunter, wenn Sie mit dem Debuggen beginnen. Sie erhalten jetzt viel zuverlässigere Symbole, die Ihnen viel besseren Einblick in den tatsächlich ausgeführten Code geben.

Die Aktivierung des Symbolservers ist einfach, die MSDN-Seite is here.

Answer 2

Sie könnten die Profilierungswerkzeuge in Visual Studio verwenden, um Hotspots in Ihrem Code zu identifizieren, die zu diesem Problem beitragen könnten. Informationen zur Symbolunterstützung für die .net CLR finden Sie unter diesem Link.

http://blogs.msdn.com/b/sburke/archive/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code.aspx