アップデート

アップデート

プログラムが終了しようとすると、PuTTY がクラッシュします。クラッシュすると、ウィンドウがフリーズし、何をしても閉じなくなります。強制終了は機能せず、タスク マネージャーも機能しません。pstools pskill(管理者コマンド プロンプトを使用) から実行しても効果はありません。プロセスが強制終了されたと表示されますが、プロセスはそのまま残ります。コンピューターを再起動する以外に、ウィンドウを消す方法はありません。

これは数週間前から発生しており、最近の Windows アップデートが原因と考えられますが、これは推測にすぎません。毎回発生するわけではありませんが、おそらく 50% の確率で発生します。「exit」または「logout」と入力して手動で終了する場合も、コンピューターがスリープ状態になったために自動的に終了する場合も、クラッシュします。

ポート トンネリングを使用する場合にのみ発生します。常に複数の PuTTY ウィンドウを開いているのですが、クラッシュするのはポート トンネルが開いているウィンドウだけです。

最近のクラッシュの前に、PuTTY ログを開いて内容を確認しました。最後の行は「Server sent command exit status 0」で、これは正常なようです。

サーバー終了ステータス 0

関係がある場合に備えて、ポート トンネリング設定のスクリーンショットを以下に示します。

港湾トンネルD9090

以下は、エラーの種類を「AppHangB1」として識別する Windows エラー ボックスです。

ここに画像の説明を入力してください

Google では結果がまったく表示されませんでした。このタイプのクラッシュを検索すると、バグのあるドライバーが原因であることがよくあるとわかりました。そのため、更新/ロールバックを試みる必要があるものをご存知の方がいらっしゃれば、それが 1 つの可能性として考えられます。

PuTTY を最新バージョンに更新しましたが、効果はありませんでした。リモート コンピューター (私が制御) やルーターの更新は試していませんが、Windows 自体に関連していると思われるこの種のクラッシュには、どちらも関係がないことを願っています。

ウィンドウズ7


アップデート

提案されたデバッグツールを実行すると、メモリダンプが生成され、その分析が行われました。かなり大量の情報なので、jsfiddleはここで見ることができます以下に概要を引用しましたが、かなり情報量が多いので全文はそちらのページをご覧ください。

説明:putty.exe__PID__7768__Date__08_14_2018__Time_02_26_52PM__311__Manual Dump.dmp のスレッド 0 が所有する 0x041916d8 で、ブロックまたはリークの可能性のあるクリティカル セクションが検出されました

このロックの影響: スレッドの 25.00% がブロックされました (スレッド 2)

次の関数がこのクリティカルセクションに入ろうとしています

mswsock!SockAsyncSelectCompletion+2a

このクリティカル セクションには次のモジュールが関係しています。

C:\WINDOWS\System32\mswsock.dllマイクロソフト株式会社


3週間後の更新

クラッシュが発生しなくなってからほぼ 1 か月が経ち、その間に別の Windows アップデートが行われました。タイミングがあまりにも偶然すぎるため、これは夏、おそらく 7 月の Windows アップデートが原因で、8 月のアップデートで修正されたのではないかと思います。

答え1

PuTTY の構成設定では、「終了時にウィンドウを閉じる」設定が問題の原因になっている可能性があるので、その他の利用可能な設定をテストしてみてください。

次のいずれかの無料代替製品を試すこともできます: キティモバエクスターム、 または ビットバイス

いずれかの代替案が機能する場合は、まず問題の回避策があります。次に、問題自体はおそらく PuTTY とリモート コンピューターの通信プロトコルに何らかの問題があるため、開発者に問題を報告する必要があります。

ただし、どの代替案も機能しない場合は、問題はおそらくユーザー側ではありません。リモート コンピューターの SSH サーバーの設定を調べ、デバッグを試し、トレース ログをここに投稿して、私たちに確認してもらいましょう。リモート コンピューターを制御できない場合は、管理者に問題を報告してください。

答え2

PuTTY が終了時にクラッシュし、コンピュータの再起動が必要になる

