日記帳

プログラミングのことをつぶやく日記です。

頻発するブルースクリーンの原因をClaudeに相談しながら調べた

日記

2026年7月下旬から、自宅のPCで頻繁にブルースクリーン(BSOD)が起きるようになった。 少なくとも15回以上発生しており、9月11日深夜から12日早朝にかけては数分から十数分おきに3連続で落ちるなど、悪化する一方だった。

最初はCPUグリスを塗りなおしたり、冷房の温度を落としてみたりしたけど発生してしまう。

何が起きているのか見当がつかなかったので、イベントログの読み方から仮説の絞り込みまで、AI(Claude)に相談しながら調査を進めた。 最終的にたどり着いたのは、Intelが第13世代と第14世代のCore i7/i9で公式に認めている電圧不安定性の問題だった。 やったことはBIOS(UEFI)更新とNVIDIAドライバ更新の2つだけだが、そこにたどり着くまでの切り分けを記録しておく。

環境

パーツ 内容
CPU Intel Core i7-14700K
GPU NVIDIA GeForce RTX 3060 Ti(ドライバ 591.86)
メモリ Crucial DDR4-3200 32GB×2(64GB)
マザーボード ASUS PRIME B760-PLUS D4
BIOS 1658(2024年5月22日リリース)

イベントログの読み方をAIに聞く

Windowsが予期せず再起動したりクラッシュしたりした記録は、システムのイベントログに残っている。 何を見ればいいのかAIに聞くと、次の3つを確認するよう教えられた。

# 予期しない再起動(Kernel-Power, Event ID 41)
Get-WinEvent -FilterHashtable @{LogName='System'; Id=41} -MaxEvents 20

# ブルースクリーンの詳細(BugCheck)
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1001; ProviderName='Microsoft-Windows-WER-SystemErrorReporting'} -MaxEvents 15

# ハードウェアエラー
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'} -MaxEvents 15

これをPowerShellで実行し、出てきたログを一つずつAIに渡しながら読み解いてもらった。

BugCheckコードがバラバラだったことの意味

ログから分かったのは、クラッシュのたびにBugCheckコード(Windowsがブルースクリーン画面に表示する停止コード)の種類が毎回違うということだった。

  • 0x0000000a(IRQL_NOT_LESS_OR_EQUAL) 6回
  • 0x0000007f(UNEXPECTED_KERNEL_MODE_TRAP、いわゆるダブルフォルト)
  • 0x00000101(CLOCK_WATCHDOG_TIMEOUT、CPUコアの無応答)
  • そのほか0x50、0xbe、0x153、0xfc、0xd1、0x1eなど

このバラつきが何を意味するのかAIに尋ねると、原因が特定のドライバであれば通常は同じコードが繰り返し出るはずであり、種類がランダムに出るのはソフトウェアよりもハードウェア、特にCPUや電源の不安定性を示す傾向として知られている、と説明された。

さらにログを遡ると、7月12日にはWHEA(Windows Hardware Error Architecture、ハードウェアエラーを記録する仕組み)のログに「fatal hardware error」が1件記録されていた。 同じ時期にNVIDIAドライバ(nvlddmkm)のタイムアウトエラーも複数回発生していたので、GPUドライバの古さも一因の可能性として残しつつ、まずはCPU側を疑う方向で調査を進めることにした。

CPU型番から見つかったIntelの既知問題

搭載していたCPUはIntel Core i7-14700Kだった。 この型番をAIに伝えると、Intelが2024年に公式に認めたVmin Shift Instabilityという問題の対象だと教えられた。

Intelはこの問題について、次の4つの発生要因を特定している1。

  • マザーボードの電力設定がIntelの推奨値を超えていること
  • eTVBアルゴリズムが高温時にも高パフォーマンス状態を維持し続けること(マイクロコード0x125で対応)
  • SVIDアルゴリズムが高電圧を要求すること(マイクロコード0x129で対応)
  • アイドル時や軽負荷時に過大な電圧要求が発生すること(マイクロコード0x12Bで対応)

0x12Bはこれら全てを包括する対策とされている。

