2013-02-19 9 views
15

.Net 4、Windows 2008 R2で実行される混合モードアセンブリアプリケーション(MFC + WinForms)は、常に1つのスレッドで100%CPUを使用します。.Net 4常にStrongNameSignatureVerificationで1つのCPUコアを無駄にする

ProcessExplorerを使用すると、ビジー状態のスレッドで次のスタックが表示されます。 clr.dllを実行している0.01%のCPUを使用している別の10個のスレッドも見ることができます!StrongNameSignatureVerification。

スピンスレッドは、アプリケーションの残りの部分が実行されることを防ぎませんが、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 

私は見つけることができました唯一の同様のアカウントは、この質問である:clr.sll!StrongNameSignatureVerification CPU consumptionスレッドは冷たい行っているようだけれども。

私たちはアセンブリに署名しておらず、信頼する意思がありますが、厳密な名前検証を完全に無効にする方法はありますか?

+0

これをご覧ください。 http://msdn.microsoft.com/en-us/library/cc713694.aspx –

+0

@SimonMourier - はい、私の理解から、これにより、バイパスが無効になり、すべてのアセンブリが厳密な名前の署名検証の対象になる私が後にしているものとは反対のものです。 – chillitom

+0

ああ、申し訳ありませんが、あなたは正しいです。これについてはどうすればよいですか:http://www.ryangerard.net/post/8768827919/assembly-verification-skipping-on-win7-64bitおよび –

答えて

14

clr.dll!StrongNameSignatureVerification + 0x164d9

これは、あなたがそれがないと思う何をしません。識別子の右側の数字は重要であり、StrongNameSignatureVerification関数アドレスの既知の場所を超えたバイト数を示します。これは91353バイトです。これは大変です。あなたがそれから知ることができるのは、ではなく、でStrongNameSignatureVerificationを実行していることです。機能はそれほど長くはありません。スタックトレース内の残りの識別子も同様に信頼性がありません。

問題は、デバッガにこれらのDLL用のPDBファイルがないことです。エクスポートされた関数のアドレスだけを発見することはできますが、間にあるすべての関数について十分な知識はありません。オフセットが約0x100バイト未満の場合、表示された名前のみを信頼できます。ギブオアテイク。

実際に何が起こっているのかを知るには、これらのPDBファイルを入手する必要があります。そのためには、Microsoft Symbol Serverを有効にする必要があります。デバッガは、デバッグを開始するときに、そのサーバから必要なPDBファイルをダウンロードします。はるかに信頼性の高いシンボルが表示され、実際に実行されているコードをよりよく理解できます。

シンボルサーバーを有効にするには、MSDNページis hereが簡単です。

+0

ありがとうハンス - 素晴らしいスポット!アセンブリ名が正しいと思いますか? – chillitom

+0

はい、正しいです。 mscorlibだけがスタックにあり、残りはCLRとオペレーティングシステムの実行可能ファイルです。 –

+0

レコードについては、Hansの説明どおりにシンボルを正しく読み込んだ後、NLogの非同期ログコード(https://github.com/NLog/NLog/issues/162)のバグに関連していることがわかりました。 – chillitom

関連する問題