私はThreadWaitReason 1..31のドキュメントを検索しています。特に、私は私が発見したThreadWaitReasonのドキュメント
ThreadWaitReason = 27
ThreadWaitReason = 31
である[1]のために興味があります：https://msdn.microsoft.com/en-us/library/aa394494(v=vs.85).aspxそれが唯一1..20まで列挙されています。
KWAIT_REASON enumはwdm.hで宣言されています（27はWrResourceと31はWrDispatchIntです）。
スレッドオブジェクト（KTHREAD）自体がWaitReasonフィールドを持っています。スレッドが待機する（アクティブではない）前に、システムは何らかの理由で値をこのフィールドに書き込みます。私たちは、カーネルでKeWaitForSingleObjectまたはKeWaitForMultipleObjectsを直接呼び出して、をWaitReasonという値に設定します。私たちが別の関数を呼び出すときには、自分自身を設定するwait-systemを引き起こす可能性があります。WaitReason。たとえば、KeDelayExecutionThread（カーネルモードの実装がSleep[Ex]）システムセットがの場合、WaitReasonはからWrDelayExecutionに設定されます。リソース関数（たとえばExAcquireResourceExclusiveLite）を呼び出すとき - システムsetWaitReason〜WrResource（27）。システムスワップスレッド、期限切れのため、システムsetWaitReason〜WrDispatchInt（31）。等々。
我々はSystemProcessInformationでNtQuerySystemInformationを呼び出す - WaitReasonからシステムread値とSYSTEM_THREAD_INFORMATION構造でそれを返します。
は明らかにWaitReasonはスレッドが待っているセンスの主を持っている - ので状態はで待機（5）を。さもなければ私たちは古い価値を持っています - 前回のスレッド待ちの理由
ThreadWaitReasonフィールドの値27と31が実際に遭遇しましたか？ –
BTW：ThreadWaitReason _valueは、ThreadStateメンバーがTransition（6）_に設定されている場合にのみ有効です。おそらく、27と31に遭遇したときは、これは当てはまりませんでした。 –
はい、値31（時には27）が発生しました。 ThreadStateは2です。私はWorkerThreadからあまりにも多くのPostMessagesを送信するかもしれませんか？ –