プログラムが終了しようとすると、PuTTY がクラッシュします。クラッシュすると、ウィンドウがフリーズし、何をしても閉じません。強制終了は機能せず、タスク マネージャーも機能しません。pstools の pskill (管理者コマンド プロンプトを使用) は効果がありません。プロセスが強制終了されたと表示されますが、そのまま残ります。コンピューターを再起動する以外に、ウィンドウを消す方法はありません。

私はそれを「クラッシュ」ではなく「ハング」と呼んでいます。クラッシュとは処刑は続くエラー メッセージを返す (良い) か、重大なメモリ破損の場合は一時停止 (通常は短いが、場合によってはやや長く、まれにウォッチドッグ) し、BSOD または再起動で実行を続行します (良くない)。

「ハング」でどれだけ待っても進歩は見込めないただし、タスク スイッチャーが影響を受けず、他のスレッドに切り替えることができる場合は、他のスレッドは引き続き正常に実行される可能性があります。

おそらく、PuTTYがトンネルを作るためにVPNサブルーチンを生成し、それプロセスに問題があり、PuTTY に戻っていないため、PuTTY がハングしています。

他のプロセスで一時ファイルが開かれているか、ポートが開いている可能性があります。PuTTYの終了かもしれないサブルーチンは閉じますが、サブプログラムからファイルやポートのロックは削除されない可能性があります。

確実に知る方法- 何が起こっているのか?

このエラーに関する Microsoft コミュニティの Web ページを読んでみると、次のタイトルが付けられています: "Windows Explorer 7 が応答しません - 'apphangb1 explorer.exe' エラー「それは言う:

アンドレ・ツィーグラー

Windows エクスプローラーのハング ダンプを作成します。

http://www.msfn.org/board/topic/130005-creating-memory-dumps/

クラッシュ ダンプを 7z または RAR として圧縮し、SkyDrive にアップロードして、リンクをここに投稿します。

ダンプを作成し、それを自分で分析することもできますし、すべての SE サイトを検索して重複した質問を探した後、「.DMP ファイルで作業するにはどうすればよいですか?」と質問することもできます。

そのリンクをたどってウェブページに進みます: "メモリダンプの作成「それは言う:

ハングしている(クラッシュしていない)アプリケーション/プロセスからのメモリ ダンプ:

  1. c:\adplusというディレクトリを作成します

  2. コマンドプロンプトを開き、デバッグツールをインストールしたディレクトリに移動します。デフォルトでは、「C:\Program Files\Debugging Tools for Windows」です。

  3. コマンドプロンプトに次のコマンドを入力します。

cscript adplus.vbs -hang -pn appname -quiet -o c:\adplus

(「appname」はハングしているアプリケーションの .exe 名です)

  1. デバッガーが終了すると (これには時間がかかる場合があります)、コマンド プロンプト ウィンドウが閉じ、C:\adplus フォルダーに分析可能なデータが格納されます。

クラッシュしている(ハングしていない)アプリケーション/プロセスからのメモリ ダンプ:

  1. c:\adplusというディレクトリを作成します

  2. コマンドプロンプトを開き、デバッグツールをインストールしたディレクトリに移動します。デフォルトでは、「C:\Program Files\Debugging Tools for Windows」です。

  3. コマンドプロンプトに次のコマンドを入力します。

cscript adplus.vbs -crash -pn appname -quiet -o c:\adplus

(「appname」はクラッシュしているアプリケーションの .exe 名です)

  1. 手順 3 で接続したアプリケーションが最終的にクラッシュすると、デバッガーはプロセスの .dmp ファイル (またはファイル) を作成します。デバッガーが終了すると (これには時間がかかる場合があります)、コマンド プロンプト ウィンドウが閉じ、C:\adplus フォルダーに分析可能なデータが作成されます。

この Microsoft サポート Web ページを参照してください: "デバッグ診断ツールv1.2が利用可能になりました「DebugDiag ツールの使用方法について説明しています。」

以下について説明します。

  • メモリダンプの生成:

    • プロセスクラッシュ

    • プロセスがハングしたりパフォーマンスが低下したりする

