locked
消えてしまったアプリケーションログの取得方法 RRS feed

 > 

  • 質問

  • Question
    サインインして投票
    0
    サインインして投票

    先日、ファイルサーバのバックアップを実施中にWindowsに予期しない再起動がかかりました。

    その原因を特定しようとシステムビューアからWindowsログを確認しております。

    再起動がかかった時間帯のアプリケーションログが見つからず、ここ2,3日のログしか残っておりませんでした。

    インターネットで調べると容量次第で古いものは上書きされる記載があったので、上書きされてしまったのかと思います。

    上書きされてしまったアプリケーションログを確認する方法はないのでしょうか?

    また、アプリケーションログ以外からWindowsの再起動を特定できるような方法はないでしょうか?

    バックアップが再起動の原因かどうかがわからないと、再度バックアップが実施できない状況で、困っております。

    2016年8月1日 4:18

すべての返信

  • Question
    サインインして投票
    1
    サインインして投票
    アプリケーション ログが２～３日で消えてしまうとは、ちょっと考えにくいと思うのですが。。。
    再起動が起きたということは、おそらくシステム クラッシュ (BSOD: Blue Screen Of Death) が発生したのだと思います。
    BSOD が発生した場合、アプリケーション ログではなく、システム ログにその情報が記録されます。
    "C:\Windows" フォルダに、再起動が起きたタイスタンプの "MEMORY.dmp" というファイルが残っていれば、それを解析すれば再起動の発生原因を特定できる可能性があります。
    (ただ生成されたダンプ ファイルの種類が「完全メモリ ダンプ」以外の場合は、原因特定できる可能性はかなり下がってしまうと思います。)
    2016年8月1日 5:36
  • Question
    サインインして投票
    0
    サインインして投票

    MEMORY.dmpは残念ながらありませんでした。。。

    アプリケーションログは先ほど確認しても2日前のものが消えていたので、最新2日分程度しか保存できない設定になっているみたいです。一応システムログはメーカに確認してもらっております。

    5：40頃にバックアップが失敗し、そこから12：00頃までシステムログが全くありませんでした。

    バックアップサーバのログからもタイムアウトエラーが出ており、Windowsの応答がかえって来なくなったと思われます。

    システムログが全く取れていないことからWindowsが不安定な状態で、12：00頃についに再起動がかかったようで、

    再起動以降は正常に稼働しています。

    システムログが全く取れなくなってから再起動がかかったのでシステムログがなかったということでしょうか

    2016年8月1日 7:35
  • Question
    サインインして投票
    0
    サインインして投票

    > アプリケーションログは先ほど確認しても2日前のものが消えていたので、
    > 最新2日分程度しか保存できない設定になっているみたいです。
    > 一応システムログはメーカに確認してもらっております。

    「最新2日分程度しか保存できない設定」とのことですが、ご自身でなにか設定をされたのでしょうか？
    私の場合、かなり Low Spec な (メーカーは Windows 10 をサポートしていない) マシンに Windows 10 をインストールして使用していますが、そんな環境でもシステム インストール時からアプリケーション ログとシステム ログは、すべて残っています。

    > システムログが全く取れなくなってから再起動がかかったのでシステムログがなかったということでしょうか

    その可能性もあるのかもしれませんが、私はそのような状況に遭遇したことが無いので、何とも言えません。
    ちなみに、"C:\Windows\Minidump" フォルダにも、該当タイムスタンプでの dmp ファイルは存在していないのでしょうか？
    一般的にシステム クラッシュ (BSOD) は、NT カーネルがシステムの不整合を検出した場合に、暴走によるシステム破壊を防ぐために意図的に BSOD を発生させ、その際にメモリの情報をダンプ ファイルとして保存させるのですが、もしダンプ ファイル (*.dmp) が全く生成されていないのであれば、ソフトウェア的な要因ではなく、ハードウェアに起因する原因で落ちたのかもしれません。
    BSOD 時のダンプ ファイルが生成されず、システム ログにもエラー情報が残らないとなると、原因究明はかなり難しいかも。。。
    （この問題現象に再現性があれば、まだ調べられる可能性があるのですが。。。）

    とりあえず "CrystalDiskInfo" などの Disk Utility を使用して、Disk Device に問題がないか確認されることをお勧めします。
    2016年8月1日 8:10
  • Question
    サインインして投票
    0
    サインインして投票

    やきです。

    >アプリケーションログは先ほど確認しても2日前のものが消えていたので、最新2日分程度しか保存できない設定になっているみたいです。

    そうとも限りません。アーカイブされている可能性もあります。
    [イベントビューア] - [Windows ログ] - [アプリケーション]右クリック [プロパティ] で、「イベントを上書きしないでログをアーカイブする」になっていれば、同画面の「ログのパス」に残っているかもしれません。あとは、バックアップクライアント独自のログがあるなど。

    > システムログが全く取れていないことから
    これは[イベントビューア] - [Windows ログ] - [システム]
    のことで間違いないでしょうか。
    システムログが全くないということは、その時間帯サーバーがシャットダウンしていたのではないでしょうか。いったん途切れた後、イベント6008に「以前のシステム シャットダウン は予期されていませんでした」のようなメッセージとともに、シャットダウンされた時刻が表示されているかもしれません。

    2016年8月1日 8:12
  • Question
    サインインして投票
    0
    サインインして投票

    アーカイブされてはいないみたいでした。

    「必要に応じてログを上書きする」という設定になっていました。

    また、今日確認してもアプリケーションログは7/31日以前のものがなくなっていました。（イベントビューア上で確認）

    システムログは「イベントビューア」-「Windowsログ」-「システム」で間違いありません。イベント6008はありませんでした。

    ただ、サーバが再起動がかかったと申告があったことと、業務影響が少なかったことから5時頃から12時頃までの長い時間ずっと止まっていたということはなさそうです。

    2016年8月2日 1:33
  • Question
    サインインして投票
    0
    サインインして投票

    サーバの設定は実は私が設定したものではないのでよくわからないのです。

    イベントビューアのプロパティを見ると、アプリケーションログ、システムログともに「必要に応じてログを上書きする」になっており

    最大ログサイズは「20480」です。

    システムログは2013年のものまで残っているみたいです。

    dumpファイル、およびminidumpフォルダは見当たりませんでした。。。

    2016年8月2日 1:52
  • Question
    サインインして投票
    0
    サインインして投票

    下記事項に関して確認していただけますか？
    なおイベント ビューアで表示される各種ログは、時系列で表示されていないことがあるので、確認する際は必ず <日付と時刻> をクリックし、ソートし直してから確認してください。

    --------------------------------------------------------------------------
    <確認したい情報>
    ☆ 以前にお伺いしたお話では
      「5：40頃にバックアップが失敗し、
        そこから12：00頃までシステムログが全くありませんでした。」
       とのことですが、この間セキュリティ ログにも何も記録されていないのでしょうか？

    ☆ "%SystemRoot%\Inf" フォルダに "setupapi.dev.log" というファイルが
       存在していると思いますが、このファイルにも 5:40 ～ 12:00 の間は
       何も記録されていないでしょうか？
       さらに "setupapi.dev.log" の 5:40 直前に記録されている内容は、
       どのようなものでしょうか？

    ☆ アプリケーション ログのプロパティで、[ログのパス], [ログのサイズ],
       [作成日時], [更新日時], [アクセス日時] は、それぞれどのように表示されて
       いるのでしょうか？
    --------------------------------------------------------------------------


    • 編集済み お馬鹿 2016年8月2日 3:02
    2016年8月2日 3:02
  • Question
    サインインして投票
    0
    サインインして投票

    >☆ 以前にお伺いしたお話では
    >  「5：40頃にバックアップが失敗し、
    >    そこから12：00頃までシステムログが全くありませんでした。」
    >   とのことですが、この間セキュリティ ログにも何も記録されていないのでしょうか？

    セキュリティログもアプリケーションログ同様8/1のものまでしか確認できませんでした。


    ＞☆ "%SystemRoot%\Inf" フォルダに "setupapi.dev.log" というファイルが
    ＞   存在していると思いますが、このファイルにも 5:40 ～ 12:00 の間は
    ＞   何も記録されていないでしょうか？
    ＞   さらに "setupapi.dev.log" の 5:40 直前に記録されている内容は、
    ＞   どのようなものでしょうか？

    setupapi.dev.logというファイルは見つかりませんでした。

    setupapi.devいうファイルがありました。
    再起動が発生した日のログは以下のものしかなかったです。

    [Boot Session: 2016/07/24 13:56:07.610]

    また、これの一つまえのログは
    <<<  Section end 2016/06/11 09:05:51.469
    上記の日付のものなので関係なさそうです。

    他には「setupapi.ev1」「setupapi.ev2」「setupapi.ev3」というファイルならありました。

    ＞☆ アプリケーション ログのプロパティで、[ログのパス], [ログのサイズ],
    ＞   [作成日時], [更新日時], [アクセス日時] は、それぞれどのように表示されて
    ＞   いるのでしょうか？

    ログのパス：%SystemRoot%\System32\Winevt\Logs\Application.evtx
    ログのサイズ：20.00MB
    作成日時：2010年4月6日
    更新日時：2016年8月1日
    アクセス日時：2010年4月6日

    となっております。



    2016年8月2日 5:39
  • Question
    サインインして投票
    0
    サインインして投票

    再起動がかかったのは、2016/07/24 12:00 ごろということでしょうか？
    また "%SystemRoot%\System32\Winevt\Logs\Application.evtx" ファイルおよび "%SystemRoot%\System32\Winevt\Logs\Security.evtx" ファイルともに サイズが 20MB になっているということでしょうか？
    これらのファイルに２日間程度のログしか記録されていないのに、サイズが 20MB もあるということは、ちょっと考えられないと思うのです。
    C: ドライブに十分な空き容量がありか、および C: ドライブの一部が破損していないか、確認されてみては？

    あと。。。
    一番はじめの質問での「Windowsに予期しない再起動がかかりました。」は、なぜそのように判断されたのでしょうか？
    （Windows Update 等で自動的に再起動がかかった可能性はないのでしょうか？）

    2016年8月2日 10:08
  • Question
    サインインして投票
    0
    サインインして投票

    詳細調べてみると、再起動自体は手動で行ったみたいでした。朝からサーバへのアクセスができたりできなかったり
    かなり不安定な状態だったみたいで、12時頃についにpingすら当たらなくなったので手動で再起動したみたいです。

    冒頭では再起動の原因追及のためにアプリケーションログを追っていると記載しましたが、
    実際はWindowsサーバが正常ではなくなった原因を知り、再度バックアップを正常に実施したいという目的です。
    なので、5時頃にWindowsが不安定になった原因を引き続き追究したいと思っております。

    情報が間違っており、大変失礼しました。
    引き続きご助言頂ければ幸いです。

    ＞また "%SystemRoot%\System32\Winevt\Logs\Application.evtx" ファイルおよび "%SystemRoot%\System32\Winevt\Logs\Security.evtx" ファイルともに サイズが 20MB になっているということでしょうか？

    Application.evtx" ファイルは２０MBでSecurity.evtx" ファイルは10GBでした。
    2日分ということなのですが、イベントビューア上で日付でソートして確認しています。
    時間をおかないと全てのログが読み込まれないだけという可能性はないでしょうか。

    Cドライブの空きは2.37GB/49.9GBです。十分な空きでしょうか？・・・

    ＞一番はじめの質問での「Windowsに予期しない再起動がかかりました。」は、なぜそのように判断されたのでしょうか？
    ＞（Windows Update 等で自動的に再起動がかかった可能性はないのでしょうか？）

    これについては、昨日詳細な話を聞くまでは「5時頃から不安定になり、12時頃に再起動がかかった」と申告を受けていたので
    その言葉から判断しただけです。ただの伝達ミスでした。
    Windows Update等の可能性ははじめ疑っていたのですが、その時間帯にログが出力できていなかったので、
    そこもかねてアプリケーションログを追っておりました。(もうそこのアプリケーションログは必要なくなりましたが、、)

    2016年8月3日 0:57
  • Question
    サインインして投票
    0
    サインインして投票
    > 2日分ということなのですが、イベントビューア上で日付でソートして確認しています。
    > 時間をおかないと全てのログが読み込まれないだけという可能性はないでしょうか。
    evtx ファイルのサイズやレコードされているイベント数、さらには CPU やディスク アクセスなどのスピードにも依存するとは思いますが、瞬間的にすべてのログが読み込まれることはないと思います。
    <日付と時刻> などの項目をクリックすると「並べ替え中」と表示されると思いますが、少なくともこの表示が出ている間は、まだログの読み込み中のはずです。
    私の手元の環境では、約 25,000 レコードの 20MB のアプリケーション ログ（約１年分）のソートに、約 30 秒程度かかりました。
    アプリケーション ログにレコードされているイベント数は、いくつと表示されているのでしょうか？

    > Cドライブの空きは2.37GB/49.9GBです。十分な空きでしょうか？・・・
    C: ドライブのボリューム サイズが 49.9GB で、そのうちの空き容量が 2.37GB ということでしょうか？
    だとしたら、全然足りないです。
    デフォルト設定では、ブート ボリュームに仮想メモリ用の pagefile.sys が置かれるので、ブート ボリュームの空き容量は特に重要になります。
    ブート ボリュームの空き容量が不足しているために、Application.evtx 等のログ ファイルを正しく更新できていない。。。ということではないでしょうか？
    Explorer から C: ドライブのプロパティを開き、[ディスクのクリーンアップ] を実施してみては？
    どの程度空き容量が改善するかわかりませんが、もしかしたら効果があるかもしれません。
    なお、仮想メモリ (pagefile.sys) のサイズを変更すれば、空き容量を劇的改善させることも可能だとは思いますが、この変更はパフォーマンスに直接影響するので、個人的にはお勧めしません。
    2016年8月3日 2:57
  • Question
    サインインして投票
    0
    サインインして投票

    >アプリケーション ログにレコードされているイベント数は、いくつと表示されているのでしょうか？

    イベント数：44643と表示されています。
    「並び替え中」が消えてもログの昔のログが読み込まれて見えるようになるといったことはなかったのでこの可能性はないみたいです。

    　

    ＞C: ドライブのボリューム サイズが 49.9GB で、そのうちの空き容量が 2.37GB ということでしょうか？
    だとしたら、全然足りないです。

    その通りです。
    これが原因でログが2日分程度しか残せていないかもしれないのですね。
    ディスクのクリーンアップの際のデメリット等調べて実行するか決めようとおもいます。

    2016年8月3日 4:51
  • Question
    サインインして投票
    0
    サインインして投票

    バックアップのソフトを何を使っているのかわかりませんが、
    バックアップソフト側には何かエラーのログなどは残っていないのでしょうか？

    私も空き容量に関しては少なすぎると思いますが、
    アプリケーションログの保存期間については、何かのアプリが大量のログを書き込むなどしてるケースも考えられるので期間ではなく、件数で考えていくべきかと。
    例えば、ハードディスクに障害があるなどしてバックアップ時にファイルの読み込みに失敗して大量のログを出力したり
    ウィルス対策ソフトがログをたくさん出力していたり。。。

    今後のことを考えるとログの管理計画をしっかりしていただく必要がありますし、
    今後、万が一サーバーパフォーマンスが低下したときに調査が必要ということであれば
    パフォーマンスログの保存などもするべきだと思います。

    2016年8月3日 6:49
  • Question
    サインインして投票
    0
    サインインして投票
    > イベント数：44643と表示されています。
    たった２日間分のアプリケーション ログに、44,643 ものイベントがレコードされるとは、ちょっと考えられないのでは？
    2016年8月3日 7:19
  • Question
    サインインして投票
    0
    サインインして投票

    ログの詳細をみてみると、バックアップサーバのアクセスエラーのようなものが5秒に2回ずつでており、それが2日程ずっとでておりました。
    アプリケーションログに関してはこれが原因な気がします。。。

    ひとまずこのエラーの対策をしてみます。

    2016年8月3日 8:17
  • Question
    サインインして投票
    0
    サインインして投票

    計算してみると5秒に2回で44000件のログがでるのに30時間30分程かかるみたいです。
    ログを見てみると、だいたい30時間弱のログが保存されていました。


    • 編集済み Microemon 2016年8月3日 8:24
    2016年8月3日 8:23