Skip to content

PCがアイドル付近になると落ちるためサルベージしつつCPU交換(SWR)した記録

   
11127文字(約18分)

壊れて悔しいので備忘録として、症状・原因・対策・復旧の過程を残す。くやしい

まとめ(教訓)

  1. 電源が突然落ちる不具合は手を抜かずすぐに調べよう
  2. パソコンは復旧するにも必要になる。二台持とう
    1. (推定)intel cpu 13世代は壊れるのでバックアップを準備しよう
  3. 暇つぶしにchkdsk C: /f /rをするのはやめよう(二敗)
    1. chkdskは本当に壊れたことを確認してからやろう。壊れてるかも、でやると逆に壊れる(自戒)
  4. 復旧用のOSで外付けグラボを使おうとするのはやめよう。オンボードから出力できるならそっちを使おう
    1. Re-Size BAR SupportをDisabledにすれば使える
  5. bootはドライブを合わせよう

症状・原因

低負荷時に時折PCがシャットダウンすることがあった。頻度的に微妙でかつ低負荷なタイミングであることまでは分かったがそれ以降原因のめどがつかず、仕事にかまけていたら原因の特定に手間取ってしまった。その結果、起動しない状態にまでおちいってしまった。具体的には起動時に、stop code: 0x24が出てWindowsが立ち上がらなくなった。

原因の結論としてはintel cpu不具合、なのだろう。windowsが破損したので復旧までの間にlinux(Pop! OS)を入れたのだが、linuxでも落ちた。そのためOSには依存しないということはわかっている。
GPUは電源と合わせて昨年変更したが、変更前に落ちることはなかった。変更後半年近く経ち突然落ちるようになった。そのため他のデバイスが関係ないという意味でのcpu単独、またはcpu, gpu, 電源の組み合わせにより発生したと考えられる。どちらにせよbiosの設定をcpuへの電力供給の項目について振ると落ち具合が変化したのでcpu側に何かしらの問題がある、ないし出たことは明白である。

マシン構成:
cpu: intel 13600k
gpu: nvidia RTX5070ti
マザーボード: MSI 790-PRO
電源: Corsair RM850e

対策

落ちるタイミングを見るとアイドル時, またはアイドルから急にクロックを上げた時の電圧上昇が原因に思える。そのため電圧上昇が起きてしまうことすなわち低電圧状態になることが問題と判断できる。
そのためあまり省エネ状態にならない設定とすることで緩和されるのではなかろうか、という仮説の元生成AI君にも聞きながらマザーボードのbiosを次の条件で振った。
その結果、どの設定でも落ちた。
サルベージ中にも落ちてもう無理かとも思ったが、小分けにして作業をして何とか終えられた。

パターン package c state limit cpu lite mode IA CEP 備考
1 C6 auto auto -
2 C2 auto auto -
3 auto mode 6 auto 他の条件より落ちやすかった気がする
4 mode 9 auto -
5 intel default setting auto 即死。ログイン画面で落ちる
6 mode 12 disabled -

ここで気になるのはintel default settingで落ちる点。これはマザーボードが各社電圧もりもりでクロックを上げに行っているところを抑える、みたいなイメージがあったがこれが一番やばかった。原因は最後まで分からなかった。

復旧

次のように被害を拡大しながら復旧をした。

  1. chkdsk C: /f /r
  2. windows起動しない原因切り分け
  3. linuxインストール
  4. testdiskでのサルベージ
  5. windows再インストール

chkdsk C: /f /r

なんか落ちるが整合性大丈夫かなと思って暇つぶしにかけた。かけたら立ち上がらなくなった(人生二敗目。昔のPCもこれで1回壊した)

このコマンドは生成AI君曰く

  • /f → ファイルシステムのエラーを修復
  • /r → 不良セクタを確認して読み取れるデータを回復

