none
シャットダウンの途中で停止する RRS feed

  • 質問

  • 手掛かりが少なく、どのように原因の調査をすればよいのか分かりません。

    調査する際のヒントを教えて下さい。宜しくお願い致します。

    ■ 問題の内容

    windowsのタスクにて、「shutdown.exe -r」を実行し、定期的に再起動を行っています。

    今回、この定期再起動処理にて、停止の途中で落ちきれない状況が発生しました。

    ■ 現象

    問題発生時、以下の事項を確認しています。

    ◎ PING疎通確認

    ⇒ OK

    ◎ リモートデスクトップによる接続

    ⇒ NG

    ◎ 画面表示

    ⇒ 真っ黒な画面が表示されていた

    ◎ タスク(Windows) 実行ログ

    ⇒ 実行結果ステイタスが「0x0(正常完了)」になっていることを確認

    ◎ イベントログ(セキュリティ)

    ⇒ イベントID:513「Windowsをシャットダウンしています。」が最後のログ

    ◎ イベントログ(システム)

    ⇒ イベントID:6006「イベント ログ サービスが停止されました。」が最後のログ

    ■ 環境

    Windows Server 2003 R2 Standard Edition Service Pack 2

    ※DBサーバとして使用しており、Oracleがインストールされています。

    以上、宜しくお願い致します。

    2010年7月2日 11:54

回答

  • こんにちは。

    原因や対処策を得るためには、問題発生時のダンプファイルを取得し、解析が必要なケースです。

    提示された情報からは、概要はわかりますが、詳細はわかりません。
    "◎ PING疎通確認 ⇒ OK " :まだドライバ ( Pingの応答はtcpip.sysが行います)が停止していないことが解ります。
    "◎ リモートデスクトップによる接続⇒ NG" :RDP接続が不可であることが解りますが、サービスが停止しているだけなのかどうかまでは解りません。
    "◎ 画面表示⇒ 真っ黒な画面が表示されていた" :何もわかりません。
    "◎ タスク(Windows) 実行ログ":タスクが正常完了していることと、シャットダウンの途中での停止は何の関係もありません。
    "◎ イベントログ(セキュリティ)" : シャットダウンが進行していたことがわかります。
    "◎ イベントログ(システム)"イベントログサービスが停止されていますので、ほとんどのサービスは正常に停止されています。

    詳細を確認する場合は、まず問題発生時のダンプファイル(完全ダンプファイル)を取得します。方法は次の資料を参照して下さい。
    http://support.microsoft.com/kb/927069/ja


    ◎ 停止処理のどの過程で止まっていたのかを確認する
    =>完全ダンプファイルを取得後、winlogon.exeのプロセスのスレッドのスタックやLPCポートなどを確認してください。
    スレッドが例えば何らかのI/O待ちになっているかもしれませんし、LPCで他のプロセスを待っているかもしれませんが、ダンプを確認して初めて状況が確認できます。

    ◎ 再発の可能性がある現象なのか確認する
    =>ダンプの解析状況次第です。

    ◎ 再発した際に詳細な調査が出来るようにするための対応策を確認する
    =>ダンプの解析状況次第です。例えば、何らかのI/O待ちになっている場合は、I/Oを処理しているドライバやハードウェアで対処する必要があります。ダンプの解析状況次第です。

    ◎ 再発させないための対応策を確認する
    ダンプの解析状況次第です。

     

    • 回答としてマーク 日本人 2010年7月5日 4:29
    • 回答としてマークされていない 日本人 2010年7月5日 5:15
    • 回答としてマーク 三沢健二Moderator 2010年7月14日 8:10
    2010年7月5日 3:48
  • こんにちは。

    >◎【確認】完全ダンプファイルの取得設定の目的

    これは、「再発した際に詳細な調査が出来るようにするための対応策」の1つとして行う設定であるとの認識で問題ありません。

    "再発を待たずに、調査できるログは残っていませんでしょうか。" については、OS標準ではまずイベントログです。
    ここにハードウェア系のエラーが記録されている場合は、原因の可能性があります。

    シャットダウン時に停止した場合(特にイベントログサービス停止後)は、そもそもいかなるイベントログも残りませんので、直接的な手がかりはありません。
    ただ、例えば突如、ードウェア系のエラーが記録され、その直後にシャットダウンが停止しているようであれば、状況証拠として関連が疑われます。

    直接的に調べるログはOS標準にはありませんが、システム固有のログ機能があるかもしれませんし、無いかも知れません。これは実機で調べてください、としか言いようがありません。


    >◎【確認】完全ダンプファイルの取得設定のリスク
    これは、1度実機でダンプを模擬的に取得し、その上でリスクを検討される事をお勧めします。
    理由は、そもそもリスクは状況によって大きく異なり、一概に言えないからです。

    例えば、完全ダンプファイルの設定後、OSの再起動が必要です。人によってはリスクになりますが、人によっては問題になりません。

    完全ダンプの取得には、C:ドライブにpagefile.sysを設定し、かつ物理メモリ+1MB以上の空き容量が必要です。人によってはリスクになりますが、人によっては問題になりません。

    通常の運用時には負荷の心配はありません。ただ、ダンプ取得の操作(NMIスイッチの押下やCtrl+Scrollキーの押下)を行うと、例え誤操作だったとしてもStopエラーが発生します。オペレーターに間違い操作があり得れば、これはリスクです。

    Stopエラーが発生すればダンプファイルの保存の時間がかかります。これは物理メモリの容量や、ディスクの書き込み速度で大幅に変化します。ものによっては、Stopエラー発生後数十分のサーバー停止に至ります。人によってはリスクになりますが、人によっては問題になりません。

    いざダンプを取得後、自力で解析可能であれば、リスクではありません。どうやって解析すればいいのか不明で、かつ誰にも頼めるあてがなければ、これはリスク(というよりやるだけ無駄)になります。


    リスクというものは人によって変わりますので、リスクの検討、洗い出しは日本人さんのお仕事になります。

    2010年7月6日 15:33

