カスタマーサポートがクラッシュの原因を突き止めた話 その2

この記事は[クラスター Advent Calendar 2021](https://qiita.com/advent-calendar/2021/cluster) 11日目の記事です。
昨日は @57_kokokona さんの「[好きなclusterイベント＆ワールドについて語るだけ](https://note.com/57_kokokona/n/n55da42c4d20a)」でした。これはガチ勢。

## はじめに

こんにちは、スワンマンです。クラスターでカスタマーサポートを担当してます。
[![スワンマンは乗り物](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58380/6b8e5a76-7f43-aa42-f460-26b328c625fd.png)](https://cluster.mu/w/304b9980-95f6-49e9-93c7-76f5b0d6cb72)
クラスターは[cluster](https://cluster.mu/)というメタバースプラットフォームを開発する会社でありつつ、それと同時にその上で開催されるバーチャルイベントの制作会社でもあります。去年は前者寄りの[cluster上で起きた不具合とそれに関わる問い合わせを自力で解決した話](https://qiita.com/Swanman/items/4d7fe581e807adfa5fae)を書きましたが、今回は後者のイベントを行う上で起きた問題を解決した話です。

## バーチャルイベントをどうやっているか

clusterではバーチャル空間上に会場を作り、そこにVRデバイスなどを用いて入ることでイベントを行っています。いくつかの専用機能はあるものの基本的にはユーザーが使うアプリケーションと同じものを使っているので、音声入力が被ってしまわないようにスタジオ内には物理的に切り離されたブースが複数あり、そこに置かれたPCから出演者が各々ログインする形です。
![スタジオの写真が手元にこれしかなかった](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58380/cdb29d19-67cc-44d4-5157-d331643f518a.png)

## そして問題が起きた

ある日、複数の出演者用PCがクラッシュしてしまうという問題が起きました。クラッシュ自体はそれまでも全く起きなかったわけではなかったのですが、その後も継続して起きるようになり、さすがに対策を取らないとマズいので原因を探ることに。
しかし当時のクラスターはスタジオ専任のスタッフもいなければ、エンジニアも数えるほどしかいない時代。問題の解決に担当者を割り当てるのが難しい状態でした。ということは、そう、カスタマーサポートの出番ですね。

## クラッシュの原因をどこから探るか

Windowsがクラッシュした時、青い背景に何だかよく分からない文字が羅列されている画面を見たことがあると思います。いわゆるブルースクリーンです。
![ブルースクリーン](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58380/ae695934-5a57-4ee9-8762-2e262ae3884f.jpeg)
最近ではQRコードが表示されてそのままドキュメントに飛べるなど昔よりはマシになっていますが、解決の手がかりとなる情報はエラーコードだけなのでそこから辿るのは難しい場合も多いです。
しかしWindowsはクラッシュする時に解析の足がかりとなる**クラッシュダンプ**をちゃんと残してくれています。

## クラッシュダンプとは

クラッシュダンプはWindowsがOSクラッシュ時の状態をファイルとして書き出してくれたものです。設定により、書き出される内容や書き出しの有無自体が変わったりもしますが、デフォルトで有効になっているので（設定を変えてなければ） `C:\Windows\MEMORY.DMP` に直近のダンプが毎回上書き保存されます[^1]。
内容としては、ブルースクリーンで表示されたエラーに付随するパラメータ値（この値を元にMSのドキュメントを見ると一発で原因が分かることもある）[^2]、クラッシュ時に実行されていたモジュール名、スタックトレースなど様々な情報が詰め込まれています。

## クラッシュダンプを見る

「クラッシュダンプが保存されていることは分かったけど、こいつの中身はどうやって見たらいいんだ…？」ということで、ここで登場するのが[WinDbgというMicrosoft謹製のデバッガ](https://docs.microsoft.com/ja-jp/windows-hardware/drivers/debugger/debugger-download-tools)[^3]です。WinDbgは基本的にはデバッガなのですが、ダンプファイルの解析機能も付いているのでこれに食わせることで上記の詳しい情報を見ることができます。
![クラッシュダンプを開いたところ](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58380/67af3150-3581-6c7b-f93f-e8f851de18b3.png)
早速開いてみると、ログの中に当時使用していたオーディオインターフェースのドライバ名が書かれていました。もしや…？と思い他のPCのダンプを見ても同じモジュール、同じアドレスで死んでいる。
**こ、こいつや…！** ということで、もう少し原因を探りたいところでしたが、死んでいる箇所が明らかだったのとちょうどオーディオインターフェースの入れ替え機運が高まっていたこともあり、全て粉砕して新しい機材に入れ替えることに。
結果として頻発していたブルースクリーンはそれ以降ピタッと止まり、安心してイベントを開催できるようになったのでした。めでたしめでたし。

## 最後に

今回のケースではクラッシュの原因を深く探ることはしなかったのですが、この程度の調査であればイベントビューアで済むこともあります。イベントビューアはWindowsにデフォルトでインストールされていて、OSやアプリケーションに関するログを確認できるツールです。
![これは昨日死んだ家のPC](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58380/11dc5691-121e-ebef-695a-ea6acab54883.png)
また、クラッシュダンプはWindowsの高速化なんかを取り扱ったサイトで「無効化すると軽くなる～」と書かれてたりもしますが、今回のようにこれが残っていることで救われる命もたくさんあります。オフにしている人は最低限の出力内容でいいのでオンにしておくと良いかもしれません。
Win+Pauseキーなどで `システム` を開き、`システムの詳細設定` から `起動と回復` へ進むと設定できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/58380/51155db8-1b09-ea0e-2c4d-b4445524cf18.png)

明日は色んなイベントの制作に関わってきている @MSA-i さんの「[Unityの作業効率を上げる系Editor ScriptのTips集](https://qiita.com/MSA-i/items/bf9da9a5c5ba00485da3)」です。どんな話になるのか楽しみですね。

[^1]: `C:\Windows\Minidump\` にも必要最低限の内容に絞ったログが残ってます（こちらは上書きされないので直近以外も残ってる）
[^2]: ちなみにこれはイベントビューアで見ることのできるログにも載ってます
[^3]: Microsoft StoreにWinDbg Previewというストアアプリもあってそっちの方が新しいです