自分のマザーボードのBIOSバージョンを確認すると、1658(2024年5月22日リリース)だった。 このバージョンにはIntel Default Settingsの導入は含まれていたが、eTVB以降の電圧対策(0x125以降)はまだ含まれていなかった。 つまり、対策前のマイクロコードのまま長期間稼働していたことになる。

やったこと

Intel自身が推奨しているのは、BIOSでのIntel Default Settings適用と、マイクロコード0x12F以降を含む最新BIOSへの更新である2。 実際に行ったのは次の3つだけである。

  1. BIOSをUSBメモリ経由で最新版(1836)に更新した
  2. NVIDIAドライバをNVIDIA App経由で最新版に更新した
  3. 更新後、BIOS設定でIntel Default Settingsが有効になっていることを確認した

BIOS更新の手順は次のとおりだった。

  1. ASUSサポートページから最新BIOSをダウンロードし、zipを展開して出てくる.CAPファイルをFAT32フォーマットのUSBメモリのルート直下にコピーする
  2. USBメモリを挿した状態でBIOS画面に入る(起動直後にDeleteキーを連打する、間に合わなければWindowsの回復メニューからUEFIファームウェアの設定へ進む)
  3. Advanced Mode(F7)に切り替え、Tool → ASUS EZ Flash 3 Utilityを選択する
  4. USBドライブと.CAPファイルを選択し、バージョン確認画面でYesを押して書き込む

今のところの結果と、まだ確定していないこと

更新後しばらく様子を見ているが、今のところ再発していない。

今回実施した、マイクロコード更新は今後の電圧要求を是正し、劣化の進行を止める対策であり、既に生じてしまった物理的な劣化(Vmin Shift)そのものを修復するわけではないらしい。ということはどこかでまた再発するのだろうか。

AIに調べてもらったら、Intelはこの問題の対象プロセッサについて保証期間を2年延長し、購入日から最大5年のカバレッジを提供すると案内しているらしい。[^2]。 今後同様の頻度でクラッシュが続くようなら、購入元を通じた保証交換(RMA)も検討するつもりである。

  1. Intel Core 13th and 14th Gen Desktop Instability Root Cause Update(Intel公式コミュニティブログ) https://community.intel.com/t5/Blogs/Tech-Innovation/Client/Intel-Core-13th-and-14th-Gen-Desktop-Instability-Root-Cause/post/1633239↩
  2. Intel Core 13th and 14th Gen Desktop Processor Vmin Shift Instability Issue – Latest Information(Intel公式サポートページ) https://www.intel.com/content/www/us/en/support/articles/000102331/processors.html↩

テストダブルはスタブとモックの二つで足りるかもしれない

C#

動機付けと結論

先日私が、社内でユニットテストの研修の講師をした。 研修の目的はテストダブルを習得することであり、よく紹介される五つの用語(ダミー、スタブ、スパイ、モック、フェイク)をさっと説明した。

ただ、いきなり全部説明すると理解がこんがらがりそうなので、スタブとモックに絞って説明したら、実はスタブとモックさえ説明したら実務で使うのはそれに加えてスパイかもしれないと感じた。

スパイ、ダミー、フェイクはスタブとモックの派生であるし、ダミーやフェイクを使うことはあまりないので、スタブとモックだけとりあえず覚えておけば困らなそうではあるのかなと感じた。

テストダブルとは何か

テストダブルは、テスト対象が依存している相手を、テスト用の偽物に置き換えたものの総称だ。 「ダブル」は代役という意味で、スタントダブルと同じ使い方になる。

なぜ偽物が要るのかを、例を使って考えてみる。 注文を確定するC#で書かれている OrderService クラスがあるとする。 このサービスは、外部の決済ゲートウェイにカード決済を依頼し、成功したら通知サービスに完了を知らせる。

public class OrderService
{
    public OrderService(IPaymentGateway payment, IOrderNotifier notifier, IReceiptPrinter printer) { /* ... */ }

    // 決済して、成功したら通知する
    public OrderResult PlaceOrder(int orderId, decimal amount, string cardToken) { /* ... */ }
}

