IIS 7.5のアプリケーションプールのCPU制限
これは、シミュレーション（またはソースコードへのアクセス...>ため息<）が、ある程度の自信を持って動作を確認する唯一の方法になる可能性があるケースの1つに見えます。
CPUクォータリサイクルのイベントログエントリ のドキュメントでは、リサイクルについて次のように説明しています。
デフォルトでは、アプリケーションプールのリサイクルは重複しています。つまり、シャットダウンされるワーカープロセスは、新しいワーカープロセスが開始されるまで実行され続けます。新しいワーカープロセスが開始すると、新しいリクエストがそれに渡されます。古いワーカープロセスは、既存の要求の処理が終了した後、または構成されたタイムアウトの後のいずれか早い方でシャットダウンします。このリサイクル方法により、クライアントへのサービスが中断されることはありません。ただし、アプリケーションプール内のアプリケーションが一度に複数のインスタンスを実行できない場合は、オーバーラップローテーションを無効にすることができます。
定義上、過剰なCPU消費のためにワーカープロセスを終了することは、保留中の要求を完了できないことを意味するように思われます（CPUクォータを使い果たしているため）。
あなたの主な懸念事項について話すと、新しいワーカープロセスが自動的にスピンアップされないと私が信じるようなことは何も見られません。スタックオーバーフローリンクのステートメントでは、IISによって使用されるアルゴリズムが、実際に、CPUクォータの枯渇を測定するために使用されるタイマーの解決にリサイクルを結び付ける可能性があるかどうかを疑問視しています。最良の方法CPUを浪費するサーバー側コンポーネントを作成し、それをテスト環境にデプロイして、そのリサイクル動作がどのように機能するかを確認することを決定することを知っています。数秒間タイトなループにとどまり、既知のコンポーネントを返す単純なコンポーネント文字列は、並列の「wget」プロセスのプールのようなものでテストハーネスを実行しているクライアントと組み合わせると十分な場合があります。クライアントからの一連の並列要求でそれをハンマーし、要求が適切な応答とエラーメッセージをどのように受信するかについてレポートします、など（ソースコードを見るだけでなく、このようなものに頼らなければならないのはとてもばかげています...）
他の応答のコメントを考慮して、私は独自のテストを行いました。これをここで複製します。
私のテストでは、アプリケーションプール（v4.0統合）を小さなCPU制限（0.01％）と小さな間隔（1分）に制限し、KillW3WPアクションを有効にすると、この制限を超えると、 w3wp by アプリケーションプールの停止。
間隔の制限に達すると、アプリケーションプールは自動的に再起動されますになります。
アクションをアクションなしに変更しても、w3wpプロセスは変更されません。
どちらの場合も、システムイベント5025が記録されます。