VSSのCEventSystem・0x8007045bを調べる方法|アイドル停止との違い

VSSの「CEventSystemを開始できません」「0x8007045b、システム シャットダウンが実行中です」を見つけた時は、まず記録時刻とバックアップの結果を確認します。「アイドル タイムアウトによりVSSサービスをシャットダウンしています」という記録は別の内容です。ログの文字列だけでバックアップ破損やPCが落ちた原因と判断せず、実際に失敗した処理と同時刻の記録から調べてください。

目次

CEventSystem・0x8007045bの意味

Volume Shadow Copy Service information: The COM Server with CLSID {4e14fba2-2e22-11d1-9964-00c04fbbb345}
and name CEventSystem cannot be started.
[0x8007045b, A system shutdown is in progress.]

この例はCLSID {4e14fba2-2e22-11d1-9964-00c04fbbb345}、名前CEventSystemのCOMサーバーを開始できなかった記録です。Microsoftのエラー定義では1115(0x45B)はERROR_SHUTDOWN_IN_PROGRESS、つまりシステムのシャットダウンが進行中という意味です。HRESULTへの変換定義と対応する0x8007045bは、単独で特定のファイル破損、ディスク故障、CryptSvcの不具合を証明する値ではありません。

同じイベントIDでも、CLSID、名前、エラーコード、操作内容が違えば調査対象も変わります。CoCreateInstanceの呼び出しで同じ0x8007045bが出た場合も、記録時刻と処理の結果を照合します。「VSSのエラーはすべてこの手順で直る」と扱わないでください。

最初の判断:停止時の記録か、バックアップ失敗か

状況次に確認すること
予定したシャットダウン/再起動の時だけ記録され、バックアップは成功バックアップの完了時刻と停止時刻を比較し、通常稼働中に同じ失敗がないか確認
バックアップ中に0x8007045bが出てジョブも失敗再起動/シャットダウンを要求した処理とバックアップが重なっていないか
通常稼働中や起動時にも記録されるイベント全文、Windowsビルド、VSS以外の同時刻の記録を収集
アイドルタイムアウトの記録だけがある情報/警告/エラーのレベルと、直前のバックアップや復元ポイント作成の結果
フリーズ/突然の再起動もあるVSSと別に停止コードやシステム側の記録を確認。時刻が近いだけでVSS原因と断定しない

シャットダウン時だけの記録で、必要なバックアップが成功している場合は、まず状況を記録して経過を確認します。バックアップが失敗、復元ポイントが作れない、通常稼働中にも再現する場合は調査を続けてください。ログが消えたことだけを修復成功の基準にしません。

「アイドル タイムアウトによりVSSサービスをシャットダウンしています」は別の意味

このメッセージの対象はVSSサービスで、文章だけでWindows本体をシャットダウンしたことを意味しません。Microsoftのサービスの一般仕様でも、必要な時に起動し、仕事がなくなるとアイドルタイムアウトで停止するサービスの仕組みが説明されています。停止記録と実際のバックアップ失敗を分けて確認します。

イベントビューアでこの記録のレベルが[情報]で、関連するバックアップや復元ポイントの作成も成功しているなら、その記録だけを理由にサービスを自動起動へ変更する必要はありません。一方、同じ時刻に別のVSSエラーやジョブ失敗がある場合は、直前からの記録を確認します。

1.イベントとバックアップの時刻を揃える

  1. イベントビューアを開き、[Windowsログ]→[アプリケーション]でVSSや利用しているバックアップ製品の記録を確認します。
  2. [システム]側でも、停止/再起動の記録とVolSnap、ディスク、ファイルシステム等の関連記録を確認します。ソースがどのログにあるかを実際の一覧で確認してください。
  3. イベントの時刻、ソース、ID、レベル、全般の全文、詳細/XMLを保存します。IDだけを抜き出さず、CLSID、Writer名、エラーコードも残します。
  4. バックアップ製品側のジョブ開始/終了時刻、成否、エラーコード、対象ボリュームを比較します。OSのイベントだけでその製品のジョブ成功を判断しません。

調査に渡すログには、PC名、ユーザー名、ファイルパス等が含まれる場合があります。共有相手に必要な範囲を確認し、公開の場へ原本をそのまま載せないでください。

2.VSS・SwPrv・CryptSvcは、状態を確認してから変更する

[サービス](services.msc)でVolume Shadow Copy、Microsoft Software Shadow Copy Provider、Cryptographic Servicesの状態とスタートアップの種類を記録します。停止と無効は別です。手動設定や停止表示だけを見て、自動(遅延開始)へ変更すれば直るとは判断しません。

MicrosoftのWindows Server 2016向け一覧ではVSSとSwPrvは手動、CryptSvcは自動と説明されています。これはその資料の対象環境の説明で、すべてのWindowsやバックアップ製品へ同じ変更を強制する一覧ではありません。利用OSと製品の公式手順、会社の管理設定を確認してください。