PlaceOrder メソッドの振る舞いをテストしたい。 しかし、本物の決済ゲートウェイを呼ぶと、テストを実行するたびに実際のカードへ課金が走る。 本物の通知サービスを呼べば、そのたびにメールやプッシュ通知が飛ぶ。 外部のAPIは別にテストしたいわけではなく、 PlaceOrder の振る舞いさえ見れればよい。

じゃあ、決済ゲートウェイと通知サービスを偽物に差し替えればいいのでは？という発想からテストダブルがある。

テストダブル五分類

テストダブルの解説では、Gerard Meszaros による五分類がよく引かれる1。

  • ダミーオブジェクトは、受け渡されることはあるが実際に使用されることはない。パラメータリストを埋めたいだけといった場合に利用されることが多い。
  • フェイクオブジェクトは実際に動作するよう実装されてはいるが、手抜きがされているので製品版には向かない（InMemoryDatabaseが良い例である）。
  • スタブはテスト時の呼び出しに対して、あらかじめ用意された結果を返す。通常、テスト用にプログラムされたところ以外には応答しない。スタブは呼び出しの情報を記録することもある。例えば、Eメールゲートウェイスタブは「送られた（とされる）」メッセージを記録するような場合だ。単に「送られた（とされる）」メールの数を記録する場合もあるだろう。
  • スパイ は呼び出し方法に基づいて、なんらかの情報の記録も行うスタブである。その一例として、送信されたメッセージの数を記録するメールサービスが考えられる。
  • モックは、エクスペクテーションが事前にプログラムされたものである。エクスペクテーションとは、受信する一連の呼び出しの仕様を表わしたものである。期待されない呼び出しが行なわれた場合は例外をスローする。また、テスト実行後の検証(verification)で、期待された呼び出しがすべてきちんと行われたかどうかが確認される。

スタブとモックさえあれば、ダミーとフェイクは差し替えられる。 今回はC#で書くので、C# のモックライブラリ Moq2 を使う。

スタブ

スタブは、あらかじめ決めた値を返すだけの働きをする。 - 呼ばれた回数や引数は見ない。 - 値を返すだけ 決済を「必ず成功する」スタブに差し替えて、注文も成功することを確かめる。

var stubPaymentGateway = new Mock<IPaymentGateway>();
stubPaymentGateway
    .Setup(g => g.Charge(It.IsAny<decimal>(), It.IsAny<string>()))
    .Returns(new PaymentResult(true, "STUB"));

var orderService = new OrderService(stubPaymentGateway.Object, notifier, receiptPrinter);

var actual = orderService.PlaceOrder(orderId: 1, amount: 500m, cardToken: "tok_any");
    
        Assert.True(actual.IsSuccess);

見ているのは PlaceOrder の戻り値だけで、Charge の呼ばれ方は問わない。

.Returns を .Throws に変えれば、通信エラーのような再現しにくい異常系も同じ道具で起こせる。

stubPaymentGateway
    .Setup(g => g.Charge(It.IsAny<decimal>(), It.IsAny<string>()))
    .Throws(new HttpRequestException("接続できませんでした"));

モック

モックは、正しい引数と回数で呼ばれたかを検証する仕組みである。 - 戻り値ではなく呼ばれ方を見る。 - 呼ばれたかどうか確認することも可能 決済成功時に、正しい注文 ID で通知が一度だけ呼ばれることを Verify を使って検証できる。(Verifyはスパイなのだが、Moqライブラリだとモックとセットな感じがあるので、まとめて覚えてるのがよさそう。)

var mockNotifier = new Mock<IOrderNotifier>();
var orderService = new OrderService(stubPaymentGateway.Object, mockNotifier.Object, receiptPrinter);

orderService.PlaceOrder(orderId: 123, amount: 500m, cardToken: "tok_any");

mockNotifier.Verify(n => n.NotifyOrderCompleted(123), Times.Once);

向くのは決済やメール送信のように「呼んだこと自体が結果」になる。 ただし、内部呼び出しをモックで固めると、実装を変えるたびにテストが壊れる可能性が高くなるので多用は禁物かも。

使い分け

