デッドロックのデバッグ

[アーティクル]
03/28/2024

スレッドがコードまたはその他のリソースへの排他アクセスを必要とする場合は、ロックを要求します。可能であれば、Windows はスレッドにこのロックを与えることによって応答します。この時点で、システム内の他の何もロックされたコードにアクセスできません。これは常に発生し、適切に記述されたマルチスレッドアプリケーションの通常の部分です。特定のコードセグメントは一度に 1 つのロックしか持つことができませんが、複数のコードセグメントがそれぞれ独自のロックを持つことができます。

2 つ以上のスレッドが、互換性のないシーケンスで 2 つ以上のリソースに対してロックを要求すると、デッドロック が発生します。たとえば、Thread One がリソース A のロックを取得し、リソース B へのアクセスを要求したとします。一方、スレッド 2 はリソース B のロックを取得し、リソース A へのアクセスを要求します。どちらのスレッドも、他のスレッドのロックが放棄されるまで続行できないため、どちらのスレッドも続行できません。

ユーザーモードのデッドロックは、通常は 1 つのアプリケーションの複数のスレッドが、同じリソースへの互いのアクセスをブロックした場合に発生します。ただし、複数のアプリケーションの複数のスレッドは、グローバルイベントやセマフォなどのグローバル/共有リソースへの相互のアクセスをブロックすることもできます。

カーネルモードのデッドロックは、(同じプロセスまたは異なるプロセスから) 複数のスレッドが互いの同じカーネルリソースへのアクセスをブロックした場合に発生します。

デッドロックのデバッグに使用されるプロシージャは、デッドロックがユーザーモードで発生するかカーネルモードで発生するかによって異なります。

ユーザーモードデッドロックのデバッグ

ユーザーモードでデッドロックが発生した場合は、次の手順を使用してデバッグします。

!ntsdexts.locks 拡張機能を発行します。ユーザーモードでは、デバッガープロンプト で「!locks 」と入力するだけで済みます。ntsdexts プレフィックスが想定されます。
この拡張機能には、現在のプロセスに関連付けられているすべての重要なセクションと、所有しているスレッドの ID と各クリティカルセクションのロック数が表示されます。クリティカルセクションのロックカウントが 0 の場合、ロックされません。 ~(スレッドステータス)コマンドを使用して、他の重要なセクションを所有するスレッドに関する情報を表示します。
これらの各スレッドの kb (Display Stack Backtrace) コマンドを使用して、他の重要なセクションで待機しているかどうかを判断します。
これらの kb コマンドの出力を使用すると、デッドロックを見つけることができます。2 つのスレッドはそれぞれ、もう一方のスレッドによって保持されているロックを待機しています。まれに、循環パターンで 2 つ以上のスレッドがロックを保持することによってデッドロックが発生する可能性がありますが、ほとんどのデッドロックには 2 つのスレッドのみが含まれます。

この手順の図を次に示します。まず、 !ntdexts.locks 拡張機能を使用します。

0:006>  !locks 
CritSec ftpsvc2!g_csServiceEntryLock+0 at 6833dd68
LockCount          0
RecursionCount     1
OwningThread       a7
EntryCount         0
ContentionCount    0
*** Locked

CritSec isatq!AtqActiveContextList+a8 at 68629100
LockCount          2
RecursionCount     1
OwningThread       a3
EntryCount         2
ContentionCount    2
*** Locked

CritSec +24e750 at 24e750
LockCount          6
RecursionCount     1
OwningThread       a9
EntryCount         6
ContentionCount    6
*** Locked

表示される最初のクリティカルセクションにはロックがないため、無視できます。

表示される 2 番目のクリティカルセクションのロックカウントは 2 であるため、デッドロックの原因として考えられます。所有スレッドには、0xA3のスレッド ID があります。

このスレッドを見つけるには、~ (スレッドの状態) コマンドを使用してすべてのスレッドを 一覧表示し、この ID を持つスレッドを探します。