プロセスのハングやパフォーマンスの低下をデバッグするには、次のいずれかを使用します。

  1. パフォーマンス ルールを作成します。パフォーマンス ルールは、パフォーマンス カウンターまたは HTTP 応答時間に基づくことができます。後者は、Web サーバーまたは HTTP ベースの Web サービスに固有のものです。パフォーマンス カウンター ルールを使用すると、1 つ以上のパフォーマンス カウンターが指定されたしきい値を超えたときに、一連の連続したユーザー ダンプをキャプチャできます。HTTP 応答時間ルールを使用すると、構成されたタイムアウトに達したときに、ETW (IIS Web サーバーに固有) または WinHTTP (任意のタイプの Web サーバーまたは HTTP ベースの Web サービスを 'ping' する) を使用してユーザー ダンプをキャプチャできます。

  2. プロセス ビューでプロセス名を右クリックし、「ダンプ シリーズの作成」オプションを選択して、低速状態またはハング状態の間に手動のメモリ ダンプ シリーズを作成します。

    次に、結果の .dmp ファイルを CrashHangAnalysis.asp および/または PerfAnalysis.asp (以下を参照) を使用して分析します。

    • メモリまたはハンドルの使用
  • メモリダンプの分析:

    DebugDiag の最も強力な機能の 1 つは、メモリ ダンプを分析し、分析結果と特定された問題を解決するための推奨事項を示すレポート ファイルを生成する機能です。

    DebugDiag は「分析スクリプト」を使用してメモリ ダンプを分析します。DebugDiag 1.2 には、次の 5 つの分析スクリプトが付属しています。

    • クラッシュ/ハング アナライザー - CrashHangAnalysis.asp

    • メモリ プレッシャー アナライザー - DotNetMemoryAnalysis-BETA.asp

    • メモリ プレッシャー アナライザー - MemoryAnalysis.asp

    • パフォーマンス アナライザー - PerfAnalysis.asp

    • SharePoint アナライザー - SharePointAnalysis.asp"。

問題が何であれ、正確なポイントを特定し、どのプロセスに問題があるかを調べてデバッグすることができます。これらのツールの使用について質問がある場合は、遠慮なく新しい質問を検索して投稿してください。

答え3

Winsock フィルターに問題がある可能性があり、アプリケーションが何らかのドライバー/IO の問題でロックされているようです。

管理コマンド プロンプトで、次を試してnetsh winsock reset再起動し、違いがあるかどうかを確認します。

思いつく限りでは、他に試してみるとよいことがいくつかあります。

  • 使用していない VPN ソフトウェアを削除します。

  • ネットワーク カードのドライバーをアンインストール (および再インストール) します。

  • ネットワーク カードのドライバーを更新します。

  • 最近ウイルス対策製品をアンインストールした場合、ネットワーク フィルタ ドライバが残っている可能性があります。その場合は、適切なセキュリティ製品の削除ツールを見つけて実行してください。

答え4

2 つのスキャンを実行してみてください:

スキャン1

  1. 管理者としてCMDを実行する
  2. 入力しSFC /scannowてEnterキーを押します
  3. スキャンが終了したらcbs.log%windir%\logs\cbs\cbs.log
  4. cannot repair修復されなかったファイルを探してコピーします。
  5. 修復されていないファイル(ある場合)を見つけたら、インストールディスクを使用して置換ファイルにアクセスします。これらの方向置換ファイルを取得します。

スキャン2(最後の手段)

  1. 管理者としてCMDを実行する
  2. 入力しChkdsk /f /rてEnterキーを押します
  3. ロックするボリュームに関するメッセージが表示されます。 を押してyEnter キーを押します。
  4. コンピュータを再起動してください
  5. スキャンにはしばらく時間がかかります。スキャンが完了するまでお待ちください。
  6. 再起動したら、 に移動してEvent Viewer > Windows > Application Logを探しますWinninet
  7. スキャンの結果を確認してください。

私は答えを見つけましたマイクロソフトコミュニティ

関連情報