戻り値を決めたいならスタブ、呼ばれ方を見たいならモック。 これだけ覚えればあとは Verify だけ覚えておけば、やりたいことはほとんど実現できるうえに、C#はinterfaceがある上にAIでダミーやフェイクを飛ばしていきなり実際のクラスを実装されるので今の時代はとりあえずスタブとモックだけ覚えておけばよさそう。

  1. https://bliki-ja.github.io/TestDouble↩
  2. Moq は .NET 向けのモックライブラリ。https://github.com/devlooped/moq↩

ぷちコンの実装で参考文献そのまま実装した機能

概要

ぷちコンに応募したときに参考にした記事を列挙する。ここで列挙したものは基本的にはあまり改変せずゲームに実装した。

leokun0210.hatenablog.com

戦艦のビーム

レーザートラップを応用して動かして実装した。

[UE5] レーザーのトラップをつくってみよう｜株式会社ヒストリア

バリアエフェクト

九里江めいくさんにはめちゃくちゃお世話になった。この通りに実装し、BPでScaleを変更して調整した。

www.youtube.com

チャージエフェクト

パワーチャージエフェクトが欲しかったので、動画の通りに作成した。

www.youtube.com

【UE5】Ovarlay用にMeshが点滅するMaterialを作成する

UE5

概要

キャラクターのチャージ完了を状態を視覚的に分かりやすいように点滅するMaterialを作成した。

ActorのOverlayに作成したMaterialを適用した例

調査

点滅するMaterialを作成している動画を見つけた。UE4のものになるが基本は変わらないため、これを参考にして作成する。

youtu.be

実装

MaterialのBlend ModeをTranslucentに変更してOverlayしたときにMeshの元の色が塗りつぶされないようにする。上記の動画の通りにBlend Modeを設定するとMeshのMaterialが塗りつぶされてしまう。

Blend Mode

BPの実装は画像にした。Time関数を作成して点滅間隔を実現、Divideのノードの数値を大きくするほど光るフチが小さくなる。

作成したMaterialは以下の感じで点滅する。

UE5ぷちコン#24に参加した

概要

先日、第24回 UE5ぷちコンに制作したゲームを応募した。以下コンテストサイトより引用 1

UE5ぷちコンとは？ UE5ぷちコンとは、株式会社ヒストリアが主催するUnreal Engineを学習する事を目的とした、 ゲーム制作中心の作品制作コンテストです。

Unreal Engineを触ったことがない方でも気軽に勉強できる機会を作りたいという思いから 「2、3日でサクッと作ってサクッと応募」をコンセプトに定期開催しております。

参加者は短期間（約1か月半）でテーマに沿った作品を制作・投稿し、入賞を目指します。

本コンテストは学習目的なのでプロもアマチュアも関係ありません！ぷちコンに応募してUnreal Engineを覚えちゃいましょう！

応募作品

youtu.be

端的に言うと戦艦を強化しながら突撃(ダッシュ)して敵を倒しまくるゲーム、ローグライトから着想を得ており、今回のUEぷちコンのテーマである「スピード」と合致するようにプレイヤーである戦艦の攻撃手段をダッシュにした。ただダッシュして敵を倒すだけだと面白くないので、パワーチャージしてから解放してダッシュという形にすることでチャージ中は無防備になったりと駆け引きが生まれるようにしたかった。

実装するモチベーション

最近、石黒版銀河英雄伝説本伝をずっと観ていた。それっぽいゲームを作りたいと考えたのだがスピードという要素と組み合わせるのが非常に難しかった。ただ猛ダッシュで敵に突っ込むだけだと面白さが生まれないのでローグライト風にしてダッシュ力や攻撃範囲を強化したりするようにした。ローグライトの着想はエルデンリング ナイトレインから得た。私は、競技プログラミングのようなコンテストよりも実際に遊んだりして楽しめるものを作るコンテストのほうが実は向いているのではないかと最近思い始めた。私にとってゲーム制作があまり苦にならなかった。

今後のブログの予定

このゲームを開発するにあたって学んだことをまとめておく。英語のYouTubeなどを参照して作った部分もあるので、それを日本語での文章にしたら幾分かは誰かの助けになるのかもしれない。

結果

2025年10月3日にYouTube Liveで発表される。

  1. UE5ぷちコンの開催内容・応募方法・受賞作品｜株式会社ヒストリア↩