0:006>  ~
   0  Id: 1364.1330 Suspend: 1 Teb: 7ffdf000 Unfrozen
   1  Id: 1364.17e0 Suspend: 1 Teb: 7ffde000 Unfrozen
   2  Id: 1364.135c Suspend: 1 Teb: 7ffdd000 Unfrozen
   3  Id: 1364.1790 Suspend: 1 Teb: 7ffdc000 Unfrozen
   4  Id: 1364.a3 Suspend: 1 Teb: 7ffdb000 Unfrozen
   5  Id: 1364.1278 Suspend: 1 Teb: 7ffda000 Unfrozen
.  6  Id: 1364.a9 Suspend: 1 Teb: 7ffd9000 Unfrozen
   7  Id: 1364.111c Suspend: 1 Teb: 7ffd8000 Unfrozen
   8  Id: 1364.1588 Suspend: 1 Teb: 7ffd7000 Unfrozen

この表示では、最初の項目はデバッガーの内部スレッド番号です。 2 番目の Id 項目 (フィールド) には、小数点で区切られた 2 つの 16 進数が含まれています。小数点の前の数値はプロセス ID です。小数点の後の数値はスレッド ID です。この例では、スレッド ID 0xA3がスレッド番号 4 に対応していることがわかります。

次に、 kb (Display Stack Backtrace) コマンドを使用して、スレッド番号 4 に対応するスタックを表示します。

0:006>  ~4 kb
  4  id: 97.a3   Suspend: 0 Teb 7ffd9000 Unfrozen
ChildEBP RetAddr  Args to Child
014cfe64 77f6cc7b 00000460 00000000 00000000 ntdll!NtWaitForSingleObject+0xb
014cfed8 77f67456 0024e750 6833adb8 0024e750 ntdll!RtlpWaitForCriticalSection+0xaa 
014cfee0 6833adb8 0024e750 80000000 01f21cb8 ntdll!RtlEnterCriticalSection+0x46
014cfef4 6833ad8f 01f21cb8 000a41f0 014cff20 ftpsvc2!DereferenceUserDataAndKill+0x24
014cff04 6833324a 01f21cb8 00000000 00000079 ftpsvc2!ProcessUserAsyncIoCompletion+0x2a
014cff20 68627260 01f21e0c 00000000 00000079 ftpsvc2!ProcessAtqCompletion+0x32
014cff40 686249a5 000a41f0 00000001 686290e8 isatq!I_TimeOutContext+0x87
014cff5c 68621ea7 00000000 00000001 0000001e isatq!AtqProcessTimeoutOfRequests_33+0x4f
014cff70 68621e66 68629148 000ad1b8 686230c0 isatq!I_AtqTimeOutWorker+0x30
014cff7c 686230c0 00000000 00000001 000c000a isatq!I_AtqTimeoutCompletion+0x38
014cffb8 77f04f2c 00000000 00000001 000c000a isatq!SchedulerThread_297+0x2f
00000001 000003e6 00000000 00000001 000c000a kernel32!BaseThreadStart+0x51

このスレッドには WaitForCriticalSection 関数の呼び出しがあることに注意してください。これは、ロックを持っているだけでなく、他の何かによってロックされているコードを待機していることを意味します。 WaitForCriticalSection の呼び出しの最初のパラメーターを調べることで、待機している重要なセクションを確認できます。これは、Args to Child の最初のアドレスである "24e750" です。そのため、このスレッドはアドレス 0x24E750のクリティカルセクションを待機しています。これは、前に使用した !locks 拡張機能によって一覧表示された 3 番目の重要なセクションでした。

つまり、2 番目のクリティカルセクションを所有するスレッド 4 は、3 番目のクリティカルセクションを待機しています。次に、3 番目のクリティカルセクションにも注意を向けます。このセクションもロックされています。所有スレッドには、スレッド ID 0xA9があります。前に確認した ~ コマンドの出力に戻ると、この ID を持つスレッドはスレッド番号 6 であることに注意してください。このスレッドのスタックバックトレースを表示します。