なのだが、エラーを修復する過程で破損させることがあるらしい。なんで修復と言って壊れるのだろうか、知らんがな。これにより起動しなくなった。もう気軽にかけないようにすべく、自戒も込めてここに記す。
生成AI君はこういう注意をもっとしっかりしてほしい、こういう知識不足による危険を回避する目的で聞いているのだから!(他責思考)

windows起動しない原因切り分け

起動はしないが、青い画面までは到達できる。このときにわからなかったのは、ファイルシステム側による中身の破損なのか、ハードウェアの破損なのか。
chkdskをするまでは動いていたし、Cドライブは2年ほど前にM.2SSDに換装したし、CrystalDiskInfoも入れていたのできっとおそらく多分大丈夫とは思っていた。しかし、切り分けのために再確認をすることにした。そこで次の点によりハードウェアに問題がないと判断した。

  1. MSIのbios画面でデバイスチェックができたので実施し問題なし
  2. diskpartでlist volumeを確認。それにより当該ドライブがRAW状態になっていることがわかる(=NTFSのフォーマットとして認識していない状態であり中身が異常になっている)
  3. SMART情報(これは後段のlinuxを入れたあとで確認した)

1,3はデバイスの正常性がわかる。推定問題なし。2は今どうなっていたのかがわかる、推定デバイスの破損ではなく、中身の問題。

これらより考えるに、デバイス自体はまだ壊れておらず予期せぬシャットダウンまたは整合性チェックによりファイルシステムが破損した可能性が高い。
調べるとtestdiskでパーティションを書き込み直せるらしいとのこと。一応やっては見るということで、USBメモリに入れてコマンドプロンプト(windows側のコマンドプロンプト)で起動してみた。しかし、依存ライブラリがないらしく起動しなかった。

このあたりでクリーンインストールがちらつき始めたため、長期戦を見据え空いているドライブにlinuxを入れることにした。
なお、この判断は間違いだったかもしれない。nvidiaのグラボをlinuxで使うことが大変なことを毎回忘れる。ここまでの倍ぐらいの時間がかかった。

linuxインストール

まずUSBメモリにlinux mintを入れて起動しtestdiskをもとにドライブの状態を確認したところ、当該ドライブは認識していた。一応パーティション内に再書き込みができるっぽいので書き込んでみたが変化がなかった。そのためwindows側のデータが破損したのではなくntfsのテーブルが破損したのだと考えられる。

つまり、データのサルベージはできそうだがwindowsの復旧は不可能。結局クリーンインストールは必要であると判断できる。ということでバックアップをしたいのだが、USBメモリからの起動だと解像度がひどく文字が横に潰れていた。このままで適切にファイルのサルベージができる気はしなかった。そのためインストールし、グラボの設定を開始したのだが、思わなくともこれが間違いだった。
nvidiaの公式ドライバ群をいくつか入れたのだが、起動すると壁紙で止まりうまく行かない。生成AI君に聞くとRe-Size BAR SupportをDisabledにするか、SecureBootを切れというが切ってもダメだった。

どうしようもなかったので、nvidiaのドライバをOSに同梱しているというPop! OSを使うことにし、これで成功した。一応バージョンを張っておく。

 1$ cat /etc/os-release
 2NAME="Pop!_OS"
 3VERSION="24.04 LTS"
 4ID=pop
 5ID_LIKE="ubuntu debian"
 6PRETTY_NAME="Pop!_OS 24.04 LTS"
 7VERSION_ID="24.04"
 8HOME_URL="[https://pop.system76.com](https://pop.system76.com/)"
 9SUPPORT_URL="[https://support.system76.com](https://support.system76.com/)"
10BUG_REPORT_URL="https://github.com/pop-os/pop/issues"
11PRIVACY_POLICY_URL="https://system76.com/privacy"
12VERSION_CODENAME=noble
13UBUNTU_CODENAME=noble
14LOGO=distributor-logo-pop-os