コマンドで状態を確認する場合は、次の読み取り用の例を使用できます。PowerShellでもsc.exeと明記し、別のコマンドやエイリアスと混同しないようにします。sc.exe queryの公式説明に従い、STATEや終了コードを記録してください。

sc.exe query VSS
sc.exe query swprv
sc.exe query CryptSvc

RUNNINGだけでバックアップ成功を保証できず、STOPPEDだけで破損とも判断できません。無効化や起動失敗が見つかった場合は、そのPCの管理者やバックアップ製品の手順に沿って変更を判断します。動作中のバックアップに対してVSSや関連サービスを強制停止しないでください。

3.バックアップが失敗する時はwriter・provider・保存領域を確認する

管理者としてコマンドプロンプトを開き、バックアップを同時実行していない状況で次の一覧を収集します。これらはwriter、登録済みprovider、保存領域を調べる操作で、シャドウコピーを削除するコマンドではありません。

vssadmin list writers
vssadmin list providers
vssadmin list shadowstorage
確認対象読み方と次の調査
writer:list writers名前、State、Last errorを保存。失敗したwriterがあれば、そのアプリやサービスのログ/公式手順を確認
provider:list providersWindows標準以外にバックアップ/ストレージ製品が登録されているか確認。知らない項目を直ちに削除しない
保存領域:list shadowstorage元ボリュームとコピー保存ボリュームの関連付け、使用/割当/最大容量を確認。バックアップ先の空き容量と分ける

Microsoftのwriter状態の定義ではStableは処理を終えて次へ進める状態、または準備処理がまだ呼び出されていない状態です。バックアップが進行中なら待機状態もあり得ます。StateとLast errorを処理の前後で比較し、失敗状態のwriterを特定してください。全writerがStableでも、providerや保存領域、バックアップ製品側まで正常と証明したことにはなりません。

一覧コマンドが応答しない場合も、その時刻と状況を残します。作業を重ねる前に、すでに実行中のバックアップやスナップショット処理がないか確認し、製品サポートへ結果を伝えてください。

4.対処は確認された失敗に合わせる

  • バックアップとシャットダウン/再起動の時刻が重なる場合は、ジョブ完了を確認できる時間へスケジュールを調整します。更新や別のバックアップとの重なりも記録します。
  • 特定のwriterが失敗する場合は、そのwriterを持つアプリ/サービスの公式復旧手順を確認します。全サービスの一括停止やDLL再登録から始めません。
  • 容量不足が明示されている場合は、対象と保存領域の容量を確認して対処します。上限を変える前に、その製品の保持条件と必要なコピーを確認します。
  • OSやバックアップ製品の修正情報を確認する時は、実際のWindowsビルドとエラー条件を照合します。Windows10 1903~1909の不具合と、現在のすべての同じ文字列を結び付けて断定しません。

CryptSvc停止の自動化やシャドウコピー削除を先に実施しない

CryptSvcを毎回停止してから即時シャットダウンするバッチは、原因を特定する手順ではありません。Microsoftのサービス説明ではCryptSvcはWindowsファイルの署名確認やルート証明書の管理等を行い、停止するとこれらが正常に機能しないとされています。ログを消す目的だけで恒常的に止める運用を採用しないでください。

シャドウコピーを増やしすぎたように見えても、根拠なく一括削除しません。Microsoftのdelete shadows資料は削除が永久的で、依存する以前のバージョンや復元ポイントも失われると明記しています。System Volume Informationや関連レジストリの掃除も、バックアップ製品の根拠ある手順がないまま実行しないでください。

システムファイルの修復が必要な場合は、DISMの後にSFC

Windowsの機能不良やファイル破損が疑われる時は、Microsoftの公式修復手順に従い、管理者のコマンドプロンプトでDISM、完了後にSFCの順で実施します。アイドル停止の情報だけを理由に毎回修復する必要はなく、VSSのすべてのwriter/provider設定を直すことを保証する操作でもありません。

dism /online /cleanup-image /restorehealth
sfc /scannow

DISMは通常Windows Updateから必要なファイルを取得します。取得に失敗する場合はそのコードとログを保存し、利用OSに合う修復元を公式手順で確認してください。SFCは検証が100%完了するまでウィンドウを閉じず、表示された修復結果を記録します。

復旧の確認は、ログの有無に加えてバックアップの結果で行う

同じ対象へバックアップを再実行し、製品のジョブが成功したか、同時刻に失敗状態のwriterや関連エラーが残るかを確認します。復元テストは製品が案内する方法で、元データを上書きしない別の場所/検証環境へ行ってください。復元ポイント作成の成功だけで、別製品のイメージバックアップまで復元可能とは判断しません。

相談時はWindowsの版/ビルド、バックアップ製品と版、対象ボリューム、イベント全文、ジョブの結果、3つのvssadmin一覧、実施した変更と結果を揃えます。CEventSystem、アイドル停止、実際のバックアップ失敗を区別することが、必要な対処を選ぶ出発点です。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次