Hyper-Vに環境を移行して以降はほんと安定した環境でした、多分。問題があるとすれば精々ゲストOSのWindows7をシャットダウンする前にホストOSからシャットダウン→Hyper-Vマネージメントによる終了を行うと、シャットダウン中にフリーズが発生する位の問題しかない程度、ですね。

と思っていたら、とある日(4日前)にVPN経由でSplashtopRemotePCに繋ごうとしても接続できない・・・、と思い、面倒ながらもadds→hostosの二重リモートデスクトップでアクセスするとゲストOSがBSoD(Blue Screen of Death)になっているではないかぁぁぁ・・・・・、あ、BSoD時はvmconnectで画面表示されるのですね。

bdos

見た感じ、RemoteFXの3Dグラフィックスドライバが落ちたみたいですね。(iPadから接続中)

  • エラーファイル … synth3dvsc.sys
  • ファイル内容 … Our database contains single file for filename synth3dvsc.sys. This file belongs to product Microsoft® Windows® Operating System and was developed by company Microsoft Corporation. This file has description Synthetic 3D SMT Support Driver. This file contains driver. You can find it in the Drivers section of the System Explorer. (systemexplorer.netより引用、vscanバナーが多いのでリンクは張りません)
  • エラーコード … SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (0x0000007e)
  • 引数1 … The exception code that was not handled (0xFFFFFFFFC0000005) = Memory Corruption
  • 引数2 … The address where the exception occurred
  • 引数3 … The address of the exception record
  • 引数4 … The address of the context record

正直、この情報からエラーなんてわかるわけないのですけどね。第一引数的にはメモリ破損エラーだと思われます、多分。そもそも、ホストOSからmstscでつないだ状態でそれを意識せずにSplashtopRemoteで繋いだりと、画面解像度もコロコロ変わる状況下で何かしらの違反が起きたとしても不思議ではないのですがっっ。

Windows＝BDoS的なイメージがある方もいるのかなと思っています(特にWindows95～Me, NT4.0～2000)が、私的な意見でいうと大抵の場合は”Microsoft悪くない！”という気がします。というのも、わんくまな同盟でもかつてセッションをやらせていただきましたが、BDoSが出る＝カーネルのBugCheck()関数によるOS保護が働いた、ことが起因です。で、自分が経験した中ではその半数近くは割と3rdパーティーのドライバ、取り分けグラフィックスドライバが原因である経験が強いな、と(ntoskrnlで落ちることが次いで多いですが)。となると、ある意味風評被害に近いような感じも受けます。MS信者からしてみれば（ぁ

というのを踏まえての疑問なのですが、最近では昔より格段にBSoDと遭遇する機会が減ったように思えます。となると、妄想できるのは

  • カーネルとしてのレベルが向上した
  • DDK(WDK)が改良された、サンプルが充実してきた
  • デバイスドライバの提供会社のノウハウが向上した
  • etc…

と様々なものが浮かぶのですが、実際のところどうなのでしょうね。精々趣味程度でクラスドライバを作る程度にはわらないところですね。

※ 因みに、クラスドライバを趣味で作る程度とはいってもBSoDのエラーコードはデバッグ時に非常にありがたいものです。

最後に、BSoDを見た瞬間に反射的にリセットボタンを押す人もチラホラ見られますが、私的にはエラーファイル名・エラーコード・第一引数程度はメモッた方がいいです。だってその3つがあれば大抵の場合は原因が見えますもの。

※ BSoD時に自動再起動かかる場合は[システムのプロパティ]→[詳細設定]タブ→[起動と回復]→[自動的に再起動する]のチェックを外しましょう