1

そのため、アプリケーションプールがときどきクラッシュし続ける理由を突き止めようとしており、cauが問題の原因であると思われるページを特定しました。

ブラウザでサイトを開き、（カートに商品を追加した後）配送カートページにアクセスすると、ブラウザ全体が応答しなくなり、タスクマネージャを開くと、IE（ブラウザ）が99％のCPUを使用していることがわかります。右クリック>[DUMPの作成]>[DUMPを読み取ろうとしましたが、WinDBGはDMPファイルを好まないようです。それらを読みません。

だから私は先に進み、ダンプファイルなしでそれを理解しようとします。Visual Studioを起動し、問題のサイトを開いてから、同じプロセスに従います（カートにコンテンツを追加してから、カートページにアクセスします）。そして驚いたことに、すべてが大丈夫です。

今何をすべきかわからない。助言がありますか？すべてがローカルで完全に実行されている場合、およびすべてがオンラインで完全に実行されていたが、オンラインでは正常に実行されなくなった場合、ハングの原因をどのように特定しますか？

4

1 に答える 1

2

ブラウザが応答しなくなり、99% の CPU を消費する場合、それはクライアント側の問題です。ほとんどの場合、IIS やサーバー側のコードとは何の関係もありません。

ページにバグがあり、ビジー ループに陥っている JavaScript が含まれている可能性がありますか? これをテストする価値はあると思います (IE の開発者ツール (F12)、Visual Studio の JavaScript デバッグ機能、または FireBug と組み合わせて FireFox を使用します)。

編集 AppPool がクラッシュすると、Web ブラウザーが応答しなくなるのは奇妙に思えます。応答しないということは、ブラウザ自体が機能しなくなるということですか (つまり、ページに戻ったり、google.com などの別の URL に移動したりすることは不可能ですか?)

とにかく、サーバー側で問題が発生していると思われる場合は、次のことを試すことができます (労力がかかる順に):

  • AppPool がクラッシュした後、Windows イベント ログを確認し (コマンド プロンプトから「eventvwr」を実行)、どのような情報が得られるかを確認します。
  • IIS ログを表示します (最初に有効にする必要がある場合があります)。ページがハンマーで打たれるなど、奇妙な要求パターンが含まれているかどうかを確認します)
  • IIS から Web サイトを実行しますが、Visual Studio ([ツール]、[プロセスにアタッチ] - マネージ コードのみを含める) から IIS ワーカー プロセス (通常は w3wp.exe) にデバッガーをアタッチします。ページが例外をスローした場合、VS はそれをキャッチできるはずです。
  • ページにさらにトレースを追加します。Global.asaxの Application_Error は特に良い候補のようです。
于 2012-11-25T10:35:14.930 に答える