はじめに
私は最近までWindowsサーバの運用保守を行っておりました。
その中でサーバに不具合が発生した場合の動作確認や調査として、
・イベントログの確認
・サービスの起動状態の確認
・リソース使用状況の確認
等は行ってきましたが、それ移行に行う、以下のような解析は実施してきませんでした。
・イベントログとメモリダンプをMSのサポートに送付して解析してもらう
・HW系であれば、HWログをベンダーに送付して解析してもらう
・アプリケーションログをアプリケーションベンダーに送付して解析してもらう
そのため、今回はメモリダンプの中身を見て不具合の原因を探れるよう学習しました
メモリダンプ出力とツール解析
####1. メモリダンプを出力させられるサーバを用意
今回はAWSのEC2WindowsServerを用意しました。
クラウドは負荷テストや、このような学習目的で予期せぬ挙動を
実行させられる環境を直ぐに調達できて素晴らしいです
####2.メモリダンプを吐かせる
メモリダンプの出力は、Notmyfaultを利用しました。
Notmyfaultは、Windowsシステムでクラッシュ、ハング、およびカーネルメモリリークを
引き起こすために使用できるツールです。ツールはこちらにあります
2-1. Notmyfaultを実行
2-2. ダンプを吐かせたいエラーを選択しCrashを押下
エラーについて調べましたがこのような内容でした
| エラー名 | 内容 |
|---|---|
| High IRQL fault (Kerner-mode) | 割り込み要求に与えられる優先度が高すぎて本来アクセスするべきではない領域にアクセスしようとした(カーネルモード) |
| Buffer overflow | プログラムで用意されたバッファよりも大きなサイズのデータをバッファに書き込む事 |
| Code overwrite | Code overwriteそのももの説明がみつから無かったですが、STOPが0x000000beで、これはドライバーが読み取り専用メモリセグメントに書き込もうとしている場合とDocsに記載がありました |
| Stack trash | Stack trashそのももの説明がみつから無かったですが、STOPが0x0000001eで、これはカーネルモードプログラムが、エラーハンドラーがキャッチしなかった例外を生成とDocsに記載がありました |
| High IRQL fault (User-mode) | 割り込み要求に与えられる優先度が高すぎて本来アクセスするべきではない領域にアクセスしようとした(ユーザモード) |
| Stack overflow | プログラムを組んでいる最中で関数の呼び出しが多すぎる時に発生(無限ループ) |
| Hardcoded breakpoint | Hardcoded breakpointそのももの説明がみつから無かったですが、STOPが0x0000003bで、これは特権のないコードから特権コードに遷移するルーチンの実行中に例外が発生とDocsに記載がありました |
| Double free | 同じメモリー領域を二重に解放しメモリーの内容を破損 |
2-3. 切断が切れたことの確認(運用保守でヒヤヒヤする画面(・_・;))
2-4. 予期せぬ再起動が発生した画面を確認
2-5. イベントログからbugcheckコード(0x000000d1)とC:\Windows\MEMORY.DMPにメモリダンプが保管されていることを確認
以下Docsでbugcheckコード(0x000000d1)を確認できます
- 0x000000D1:割り込み要求レベル (IRQL) が高すぎたときに、ページング可能な (または完全に無効な)
アドレスにアクセスしようとしたことを示す
####3.解析ツールを入れて中身を確認
3-1. 解析ツールのインストール
こちらからWindows 10 SDKのインストーラを落とします。
インストーラを実行するとダンプ解析ツールWindbgを含む機能がインストールされます。
3-2. Windbg(X64)の実行
3-3. Open Crush Dumpを押下し↑の2で取得したメモリダンプを指定
3-4. run !analyze -vを押下し詳細を表示
3-5. PROCESS_NAMEやIMAGE_NAMEで被疑のを確認
Notmyfaultを確認することができました。
↑の2-5と併せて、Notmyfaultを実行した時にIRQLが高くページング可能な (または完全に無効な)
アドレスにアクセスしようとしたため発生させたと推測できます
感想、その他
-
以下のtechnetを参考にさせていただきましたが、
こちらの記事は10年以上前の記事です。このような10年前記事があるのに、
運用中に自分でメモリダンプを見てみようと行動しなかったことを反省してます。
https://blogs.technet.microsoft.com/askcorejp/2009/05/22/10/ -
記事とはあまり接関係はないのですが、リソースモニタとタスクマネージャの違いが
解り易く記載されていたサイトがあったので運用の方は是非以下をご覧になってみてください。
運用者は楽してタスクマネージャだけ見がちなので。。。
http://tooljp.com/windows/chigai/html/Windows/taskmanager-ResourceMonitor-chigai.html