Windows Server 2008のクラッシュの原因を追跡する方法は？
VMwareでWindows Server 2008を実行しています。
最近、CPU使用率が100％であり、GUIで応答がないため、ほぼ毎日クラッシュし始めました。
この問題の原因を突き止めるための段階的なテクニックはありますか？
どのログを見ればいいですか？
pS Acronisをアンインストールしようとしたときに問題が発生し、ブルースクリーンになりました。ただし、現在の障害がAcronisに関連しているかどうかはわかりません。
2009-07-06-私はそのハードドライブを考えています。
私はchkdskを実行しましたが、chkdskの途中で以前と同じ症状でクラッシュしました。ソリッドステートドライブ（SSD）の「PQI DK9128Gd6R000A03 128GB SATA 2.5」SSDを使用しており、MTBFは1,500,000時間です。MTBFは133年ですが、 2週間または通常の使用後に死んだようです！私の理論を確認するために、VMwareファイルを標準のハードドライブにコピーしました。chkdskを実行し、それは魅力のように機能しました。システムが1週間の稼働時間を生き残るかどうかを確認します、そしてそれが可能であれば、PQI SSDを正式に無視できます。
2009-07-07-システムが再びクラッシュしました。ふりだしに戻る。
2009-07-08-SSDをインストールする前に、さらに20日間ロールバックしました。再度クラッシュするかどうかを確認します（クラッシュしました）。
2009-07-09-OpenVPNのアンインストール、Skypeの最新バージョンへのアップグレード、SQL 2008からSP1へのアップグレード、TeamViewerの削除。再びクラッシュするかどうかを確認します（Acronisバックアップの途中でクラッシュしました）。
2009-07-09-サーバーを実行するVMwareマシンで利用可能な仮想メモリの量が小さすぎると思われますが、現時点では4GBです。それを増やす（これは効果がなかった）。
2009-07-09-Windows Server 2008を実行しているVMwareコンテナが100％のCPU使用率でクラッシュし、一時停止/再起動すると、クラッシュせずに動作を再開することが発見されました。これは、Windows Server 2008自体の問題ではなく、VMwareまたはそのホストOS（XP）の問題を指摘する傾向があります。今、問題の核心に非常に近づいています。
2009-07-09-Windows Server 2008は、ホストOSの負荷が非常に高い場合にのみクラッシュします。使用できるCPUの数を2 CPUに増やしました。これにより問題が修正されたようです。
結論として：
- 元の問題は、不良セクターのある不良ハードドライブが原因でした（実際にはPQIの128 GB SSDでした-購入後2週間でソリッドステートドライブ（SSD）が故障するとは予想していませんでしたが、これは故障しました）。
- 次の問題は、VMwareを実行しているホストOSが高負荷になったことが原因でした。より多くのRAMを割り当て、ページファイルのサイズを増やすことで、これを修正しました。
- 再度発生する場合は、回避策があります（VMware v6.5を一時停止/再起動して、その内部で実行されているWindows Server 2008を「フリーズ解除」します）。
問題は解決しました。ありがとうございます。
Windows Server 2008で使用できる「信頼性とパフォーマンスモニター」を使用することもできます。
以下に示すように、サーバーの信頼性の記録を自動的に保持し、10から「信頼性スコア」を割り当てます。このスコアは10から始まり、サーバーがクラッシュまたは予期しないシャットダウンを経験すると低下します。
どのプログラムがいつインストールされたかの記録も保持されるため、インストールされたプログラムがさらに障害を引き起こしたと思われるかどうかを診断できます。
プログラムのCPU使用率を継続的に記録するように設定して、どのプログラムが100％のCPU使用率を引き起こしているかを確認することもできます。
システムイベントログ。アプリケーションイベントログ。グーグルBSODのメッセージ。 chkdskを使用してディスクの整合性を確認します。
次の2つのオプションがあります。
- レコードを見て、過去の問題の原因を突き止め、理解してください
- 問題を再現するために、CPUスパイクにつながる可能性のある兆候を探します
ログは、問題の発生時刻がわかっている場合、またはログが静かで、CPUのペグにつながるパターンに気付くのに十分な場合に、システムの履歴を振り返るのに適しています。システムBSODの場合、dmpをwindbgに投入できます。
CPUスパイクにつながる可能性があるものを探している場合：
- Sysinteralsからのプロセスエクスプローラー：存在しないファイルまたはネットワーク共有への奇妙なプロセスまたは開いているハンドルを探します。問題を再現するために正しい方向にあなたを指すかもしれません
- Windowsの信頼性とパフォーマンスモニター/ Perfmon：ディスク/ CPU /メモリ/ネットワークの使用状況や他の数百のカウンターに関して、各プロセスがどのように機能しているかを確認できます。それらは、VMが発生する前に何が実行されていないかについての手がかりを与えるかもしれません。
問題の適切な候補が得られたら、sysinternalsからProcess Monitorをオンにできます。システム上のすべてのプロセスがリアルタイムで行っているすべてのファイルとレジストリの相互作用をダンプします。起動時にロードし、次にGUIを実行するまですべてをキャプチャするように構成することもできます（これは大量のデータであるため、起動後に問題をすばやく再現できる場合にのみお勧めします）
根本的な原因の分析によってあなたを倒すことができるウサギの穴がたくさんあります。それがどのように進んでいるかを遠慮なくお知らせください。
ブルースクリーニングの場合は、ミニダンプファイルを確認してください： http://support.Microsoft.com/kb/315271
...これにより、（通常）クラッシュの原因となったドライバまたはソフトウェアの一部がわかります。
24時間ごとに正確にクラッシュしますか（毎日同じ時間に）？
もしそうなら、おそらくクラッシュを引き起こすスケジュールされたプロセスがあります。
クラッシュとはどういう意味ですか、サーバーがBSODに遭遇しているか、100％CPUでハングしているのですか？.
トラブルシューティングのために、サーバーログをsyslogサーバーに作成し、スクリプトリストを実行してリソースの使用状況を処理し、その出力をネットワーク共有に書き込むことができます。
サーバーがbsodを作成する場合、bsodに記載されているエラーコードを検索してみます。
また、おそらく、Acronisのアンインストールで、インストールフォルダーにいくつかの情報を含むエラーログが残った可能性があります。