KP41は精神衛生上よろしくないですね。Windowsアップデートを機に発生し出したブルースクリーン病は結局クリーンインストールで解決しました。
当初は「Win10 May 2020 update(ver.2004)でブルースクリーンの嵐(41 Kernel-Power)」とまるでアップデートが犯人のようなタイトルにしていたのですが、その後Ver.2004にアップしても安定しているので、タイトルを訂正しました。Microsoftさん、疑ってごめんなさい。
構成
非UEFIレガシーBIOSマザーボード: ASUS M3A78-EM Socket AM2+ ※2009年7月購入
グラフィックボード: Palit GeForce® GTX 1070 Ti デュアル
CPU: AMD Phenom II X6 1100T（3.2GHz）
PC電源 : ATX550W電源（NE550C）
メモリ:DDR2 800MHz 4GB × 2枚 = 8GB
ストレージ: SSD 256GB(THNSNH256GCST)、160GB/U-ATA133（6L160P0)、 160GB/SATA300(ST3160812AS )
モニター : BenQ EW3270U(31.5インチ 4Kモニタ )
CPUのせい？
５月末にCPUをAthlonII X4 630からPhenomII X4 965に替えた頃から？何か突然電源が落ちるようになった気がする…、と薄々感じていました。消費電力が上がって不安定になったのか？それは嫌だな…、とCPUを疑っていました。
異常を確信したのは6月11日にPhenomII X6 1090Tに替えた時です。結果を楽しみにいざFFXVベンチマークをやってみたところ、消える…。FFXVベンチマークの画面が突然フッと消えてしまうのです。何度やっても最後まで到達する気がしません。それどころか、ブルースクリーンでOS再起動まで発生します。
イベントビューアーを見てみると、エラーやら警告の嵐！！
「例外コード: 0xc0000005」はメモリ領域のアクセス違反を表しており、要は「他人のメモリ領域を侵犯しているぞ！」というエラーが頻発していました。FFXVベンチマークを行うと必ず発生しますが、よく見るとFFXV以外のMicrosoftEdge.exe、svchost.exe、dwm.exeといったWindowsの提供するモジュールまでもが違反を犯していました。これは公共のお役人や警官が一般市民の住居へ侵入しているようなものです。普通じゃありません。
他にもデータベースの不整合を意味するような警告やエラーが秒単位で大量に出力されています。
警告 イベント642 ESENT svchost (3364,D,12) SRUJet: 現在のデータベースの形式が 1568.20.0 (パラメーター 0x410022D8 (8920 | JET_efvAllowHigherPersistedFormat) によって制御) のため、 データベース形式の機能バージョン 9080 (0x2378) は使用できません。
エラー イベント65 AppModel-Runtime SearchIndexer (3740,D,20) Windows: 現在のデータベースの形式が 1568.20.0 (パラメーター 0x410022D8 (8920 | JET_efvAllowHigherPersistedFormat) によって制御) のため、 データベース形式の機能バージョン 9120 (0x23a0) は使用できません。
メモリーは８GBしか積んでいないし、少ないのは事実です。CPUのコア数が４から６に増えたことでメモリへのアクセスが増えた？メモリが足りなくなった？足りないからって領域侵犯するのは異常（バグ）だけど、メモリを増やしてやれば侵犯の確率が低くなるのかな…。などと考え、メモリ８GBも注文しました。
でもデータベース形式が異なって使用できないって何？て感じです。ネットで調べても有用な情報はヒットしませんでした。
ESENTの警告642 について
その後、色々と情報が出てきました。
上記ESENT(Extensible Storage Engine NTバージョン。別称JET Blue)というJETデータベースエンジン(Joint Engine Technology)に関する警告は無害のようです。
ESENTはもともと「Microsoft Exchange Server」のために開発されたデータベースエンジンで、“Active Directory”や“Windows Update”などMicrosoft製品でデータ管理用のデータベースとして使われています。
データベースの拡張子は*.edbで、cドライブを検索するといくつか検索されます。
ちなみに、Microsoft AccessのデータベースエンジンはJET Red(拡張地*mdb)と呼ばれる技術を元にしており、ESENTと区別されています。
ESENTはWindowsNTの頃から使われるデータベースで、バージョンアップを繰り返しているため、データベースを利用するアプリが想定するバージョンが、プラットフォーム(OS)が提供するデータベースのバージョンと同期が取れていない場合もあり得ます。
エラー642は同期が取れていない場合に出る警告（エラー）のようですが、不具合が発生するわけではないようで、無視してよい、といった回答がMSのフォーラム等で出ています。
ちなみに英語のメッセージは
svchost (3364,D,12) SRUJet: The database format feature version 9080 (0x2378) could not be used due to the current database format 1568.20.0, controlled by the parameter 0x410022D8 (8920 | JET_efvAllowHigherPersistedFormat).
「svchost SRUJet:このデータベースの形式ver9080(0x2378)は、現在のデータベース形式1568.20.0（パラメーター 0x410022D8 (8920 |JET_ efvAllowHigherPersistedFormat)によって制御される形式）では使えません」
と読めますが合っているでしょうか。イベントログの日本語はちょっと難しいですよね。
あぁ、Windowsアップデートか
イベントビューアを見ていくと、6月6日から「重大」エラー（ブルースクリーン）が起きだしていました。AthlonII X4 630からPhenomII X4 965に交換した５月末よりはタイミングが少し遅いですし、PhenomII X6 1090Tに替えた後も発生しています。
少なくともPhenomII X4 965の時はここまで顕著ではなかったです。PhenomII X4 965に戻しても現象は収まらないので、CPUが原因ではなさそうです。
あ、そういえば促されるままWindwosアップデートしてた事に気づきました。今回の大型アップデートはブルースクリーンが問題になって配布を中断していた、という噂も聞いた気がします。
Windowsアップデートが原因だ、と自分としては納得し、前の状態に戻すべく以下のことをやってみました。
やってみたこと
解消すべく、以下のような事をやってみたのですが、私の場合は効果がありませんでした。なので、細かい手順は端折りざっくり説明します。
前のバージョン（1909）に戻す
Windowsの「設定」-「更新とセキュリティ」-「回復」メニューにある、「前のバージョンのWindows10に戻す」で1909に戻してみました。
理屈の上ではほぼこれで解消、と期待していたのですが、現象は変わりません。FFXVベンチマークの画面はやはり消えます。ブルースクリーンも発生します。何で？
KP41対策
ネットには対策としてコントロールパネルの「電源オプション」の設定を
・高パフォーマンス
・Windows高速起動をOFF
などが挙がっていました。変更してみましたが、効果はありませんでした。
私の場合は元々そのあたりを変更しなくても安定して動いていましたし…。
デバイスドライバやサービスの残骸を削除
イベントビューアーに、「AMD External Events Utility サービスが見つかりません」、「AODDriver4.3.0 サービスを開始できません」、といったエラーが出ていました。調べてみると、過去に使っていたAMDのグラボのドライバやユーティリティの残骸がゾンビの如く動こうとしてエラーになっているようです。
コントロールパネルの「管理ツール」にある「サービス」や「コンピューターの管理」でサービスの残骸やデバイスドライバーの残骸を削除しました。私の場合、グラボ（AMD Radeon HD 7700Series）の他にCPUも交換（Athlon630、Phenom965、semplon）しているため、これらの残骸も併せて削除しました。
以下は残骸を消してすっきりした後の状態です。
私の場合はこれが一番効果があったように感じました。1909に戻すといった対策との合わせ技で効果が出たのかもしれませんが、ブルースクリーンは減った気がしました。また、FFXVベンチマークも前よりは長く持つようになりました。でも、やはり最後まで到達はできませんし、回数は減ったとは言え、ブルースクリーンは治まりませんでした。
グラフィックドライバの世代入替
NVIDIAのグラボのドライバを、残っていた古い物、最新の物など、３世代(ver446.14、445.87、442.92)を入れ替えてみましたがいずれも効果はありませんでした。ちなみに、カスタムインストールにしないとクリーンインストールの実行は選べません。一応チェックするようにしました。
もう限界
ブルースクリーンが出る度、FFXVが落ちる度、イベントビューアーを確認してネットで検索して対処を考えるのですが、決定打はありません。謎が多すぎて何をしてよいのかもだんだん分からなくなってきました。
「もうこんな生活イヤーッ！」って感じで我慢の限界を超えてしまい、一番避けたかったクリーンインストールを行うことにしました。
そして現在。Ver.1909で今のところ一度もブルースクリーンが出ることなく安定して動いています。NVIDIAグラフィックドライバーは最新のVer446.14を使いました。
FFXVベンチマークもメモリ８GBで問題なく最後まで到達しました。途中、ちょっと動作が重くなるたび「落ちるか？」とドキドキしましたが、落ちません。以前の安定した状態に戻りました。Phenom1090Tのベンチマークの結果は改めて報告します。
まとめ
理想としては原因を突き止めて「こうしたら直りました！」と皆さんに有用な情報を発信したかったのですが、結局クリーンインストールという最終手段となってしまいました。
有用な情報は発信できませんでしたが、個人的にはとにかく直ってホッとしています。クリーンインストールでも直らなかったら泥沼ですね…。
「回復」でVer.1909に戻してもダメなんですね。一度KP41エラーが出だすと、不可逆、という印象を受けました。恐ろしい…。今回はWindowsアップデートがきっかけなのかもしれませんが、私もCPUやデバイスを交換していますし、何が真の原因だったのかは分かりません。
後日、エラーが出まくっていたVer2004をクリアインストールしたら問題なく動きました。FFXVベンチマークも完遂します。Windowsアップデートというよりも、CPU交換などに伴うドライバの変更がブルースクリーンの原因と考えるようになりました。その経緯は改めて報告します。
真の原因は分かりませんが、土台（マザーボードやCPU）に近いドライバに不整合が起きてしまうと、いくら上物（Windowsやグラフィック・モニタ）で辻褄を合わせようとしても穴は塞ぎ切れないのかなぁ、という印象を受けました。
今回はアーキテクチャの異なるCPU(AthlonII X4 630 → PhenomII X4 965)に交換した時点で少なからず不整合が起きていたと思われます。あまり顕著じゃ無かったのでそれほど気にならなかったのが、更にPhenomII X6 1090Tに交換したことで決定的になったのだと想像します。
今まで同じマザーボードでこれほどCPUを交換した事が無かったので意識が低かったのですが、CPUを交換したら原則クリアインストールする必要がある、ってことですね。ここまで多岐にわたるCPUに対応しているAMD AM2+マザーボードだからこそ発生する現象なのかもしれません。
そういえば8GBメモリはまだ届いていませんが、解決してしまいました。無駄になってしまったかな…。
コメント