0:006>  ~6 kb 
ChildEBP RetAddr  Args to Child
0155fe38 77f6cc7b 00000414 00000000 00000000 ntdll!NtWaitForSingleObject+0xb
0155feac 77f67456 68629100 6862142e 68629100 ntdll!RtlpWaitForCriticalSection+0xaa 
0155feb4 6862142e 68629100 0009f238 686222e1 ntdll!RtlEnterCriticalSection+0x46
0155fec0 686222e1 0009f25c 00000001 0009f238 isatq!ATQ_CONTEXT_LISTHEAD__RemoveFromList
0155fed0 68621412 0009f238 686213d1 0009f238 isatq!ATQ_CONTEXT__CleanupAndRelease+0x30
0155fed8 686213d1 0009f238 00000001 01f26bcc isatq!AtqpReuseOrFreeContext+0x3f
0155fee8 683331f7 0009f238 00000001 01f26bf0 isatq!AtqFreeContext+0x36
0155fefc 6833984b ffffffff 00000000 00000000 ftpsvc2!ASYNC_IO_CONNECTION__SetNewSocket
0155ff18 6833adcd 77f05154 01f26a58 00000000 ftpsvc2!USER_DATA__Cleanup+0x47
0155ff28 6833ad8f 01f26a58 000a3410 0155ff54 ftpsvc2!DereferenceUserDataAndKill+0x39
0155ff38 6833324a 01f26a58 00000000 00000040 ftpsvc2!ProcessUserAsyncIoCompletion+0x2a
0155ff54 686211eb 01f26bac 00000000 00000040 ftpsvc2!ProcessAtqCompletion+0x32
0155ff88 68622676 000a3464 00000000 000a3414 isatq!AtqpProcessContext+0xa7
0155ffb8 77f04f2c abcdef01 ffffffff 000ad1b0 isatq!AtqPoolThread+0x32
0155ffec 00000000 68622644 abcdef01 00000000 kernel32!BaseThreadStart+0x51

このスレッドも、重要なセクションが解放されるのを待っています。この場合、0x68629100のクリティカルセクションを待機しています。これは、前に !locks 拡張機能によって生成された一覧の 2 番目の重要なセクションでした。

これがデッドロックです。 2 番目のクリティカルセクションを所有するスレッド 4 は、3 番目のクリティカルセクションを待機しています。 2 番目のクリティカルセクションを所有するスレッド 4 は、3 番目のクリティカルセクションを待機しています。

このデッドロックの性質を確認したら、通常のデバッグ手法を使用してスレッド 4 と 6 を分析できます。

カーネルモードデッドロックのデバッグ

カーネルモードでのデッドロックのデバッグに役立つデバッガー拡張機能がいくつかあります。

!kdexts.locks 拡張機能は、カーネルリソースに保持されているすべてのロックと、これらのロックを保持しているスレッドに関する情報を表示します。ユーザーモードでは、デバッガープロンプト で「!locks 」と入力するだけで済みます。dexts プレフィックスが想定されます。
!qlocks エクステンションは、キューに入っているすべてのスピンロックの状態を表示します。
!wdfkd.wdfspinlock 拡張機能は、カーネルモードドライバーフレームワーク (KMDF) スピンロックオブジェクトに関する情報を表示します。
!deadlock 拡張機能は、ドライバー検証ツールと組み合わせて使用され、デッドロックの原因となる可能性のあるコード内のロックの一貫性のない使用を検出します。

カーネルモードでデッドロックが発生した場合は、!kdexts.locks 拡張機能を使用して、スレッドによって現在取得されているすべてのロックを一覧表示します。

通常は、実行中のスレッドが必要とするリソースの排他ロックを保持している非実行スレッドを見つけることで、Microsoft Windows 2000 のデッドロックを特定できます。ほとんどのロックは共有されます。

デッドロックのデバッグ

ユーザーモードデッドロックのデバッグ

カーネルモードデッドロックのデバッグ

フィードバック

フィードバック

その他のリソース

デッドロックのデバッグ

ユーザー モードデッドロックのデバッグ

カーネル モードデッドロックのデバッグ

フィードバック

フィードバック

その他のリソース

ユーザーモードデッドロックのデバッグ

カーネルモードデッドロックのデバッグ