そうしてやっとサルベージ作業に入れると思いきや、Pop! OSはboot領域を別で確保しなくてはいけないという。sda4が昔windowsを入れていてデータドライブに変更した部分なのでここに入れたかったが、boot領域がない。ほとほと困り果てたため、データディスクの末尾(sdb3を減らしてsdb4を作る)をちょっと空けた。困ったときにインストールするOSではない気がする。
sdbの前半に置いていたubuntuを消さなければよかった。年始にパーティションを整理したんだよな。

 1NAME        FSTYPE FSVER LABEL
 2sda
 3├─sda1      ntfs         回復
 4├─sda2      vfat   FAT32
 5├─sda3
 6├─sda4      ext4   1.0
 7└─sda5      ntfs
 8sdb
 9├─sdb1
10├─sdb2      vfat   FAT32
11├─sdb3      ntfs         Volume_E
12└─sdb4      vfat   FAT32
13nvme0n1
14└─nvme0n1p1 ntfs

こうしてwindowsはnvme0n1にOSを入れてsdaにbootを入れる。Pop! OSはsdaにOSを入れているもsdbにbootを入れるというキメラ構成になった。やっぱりbootは整理しないといけない。よくわかった。というかなんかbootメニューにubuntu bootが残っているなと思っていたら、sdb2にboot領域が残ってるじゃん。今度消さなくては。

そうしてOSを取り戻した。やっぱlinuxは起動が早いな。

testdiskでのサルベージ

今の問題は推定ファイルシステムの破損でありハードウェアは正常であると想定している。そのためtestdiskでサルベージを試みる。このソフトは素晴らしく、フォルダ単位でサルベージ先をその構造を維持した状態で指定ができる。複数のフォルダの選択すらできる。

これは極めて偉大である。今回破損した領域に入れていたデータは1.2TBほどあるのだが、ある程度はサルベージ不要なデータ。ドライブごとコピーすると1TBでは足りない。2TBの領域が必要となるのだが、自宅のNASの空きは1TB。昔使っていた外付けも1TB。足りないのである。

しかし、偉大なるtestdiskは個別にサルベージできるためこの問題を回避できる。少しづつサルベージし圧縮すれば良いのだ。ありがたい。ほんとうにありがとうございます(いま姿勢を正した)。
おかげで、全コピーするためのデバイスを追加購入せずに済んだ。本稿執筆時点で、M.2SSDは2TBで3万ほど、HDDは拡張を考えると8TBにしたかったがこれも4万ほど、買い時でないことは間違いない。
この分は儲かったと考えて別のデバイス購入ではちょっと豪華な仕様にしてしまおうと思う。本当にありがたい

そうしてサルベージ作業にかかるが、書き込みに非常に時間がかかるため暇になり本記事を書いているという次第である。暇なので結構ちゃんと記録を残せたと思う。

寄付について

サルベージに成功したので、さすがに寄付ぐらいはせねばと思いCGSecurityより微力ながら送金させてもらおうとしたのだが、「この受取人への寄付は、この国ではサポートされていません」と出てPaypal君に止められてしまった。Bitcoinは大丈夫なのだろうが、手持ちがなく購入するためのアカウントを作るのはさすがに手間すぎる。申し訳ないがこの場における謝辞だけで許していただきたい。ありがとうございました。

一番いいのは誤字脱字的なfixややるだけだけど効果が薄いから後回しにしている機能・バグ対応に参加することだと思うが、OSSって大変なんだよな。特にtestdiskはgit管理こそしているが開発形態がよくわからん。お金で済ませたかった、どのように穿って見ても高評価になる概念だもん。

windowsの再インストール

特記事項は特にない。
ドライブ内に復旧領域もあったが、公式のツールを使いUSBメモリ経由で再インストールした。

CPU交換

サルベージ中、CPUの不具合の可能性に気が付きintelに問い合わせをした。流れとしては次のような感じだった。原文を張ってよいかわからないので主観により適当に要約している。

