バックグラウンドで検索操作を実行し、リストボックス内のフォアグラウンドで結果をユーザーに表示するのに問題があります。
プログラムはSendMessage、クエリ結果をGUIに送り返すために使用します。
プログラムを閉じると、GUIはグローバル（揮発性）変数を「完了」としてマークMsgWaitForMultipleObjectsし、スレッドハンドルを待機してスレッドに参加します。
プログラムを中断すると、デッドロックが発生します。GUIはバックグラウンドスレッドの終了を待機していますが、バックグラウンドスレッドはで待機していSendMessageます。
MsgWaitForMultipleObjectsこのデッドロックは、100ミリ秒のタイムアウトを使用してループ内で呼び出した場合でも発生しQS_ALLINPUTます。理由がわかりません。
このデザインは正しいですか？スレッドが終了するのを待つより良い方法はありますか？
そうでない場合、問題は何ですか？
メッセージキューのオーバーランを回避するには、ダブルバッファリングスキームが必要です。このようにレイアウトします。
スレッド1は検索を実行し、PostMessageを使用して結果を送信します。
スレッド2は、メッセージキューを読み取り、検索結果メッセージを選択的に削除して、任意の数のエントリを処理できる内部メモリベースのキューに格納します。
スレッド3は、内部キューから結果を読み取り、それらを表示します。
スレッド2とスレッド3が相互にステップするのを防ぐために、ミューテックス保護を備えたキューのget /putAPIが必要になることに注意してください。
それは古典的な消費者/生産者パターンです。スレッドメッセージキューを使用せず、独自の同期キュー、できれば固定サイズのキューを使用してください。コンシューマー（UIスレッド）は、オンデマンドで検索スレッドの速度を低下させます。または、同期キューが大きすぎることが検出された場合は、UIスレッド速度に合わせて検索結果をフィルタリングできます。
MsgWaitForMultipleObjects「メッセージがあります」と言った後、メッセージを処理する必要があります。チャンスは1回だけです。これを怠ると（ループバックしてMsgWaitForMultipleObjects再度呼び出すと）、メッセージは未処理になり、それ以上の通知は届きません。