ボタンをクリックすると複数のスレッドを実行するWebアプリケーションがあり、各スレッドは異なるipAddressesでIO呼び出しを行います（Windowsアカウントにログインしてからファイル操作を行います）。30 秒のしきい値があります。しきい値を超えた場合のログイン試行中に、ipAddress のデバイスが私の条件と一致しないため、気にしないと思います。Thread.Abort() は、時間がかかる可能性がある IO 呼び出しが完了するのを待つという私の状況には合いません。
しきい値タイムアウトの直後に、スレッドの状態に従って db 操作を実行してみました。問題なく動作しましたが、ログ ファイルを確認したところ、応答していないスレッドの thread.IsAlive プロパティがまだ true であることに気付きました。ローカル pc でいくつかのデバッグを行った後、pc がひどくクラッシュした可能性があるデッドロック状態 (と思われます) に遭遇しました。
つまり、button_click の実行直後に (IO 操作を待機している) 応答しないスレッドを (強制的に) 強制終了することについて何か考えはありますか?
（PS：スレッドプールは使用していません）
オグザン
編集
さらに明確にするために、
各 ipAddress で指定されたローカル管理者の資格情報を検証し、連続するものに DB レコードを挿入する必要があります。残りは、気にしません。
私の検証方法では、最初に管理者ユーザーになりすますために advapi32.dll をインポートして、win32 の logonuser メソッドを呼び出しました。その後、認証を確認するためだけに、Directory.CreateDirectory メソッドを使用してリモート sys ドライブに一時ディレクトリを作成しようとしました。例外がスローされた場合 (UnauthorizedAccessException または IOException)、リモート マシンは対象外です。それ以外の場合は、取得したので DB に挿入します。
特定の IP 範囲に対して同期的な方法で検証メソッドを呼び出したところ、一連の一連のエンドポイントに対して正常に機能しました。しかし、関係のない ipAddress 範囲に対してメソッドをテストしたところ、各検証の試行が完了するまでに 20 秒から 5 分かかりました。
次に、設計をマルチスレッド方式に変更し、各検証を個別のスレッドで実行し、しきい値の最後で応答しないスレッドを中止することにしました。問題は、thread.abort が状況にうまく適合しなかったことです。これは、実際には IO 命令の戻りを待機し (これは望ましくありません)、その後 ThreadAbortException を発生させます。
連続するスレッドの実行を完了するために、応答しないスレッドを無視して DB 操作を続行し、ボタン クリック メソッドから戻ります (応答しないスレッドはその時点でまだ生きていました)。ボタンクリックを（デバッグモードで）数回実行した後、悪いシステムクラッシュが発生するまで、すべてが問題ないように見えました。問題はおそらく、IIS サービスの下で生きているスレッドの数が増えたことです。
解決
スレッドがタイムリーに応答しない原因は、ネットワーク パスが見つからない状況です。私の解決策は、IO 呼び出しを行う前に、ポート 135 で TCP 経由の接続を確認することです (ポート 135 は、Windows の RPC には必須です)。デフォルトのタイムアウト期間は 20 秒です。タイムアウトを設定する必要がある場合は、BeginConenct を使用します。他のオプションはPingingです（ICMPがネットワークで有効になっている場合）