ハクソク

世界を動かす技術を、日本語で。

私のSnapdragon開発キットは正常に動作していましたが、Windowsのアップデートが失敗してしまいました。

概要

  • Snapdragon Dev Kitを約1年間日常利用した体験談
  • Windows 11のセキュリティアップデート失敗による致命的トラブル発生
  • 再インストールや復旧策も無効となり、完全起動不能状態に
  • ファームウェアリカバリ手段やサポート不在が致命傷に
  • Snapdragonプラットフォーム自体への信頼は維持

Snapdragon Dev Kit:1年使用レビューと突然の終焉

  • 2024年10月、Snapdragon Dev Kit(Qualcomm Snapdragon X Elite ARM64 CPU搭載、32GB RAM、512GB SSD)を入手
  • Windows 11 for ARMが非常に高速で動作、以降日常利用PCとして活用
  • 1年間の利用で安定性・信頼性に優れ、不具合やエラーは皆無
  • ファンの騒音はあるが、ヘッドホン利用で気にならず
  • Windowsアップデート(KB5068861)が12月にインストール失敗、ロールバックを繰り返す
    • キャッシュクリアやsfc /scannowdismコマンド、手動インストールも効果なし
    • 同様の問題が多数報告され、Microsoftの今後の修正待ちに
  • アップデート再開後、再起動時に同じ失敗とロールバックが発生
    • 今回はロールバックも正常動作せず、4回再起動後ようやくWindows起動
    • Microsoftアカウントにサインイン不可、PINで新規プロファイルにログイン
    • Windows Terminalや多くのMicrosoftアプリが起動不可

復旧作業と絶望的な状況

  • 再起動後、Windowsロゴ表示後に自動再起動やシャットダウンを繰り返す
  • UEFIのBDSメニュー(Homeキー)にも断続的にアクセス可能
    • メニューのフリーズや選択不能など不安定挙動
    • キーボードやUSBポート変更も効果なし
    • 何度も試行の末、BDSメニューでSecure Boot無効化・USB優先起動・外部ディスプレイ利用を設定
  • Windows 11 ARM ISOをUSBに書き込み、Snapdragon Dev Kit用ドライバも別USBに準備
  • Windowsインストーラー起動・Cドライブ上書きインストールは一度は成功
    • ネットワーク用ドライバ選択画面でフリーズ&シャットダウン
  • 以降はSnapdragonロゴから先に進まず、再起動や電源断を繰り返す
  • BDSメニューには入れるが全オプションが選択不可、再インストールやLinux起動も不可能
  • 本体を開けてSSD再装着・他PCでの動作確認も問題なし

原因考察とSnapdragon Dev Kitの限界

  • Windowsアップデート失敗が直接の引き金
    • ファームウェアやUEFI、ブートローダの一部が破損した可能性
    • Secure BootやTPM状態の不整合、電源管理ファームウェアの問題も疑念
  • ドキュメント化されたファームウェア復旧手段が未提供のため、通常なら復旧可能な障害も致命傷に
  • QualcommによるSnapdragon Dev Kitのサポート終了が状況を悪化
    • ASUS、Dell、LenovoなどOEM製品なら復旧ツールやサポートが存在
  • Snapdragonプラットフォーム自体には不信感なし
    • Snapdragon X EliteとWindows 11の組み合わせは1年間安定動作
    • 高性能・信頼性に満足、Core i9機を凌駕
  • 唯一無二の32GB ARMマシンを失った喪失感

Snapdragon Dev Kitのサポートと今後への提言

  • Qualcommがファームウェアリカバリツールを今後提供するなら、再挑戦を希望
  • 開発者向けハードウェアには最低限の復旧手段やサポートの必要性
  • 一般向けSnapdragon PCでは同様のトラブルでも復旧可能性が高い

RIP, Snapdragon Dev Kit

Hackerたちの意見

