こんにちは**、高嶋健太郎(高嶋 健太郎)**、
Windowsサービススタックを深く掘り下げているようですね。Windows Updateの失敗やディスク容量の問題のトラブルシューティングをしているのかもしれません。コンポーネントベースサービス(CBS)ログは、Windowsのアップデートに関する問題の診断に確かに重要です SFC.exe DISMが、その管理動作は標準的なイベントビューアログとは異なります。
主なログファイルは正しいC:\Windows\Logs\CBS\CBS.logです。通常の操作では、Windows Modules Installer(TrustedInstaller)サービスがこのファイルに書き込みを行います。内蔵の「ソフト制限」は約__50MB__です。CBS.log この閾値に達すると、システムは現在のログを にリネームしCbsPersist_[Timestamp].log、その後.cabスペースを節約するためにアーカイブに圧縮します。このプロセスが正しく動作すれば、その .log フォルダ内に小さなアクティブなファイルといくつかの圧縮アーカイブが見られるはずです。しかし、一般的な故障シナリオとしては、圧縮プロセス(を用makecab.exeいる)がクラッシュまたは失敗し、多くの場合は の問題が原因ですC:\Windows\Temp。この場合、ログ回転が失敗し、 CBS.log 制御されずに増え、数十ギガバイトものディスク容量を消費する可能性があります。
生成管理のためのレジストリ制御に関しては、標準的なWindowsイベントログ(明確なMaxSizeレジストリキーを持つ)とは異なり、CBSのログサイズ制限と回転ロジックはサービススタックのバイナリにハードコーディングされており、特定の「MaxLogSize」レジストリ値から直接設定できないことに注意が必要です。ただし、 __ レジストリを通じてこれらのログの生成や詳細を制御できます。関連するキーは以下の通りです: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing
このキー内で、DWORD値を見つける(または作成可能です)。という名前のDワードが存在しますEnableLog。これを設定すると0、TrustedInstallerがCBSログを完全に生成するのを実質的に止められます。これによりファイルの拡大は防げますが、将来のアップデート失敗には気づかなくなるため、通常は一時的な診断手段やスペースの限られた組み込みシステムでは最後の手段として推奨されます。ローテーションしない膨大なログファイルを扱っている場合、標準的なエンジニアリングの修正はレジストリの調整ではなく手動リセットです。サービスを停止 Windows Modules Installer し、およびの内容を削除 C:\Windows\Logs\CBS C:\Windows\Tempし、サービスを再起動して新しいログ生成サイクルを強制します。
ここで何か役に立つものが見つかっていることを願っています。もし問題についてより深く理解できるような情報が得られるなら、その答えを受け入れていただけるとありがたいです。 もし他に質問があれば、どうぞメッセージを残してください。よい一日を!
副大統領