曜日 日付 内容
木曜 22時 ◇問い合わせ
biosの設定を振ったが落ちる
金曜 01時 ■回答
最新のbiosがあるから更新せよ
cpuとマザーボードの組み合わせを試したか
金曜 23時 ◇問い合わせ
biosは確かに古かった。しかしbiosを最新に上げるのはリスクがあるからあまりやりたくない。そもbios更新をすることを進めるのは壊れている可能性の切り分け?であれば交換してほしい。bios更新で様子を見てもよいが、問い合わせ時に設定を振っている。様子を見るにしてもどの条件を想定したのか。
土曜 01時 ■回答
現在、ご提供いただいた情報につきましては、社内にて慎重に確認を行っており、本件における最も適切かつ公正な対応を検討しておりますので、どうぞご安心ください。
火曜 17時 ■回答
トラブルシューティング手順より、プロセッサーが問題の根本原因であることが確認できた。標準保証交換(SWR)する。住所を提出して
水曜 22時 ◇問い合わせ
住所提出
木曜 19時 ■回答
標準保証交換(SWR)開始した。先にCPUを送って。
日曜 CPU送付
火曜 01時 CPU受領連絡
火曜 17時 CPU発送連絡
水曜 CPU到着

おそらく時差があるので日本時間の深夜に回答がある。当然だが土日は休みっぽい。

交換の総括

良かった点

  • 交換が速かった。ダウンタイムは3日ほど

良くなかった点

  • 壊れた
  • 返送時にグリスぐらいは付けて欲しかった。引っぱり出したら残っていたのでセーフだったが、CPUグリスを誰しも残しているとは思わないでほしい。
  • ブロークン対応までは分かる。全数交換が現実的に無理なのはしょうがない。しかし問い合わせがあった際に初手bios更新を進めるのは、無意味なリスクをユーザーに強いているようにしか思えない。
  • マイクロコードは0x12Bで終わりではなく、0x12Fまで出たらしい。そんなニュースを見た記憶がない。ブロークン対応をするにしても広報が不足している気がする(少なくとも0x12Bは存在を認知し更新していたのでアンテナが低すぎるというわけではないはず、たぶん)。
  • サポートでは当然のようにbiosの更新をしての検証を依頼されたがbios更新は普通に考えて一般ユーザーのやることではない。そしてbiosを更新しても壊れたものが治るわけではない。なぜ勧めているのであろうか。
  • 3回目の回答で「トラブルシューティングの手順より~」と言っている、トラブルシューティングの手順は問い合わせ開始時に提示している。つまりそれ以前は読まずに質問側がごねたからしっかり読んだか詳しい人に回したと受け取るのが自然に思う。つまりサポートに問い合わせる時点でごねるパワーが必要だが、問い合わせ後もごね力は保つ必要がある。大変である。まあ前提チェックもかねてひとまず突っ返すというのも分からなくはない。
  • SWR開始の際に「透明性のある形でご説明できたことを願っております。」と言われた。交換に応じた理由・原因の説明は皆無だった。透明性という概念が私とは違うのだと思う。ただパンピーに説明してもわからないのはその通りだとは思う。

その他

  • 日本語が微妙に変だったり、見えないスペースが入っていたり、同じ文章を2回続けていたので翻訳以外にも生成AIを使っていたのだろう。どこまで生成AIなのかはやや気になる(chatgptなどにカスタマーサポートとして回答を生成させると初手交換を認めるので、すぐに認めないようなカスタム指示が入っていることはありそう)。
  • つつがなく交換してはくれたが、やっぱ壊れたのはやや許せない。特にマイクロコードが気が付けなかった(自分のせいかもしれないけど他責にしておく)。次のcpu交換時、入手できる限りは別の会社にすることを固く誓う。別に他社が焼けないってことじゃないし、何なら焼いたことあるが直近被害という意味ではやはりマイナスイメージ。ちゃんと交換はしてくれたので次々回以降は選定する
comments powered by Disqus