あなたが悪いわけじゃないけど、コンピュータが壊れた直後にシステムアップデートをインストールするのはちょっと躊躇しちゃうな。特にMicrosoftが関わってるときはね。
それか、ソフトウェアもハードウェアもサポートがないEOLの実験用デバイスだね。Windows Updateは完全に無効にして、コンピュータがすでに侵害されているかのように振る舞って、セキュリティが問題にならない作業だけをするのが一番「信頼できる」方法だと思う。もちろん、後から考えればなんとやらだけど…。
ブートセレクターで予測できない動作があって、ランダムにフリーズしてたなら、ハードウェアのどれか(RAMかな?)がダメになったんじゃないかな。ファームウェアの破損だったら、メニューが表示されなかったり、全く起動しなかったりするはずだし。Microsoftのコード品質が今あまり良くないのは確かだけど、たぶんハードウェアの故障なのに彼らを責めるのはあまり生産的じゃないと思うよ。
Windowsのアップデートインストールが失敗したときに起こった「ハードウェア故障」とは関係ないの?それって一億分の一の偶然みたいだね。
そうだね、同意するよ。これはただの反マイクロソフトのクリックを狙った記事に感じる。記事から: 「再起動するか、電源が切れる前にSnapdragonのブートロゴを通過しない…また、ランダムに見える。ブートプロセスの異なるポイントでのランダムなフリーズは、ハードウェアの故障を示唆してるね。ソフトウェアのブートチェーンが壊れてるわけじゃない。」
CPUクーラーをテストしてみるべきだね。ファンがすごく回ってたから。ログイン画面周辺で温度が上がって、その後ずっと熱いままで、再起動が予測できなくなる。最近、Windowsのアップデート中に水冷ポンプが壊れたことがあったんだ。ポンプがダメになってたけど、制限なしのアップデートがモンスターCPUで詰まってしまったのが原因だった。
元のArduino Dueには、MCU(Atmel Cortex-M3)に関する面白い未文書化の動作があって、10kオームの抵抗を取り付けないとランダムなことが起きてた。フラッシュやROMからランダムにブートすることから、クロックが正しく立ち上がらないことまで。SWDインターフェース経由でフラッシュしようとするまでは、ちゃんとブートしてたのに。抵抗をハンダ付けしたら、ほぼ解決したよ。
記事に載ってるアップデートには、"ハンドヘルドデバイス"向けの2つのUEFIパッチが含まれてる。これが特定のARMデバイスのUEFIを壊すのは全く驚きじゃないね、ファームウェアの破損から。
何かが完璧に動いてたのに、アップデート後に不具合が出ると(ユーザーの操作はなしで)、そのアップデートがハードウェアに問題を引き起こした可能性があるよね。例えば、SSDのフラッシュの使いすぎ(もう報告されてるしね)とか、コンポーネントを何度も再フラッシュすること(スクリプトの単純なエラー)。
うーん、あんまり確信が持てないな。W10のPCで似たような問題があったから。ドライバーのレースコンディションが原因かもってぼんやり疑ってる。esp32のフラッシングドライバーに特に注目してるんだ。時々は普通にブートするけど、時々はスピニングダイヤルが消えて黒い画面で止まったり、スピニングダイヤル中にフリーズしたり、たまにDPCウォッチドッグ違反でブルースクリーンになることもある。奇妙なことに、セーフモードでも起こることがある。ハードウェアの問題かと思ったけど、RAMは交換済みで、ブート後は問題なし。CPUとGPUを同時にフル稼働させても問題ないし。
そうだね、(たぶん)彼らはやってないと思う。ほぼ確実にソフトウェアのハードウェア故障、たぶんSSDだね。似たような状況に遭遇したことがあるけど、原因はWindowsじゃなくてLinuxだった。数ヶ月間そのマシンをクローゼットに放り込んでたら、奇跡的にまた動き出したんだ。でも1日半後にまた壊れたけどね。ディスクかRAMの破損だよ。もう諦めなよ、ハードウェアのせいだから。でもMicrosoftを叩くチャンスは逃さないでね。
問題が始まったときに、多くの人が似たような問題を抱えてたから、ハードウェアの故障だったとは考えにくいね。
記事から: 「システムを開けて、SSDを含めてすべてを再接続したけど、変わらなかった。SSDを別のマシンでテストしてみたけど、そっちは問題なし。ただ、これが悪いRAMやSSDコントローラーのせいじゃないとは限らないし、何が原因かは分からない…とにかく、こういうボックスは数少ないから、デバッグできる可能性は低いね :(」
フリートデプロイメントで出会ったx86マシンの数を考えると、Windows Updateでブリック状態になったのが多かったから、悪いアップデートのロールバックシーケンスが原因でも全然驚かないよ。ノートパソコンは特に、マイクロソフトのアップデートロールバックプロセスの魔法に弱いみたいだけど、どのデバイスクラスでもランダムに起こるみたい。よくある「System32のランダムなファイルが壊れる」っていうのは、クリーンインストールで簡単に直せるけど、BIOSアップデートのロールバックがロールバックマネージャーによって中断されて、ハードブリックになったケースもあった。外部プログラマーとクリップ(または手でハンダ付け)でクリーンなBIOSイメージをフラッシュしないと復旧できなかったけど、その後は問題なく動いたよ。マイクロソフトに対する無条件の批判は正当だけど、彼らも完璧じゃないし、最近は特に信頼性が低下してる気がする。
>ほぼ確実にソフトウェアのハードウェア故障、たぶんSSDだね。記事をちゃんと読んでたら、そうじゃないってわかるはず。ちなみに、WindowsのアップデートはファームウェアやBIOSのアップデートも届けることがあるよ。
これはWindowsの問題じゃないと思うよ。RAMスティックを交換した方がいい。古いIntel NUCで似たような謎の問題があったけど、Amazonで新しいスティックを買ったら、その後は問題が出なかったよ。
残念ながら、これはArmのQualcomm Snapdragonボックスの一つなんだよね。見た限り、交換可能なRAMスティックを提供してるものはないよ。
これらのデバイスは悪夢だね。いつかは報われると思うけど、これはまるで何年も前にみんながLinuxでNvidiaを罵って、AMDのオープンソースへの献身を称賛してた時のようだ。私のコンピュータは、Nvidiaに切り替えるまでずっとロックアップし続けた。みんなが言ってたサポートが一番良いっていうのと、実際の体験との間に大きなギャップがあったよ。同じように、QualcommのLinuxへの新たな関心についてもよく聞くけど、実際にはそんなことはなかった。10年くらい前に彼らの開発キットで学校のプロジェクトをやろうとしたけど、ドキュメントがすごく少なかった。今、Snapdragon X EliteがIdeacentreの製品に入ってるのを見たけど、オンラインで調べても、LinuxがMac M2のようにうまく動いてるところは見つからなかった。それが私にとっての基準だよ。もしMacがあなたがリリースしたチップセットよりもLinuxをうまく動かせるなら、そのハードウェアは買う価値がないってことだよ。Appleじゃないなら、Linuxをサポートしなきゃダメだよ。そうじゃないと、ネット用語を借りると「本気じゃない」ってことになる。
これは不良RAMの可能性があるかもね。Memtest86はUEFIから直接ブートできるから、BDSに表示されるといいな。実行すれば、どのRAMの領域がダメか分かるはずだよ。
これはハードウェアの故障の可能性が高いから追加しておくけど、数年前にアフターマーケットのエンジンECUで似たような問題をデバッグするのが大変だったんだ。面白いエピソードになるかなと思って。車は一度始動すると問題なく走るけど、時々始動しないことがあった(かなり改造してたから、システムには詳しかった)。スターターはリレーが簡単だから回るけど、ECU制御のデバイスは全く反応しなかった。ECUに接続してもエラーコードは出ず、すべて正常に見えた。最終的に、特定の状況でしか読み込まれないROMの破損が原因だとわかった。ECUは圧力や温度に基づいてエンジンパラメータのマップを保存してるから、特定の状況でしか壊れたテーブルの部分に当たらなかった。ROMを再フラッシュしたら、その後は問題なし。破損の原因と疑われたのは、以前修理した不安定な電源供給だった。
最近、Ubuntuが私のNVidia Jetsonを今後もサポートしてくれることを知って嬉しかったよ。NVidiaの公式サポート期間が終わった後もね。https://canonical.com/blog/ubuntu-now-officially-supports-nv... だから、長期的なLinuxサポートのあるARM開発キットが少なくとも一つあるってことだね。
Jetsonってほんとにわかりづらい製品だよね。何をサポートしてるのか全然わからない。画像のダウンロードページを見ると、オリンとそれ以降のモデルだけみたい? https://ubuntu.com/download/nvidia-jetson
数十年の経験から、私の普通のやり方は、全ディスクの定期的なマルチジェネレーションバックアップを取ること(通常は圧縮してね)。こんなことが起こったとき、最後の良好なイメージに戻れるから、すごく時間と手間が省けるよ。
あなたが持ってるSnapdragon Kitは、既知の問題で即座にリコールされたよ。どこかで数百台しか出荷されなかったって読んだ。私もそのラッキーな一人なんだ。もし私があなたなら、Lenovoのarm64デスクトップを一台買って、持ってるのは遺物として保存するかな。