Windows Updateができない のと イベントログに disk (51)のエラーが出る

投稿者: | 2019年5月4日

Windows Updateができなくなっていた

設定からWindows Updateを開いても、0x80080005 のエラーになっていました。

備忘録なのでキャプチャほとんどはありません。

(結論というかやったこと)
対処療法としてSoftwareDistributionを削除する等の「あるある」なWindows Update関連の修復を行いました。
イベントログに disk1 のエラーが頻発していて関係しそうなのでいろいろ調べた結果、よくわからないので、パソコンの筐体をあけてSATAケーブルを差し替えてみました。推測ですが、SATAケーブルが不良か、ポートが不良か、しっかり刺さってないか、なにかあるんでしょう。(それが嫌でラッチ付きのケーブルを買っているというのに!)
イベントログでApplicationのほうにESENTのエラーも頻発してるので、直してみました。

備忘録なので、ここに書いてあることで確実に直るという保証はないし、違うケースもあれば、やったことで傷口を広げることもあるでしょう。
今どきは自己責任でと書いて置かなきゃいけないんでしょうかね? しらんがな、そんなん。人に文句言うやつは、管理者権限でパソコン使うなよ…と。
自分もgoogle先生を頼って、あっちこっち見て解決したので、記録を残しておこうくらいの意味です。

Windows Updateのエラー

Windows Updateを開いてもアップデートはエラーになるばかり。
履歴は参照できません。(固まります。)
設定 > ホーム > 更新とセキュリティ > トラブルシューティング > Windows Update でWindows の更新を妨げている問題を解決します。 というのをやってみましたが、なにか解決されたふうに出るくせに、何も解決していませんでした。

以下のイベントが出ています。

ソース Service Control Manager
ID 7023
Windows Update サービスは、次のエラーで終了しました:
%%3355444217

以下のコマンドを実行しました。
sc queryexe wuauserv で見ると、stopped になっていましたが、net stop wuauserv も実施はしています。

net stop wuauserv
cd /d C:\Windows
ren SoftwareDistribution SoftwareDistribution_old
net start wuauserv
net stop bits
net start bits
net stop cryptsvc
cd /d c:\Windows\system32
ren catroot2 catroot2_old
net start cryptsvc

ちなみに、上記の net start wuauserv のところまでいけば、Windows Updateが動くようになりますが、違うエラーになるので、最後までやりきったほうがいいです。「しらんけどな」

真の原因はSATAの接触不良?

そのdisk1のエラーが大量に出ているのですが、原因が不明。
ソース: Disk
イベントID: 51
ページング操作中にデバイス \Device\Harddisk1\DR1 上でエラーが検出されました。


ページファイルの読み書きかと思い、仮想メモリを他のドライブに移してみましたが、SATAケーブルを差し替えてみればわかりやすいだろうと、実際にやってみました。
マシンはすでに4ポートすべてを使っているので、SSD同士で差し替えです。

抜けかける事件は昔にもあったので、ラッチ付きのケーブルを使うようにしていますが、実際には接触不良の可能性は残るんですね。

この時、シャアは通信機の接触不良にしてたっけ。


機動戦士「ガンダム」第10話「ガルマ散る」より

Applicationのイベント、ESENT ( 447 と 467 )

このイベントも大量に出ていました。
Application のエラー、ソースはESENTで、IDは447と467です。


svchost (3304,D,22) SRUJet: データベース C:\WINDOWS\system32\SRU\SRUDB.dat (3897 => 1221、3895) の B-Tree (ObjectID: 27、PgnoRoot: 240) から、誤ったページ リンク (エラー -327) が検出されました。
イベント XML:

svchost (3304,D,23) SRUJet: データベース C:\WINDOWS\system32\SRU\SRUDB.dat: テーブル {5C8CF1C7-7257-4F13-B223-970EF5939312} のインデックス UserIdTimeStamp が壊れています (0)。


これは SRUDB.dat 絡みで、そこから探っていくと、このSRUフォルダを使っているのは、Diagnostic Policy Service との情報にたどり着きました。

診断ポリシーサービスで、Windows コンポーネントの問題を検出、トラブルシューティング、および解決のためということです。
この中に、 Windows Update のトラブルも含まれるようです。Windows 7時代は殆ど役に立たなかった(何も解決してくれない、出てくるメッセージは意味不明、というよくあるクソな上司とかあそこにいた営業の課長・支店長みたいな)サービスだったようです。しかし、Windows 10では役に立つようになったんだとか。
つまりは、「サービスを止めてしまえばエラーは出なくなります」

世の人々は、Microsoftのサービスを止めるのが好きなので、自分も止めたままにするかと思ったのですが、とりあえず動かすことにしました。

まず、サービスを停止します。サービスがうまく止まらないので「無効」にしてマシンを再起動。(サービスが止まっても、次にやりたいSRUフォルダの中身の削除ができません。)

C:\WINDOWS\system32\SRU フォルダですが、これは sru で小文字でした。
このフォルダの中身をごっそりざっくり削除します。

sruフォルダは管理者権限のユーザーでもアクセス権を取得してから出ないと中身は見れません。ここは意を決して取得します。
セーブしてとっておいてもいいですが、再作成されるのでガッツリ削っても問題ないようでうす。(しらんけどな。)

比較したら、SRUDB.dat.IRS.RAW というファイル以外は作成されていました。

このあと、アクセス権を戻す等はせずに、Diagnostic Policy Service を「自動」にして、マシン再起動。

これで ESENT のエラーもでなくなりました。

推測

SATAケーブルの接触不良でディスクIOが障害を起こし(遅延書き込みデータの消失のような怖いログも出ていたので)、Windows Updateの情報が壊れてしまったのではないかと考えています。