すべての返信

  • 度々申し訳ありません。

    今後、以下の事項を確認していきたいと考えています。

    ◎ 停止処理のどの過程で止まっていたのかを確認する

    ◎ 再発の可能性がある現象なのか確認する

    ◎ 再発した際に詳細な調査が出来るようにするための対応策を確認する

    ◎ 再発させないための対応策を確認する

    原因の調査に限らず、対応策等をご存知の方がいらっしゃいましたら、

    是非ご教示下さい。何卒、宜しくお願い申し上げます。

    2010年7月5日 2:29
  • こんにちは。

    原因や対処策を得るためには、問題発生時のダンプファイルを取得し、解析が必要なケースです。

    提示された情報からは、概要はわかりますが、詳細はわかりません。
    "◎ PING疎通確認 ⇒ OK " :まだドライバ ( Pingの応答はtcpip.sysが行います)が停止していないことが解ります。
    "◎ リモートデスクトップによる接続⇒ NG" :RDP接続が不可であることが解りますが、サービスが停止しているだけなのかどうかまでは解りません。
    "◎ 画面表示⇒ 真っ黒な画面が表示されていた" :何もわかりません。
    "◎ タスク(Windows) 実行ログ":タスクが正常完了していることと、シャットダウンの途中での停止は何の関係もありません。
    "◎ イベントログ(セキュリティ)" : シャットダウンが進行していたことがわかります。
    "◎ イベントログ(システム)"イベントログサービスが停止されていますので、ほとんどのサービスは正常に停止されています。

    詳細を確認する場合は、まず問題発生時のダンプファイル(完全ダンプファイル)を取得します。方法は次の資料を参照して下さい。
    http://support.microsoft.com/kb/927069/ja


    ◎ 停止処理のどの過程で止まっていたのかを確認する
    =>完全ダンプファイルを取得後、winlogon.exeのプロセスのスレッドのスタックやLPCポートなどを確認してください。
    スレッドが例えば何らかのI/O待ちになっているかもしれませんし、LPCで他のプロセスを待っているかもしれませんが、ダンプを確認して初めて状況が確認できます。

    ◎ 再発の可能性がある現象なのか確認する
    =>ダンプの解析状況次第です。

    ◎ 再発した際に詳細な調査が出来るようにするための対応策を確認する
    =>ダンプの解析状況次第です。例えば、何らかのI/O待ちになっている場合は、I/Oを処理しているドライバやハードウェアで対処する必要があります。ダンプの解析状況次第です。

    ◎ 再発させないための対応策を確認する
    ダンプの解析状況次第です。

     

    • 回答としてマーク 日本人 2010年7月5日 4:29
    • 回答としてマークされていない 日本人 2010年7月5日 5:15
    • 回答としてマーク 三沢健二Moderator 2010年7月14日 8:10
    2010年7月5日 3:48
  • 丁寧なご回答ありがとうございます。

    ダンプファイルに関しては、取得方法を含め、詳細を確認致しますが、

    取り急ぎ、1点確認させて下さい。

    >"◎ イベントログ(システム)"イベントログサービスが停止されていますので、ほとんどのサービスは正常に停止されています。

    ⇒「ほとんど」に含まれていないサービスは、具体的にどのようなサービスか分かりますでしょうか。

      ※Oracleに関連するサービスが停止状態になっていたのか否かを確認したいと思っています。

    ご面倒お掛け致しますが、宜しくお願い申し上げます。

    2010年7月5日 5:07
  • こんにちは。

    ⇒「ほとんど」に含まれていないサービスは、具体的にどのようなサービスか分かりますでしょうか。

    これは、ダンプ見ないとわかりません。

    OSのシャットダウン時、各サービスに対して停止要求が出されます。以下の資料の"SERVICE_CONTROL_STOP"です。

    http://msdn.microsoft.com/ja-jp/library/cc429053.aspx

    停止要求を受け取った各サービスは停止処理を進めていきます。サービスによってはさっさと停止するものもあるでしょうし、なかなか停止しないものもあるかと思います。

    提示された情報からは、.SERVICE_CONTROL_STOPが各サービスに要求された。 .少なくともイベントログサービスは停止完了まで進んでいる。(他のサービスも停止できるだけの時間は経過している)

    事が解ります。Oracle関連のサービスについては何とも言えません。Oracleのサービスに対してもSERVICE_CONTROL_STOPが要求されたことは確実ですが、あとはOracleのサービス次第です。Oracle関連のログにサービスの停止を判断できるものがあるか、確認してみてください。

     

     

    2010年7月5日 5:44
  • 度々のご回答、誠にありがとうございます。

    『完全メモリ ダンプ』について確認したところ、

    メモリ ダンプ ファイルとしては、以下の2つのみ選択できる状態でした。

    1.『カーネル メモリ ダンプ』

    2.『最小メモリ ダンプ』

    ※ メモリを4GB搭載しているからかも知れません。

        (参考)http://support.microsoft.com/kb/254649/ja

     尚、上記1、及び2のダンプファイルも出力されていないことを確認しています。

    他に確認できるログ等はありますでしょうか。

    また、次回発生に備え、仕掛けておくべきログ等がありましたら、併せてご教示頂けませんでしょうか。

    何卒、宜しくお願い申し上げます。

    2010年7月5日 6:46
  • こんにちは。

    ダンプに関してKB254649を参照されていますが、古い情報です。

    メモリを4GB搭載していても完全ダンプの取得は可能です。こっちの情報を見て下さい。

    http://support.microsoft.com/kb/972110/en-us

    また、シャットダウンの停止の場合、完全ダンプが最低限必要です。各プロセスとカーネルモードの両方を解析する必要があるためです。

    尚、今回取得する完全ダンプは、自発的に発生するStopエラーではありません。ユーザーの操作(NMIスイッチを押す、またはCtrl+ScrollキーでStopエラーを発生させる)により発生するStopエラーです。もう一度以下の資料を確認してください。

    http://support.microsoft.com/kb/927069/ja

     

    他に確認できるログ葉、OS標準ではありませんが、使用しているシステムによってはあるかもしれません。例えば、ハードウェアの方でWatch Dog Timer が実装されていれば、これを有効にしてもいいと思います。以下はこういった機能の一例です。

    http://www10.big.or.jp/~and/gba/watchdog.html

     

     

    2010年7月5日 7:11
  • ご回答頂き、本当にありがとうございます。

    念のため、確認させて下さい。

    ◎【確認】完全ダンプファイルの取得設定の目的

      今回、ご教示頂いた完全ダンプファイルの取得設定は、

       「再発した際に詳細な調査が出来るようにするための対応策」の1つとして行う設定であるとの認識で、

      問題ありませんでしょうか。

      ※再発を待たずに、調査できるログは残っていませんでしょうか。

        (繰り返しの質問となり、申し訳ありません。)

    ◎【確認】完全ダンプファイルの取得設定のリスク

      完全ダンプファイルの取得設定をした場合の懸念点がありましたらご教示頂けないでしょうか。

      ※サーバへの負荷や設定時のリスク等

    度々、お手数お掛け致しますが、何卒、宜しくお願い申し上げます。

    2010年7月5日 14:05
  • こんにちは。

    >◎【確認】完全ダンプファイルの取得設定の目的

    これは、「再発した際に詳細な調査が出来るようにするための対応策」の1つとして行う設定であるとの認識で問題ありません。

    "再発を待たずに、調査できるログは残っていませんでしょうか。" については、OS標準ではまずイベントログです。
    ここにハードウェア系のエラーが記録されている場合は、原因の可能性があります。

    シャットダウン時に停止した場合(特にイベントログサービス停止後)は、そもそもいかなるイベントログも残りませんので、直接的な手がかりはありません。
    ただ、例えば突如、ードウェア系のエラーが記録され、その直後にシャットダウンが停止しているようであれば、状況証拠として関連が疑われます。

    直接的に調べるログはOS標準にはありませんが、システム固有のログ機能があるかもしれませんし、無いかも知れません。これは実機で調べてください、としか言いようがありません。


    >◎【確認】完全ダンプファイルの取得設定のリスク
    これは、1度実機でダンプを模擬的に取得し、その上でリスクを検討される事をお勧めします。
    理由は、そもそもリスクは状況によって大きく異なり、一概に言えないからです。

    例えば、完全ダンプファイルの設定後、OSの再起動が必要です。人によってはリスクになりますが、人によっては問題になりません。

    完全ダンプの取得には、C:ドライブにpagefile.sysを設定し、かつ物理メモリ+1MB以上の空き容量が必要です。人によってはリスクになりますが、人によっては問題になりません。

    通常の運用時には負荷の心配はありません。ただ、ダンプ取得の操作(NMIスイッチの押下やCtrl+Scrollキーの押下)を行うと、例え誤操作だったとしてもStopエラーが発生します。オペレーターに間違い操作があり得れば、これはリスクです。

    Stopエラーが発生すればダンプファイルの保存の時間がかかります。これは物理メモリの容量や、ディスクの書き込み速度で大幅に変化します。ものによっては、Stopエラー発生後数十分のサーバー停止に至ります。人によってはリスクになりますが、人によっては問題になりません。

    いざダンプを取得後、自力で解析可能であれば、リスクではありません。どうやって解析すればいいのか不明で、かつ誰にも頼めるあてがなければ、これはリスク(というよりやるだけ無駄)になります。


    リスクというものは人によって変わりますので、リスクの検討、洗い出しは日本人さんのお仕事になります。

    2010年7月6日 15:33
  • こんにちは、フォーラムオペレーターの三沢健二です。

    中年やっちゅうねん さん、ご丁寧なアドバイスありがとうございます。

    案内いただいた内容が参考になられたようですので、勝手ながら [回答としてマーク] を付けさせていただきました。

    なお、タイミング的に、調査に必要となるログや情報の採取が難しい場合もありますので、その際には疑いのあるサービスや常駐アプリなどを一つずつ停止してどうかなどの地道な切り分けが必要になる場合もあります。
    (再現性があればそのような切り分けも試していただければと思います)


    それでは、今後とも TechNet Forum をよろしくお願いします。

    ______________________________________
    マイクロソフト株式会社 フォーラム オペレーター 三沢健二

    2010年7月14日 8:16
    モデレータ
  • 返信、遅くなり、大変申し訳ありません。

    丁寧なご対応、本当にありがとうございます。

    一旦、完全ダンプファイルの取得は見送ることに致しました。

    また、現在、ハードウェアのログを取得し、確認を実施しているところです。

    何かありましたら、改めて質問させて頂きたいと思っています。

    本当にありがとうございました。

     

    2010年7月15日 3:09