X79のブルースクリーン問題
IntelのCPUの主力がSandy BridgeからIvy Bridgeへと移ってきているが、Nehalem(訂正：Bloomfield)・LGA1366のi7-950にそこそこ満足していた私は、いずれにもさほど魅力を感じることなく過していた。しかし、Sandy Bridge-EのLGA2011には、特にenthusiastという訳でもないが、興味をそそられ、価格がこなれるのを待って昨秋、i7-3930Kを購入。これ以降当分は、PCを組むことはなかろうと思い、奮発した。
マザーボードは、ひいきのGIGABYTEからGA-X79-UD5を選んだ。この板は発売初期に発火したなどとして評判が芳しくなく、とりわけオーバークロックマニアには不評であったものの、定格で使用する分には大事ないと踏んで決めたのである。
Windows7 Professional SP1 x64をPLEXTOR 256M5Pにインストールし、UEFI BIOSを最新のバージョンF13ｐにした。チィップセットX79のドライバはIntel Rapid Storage Technology enterprise（IRSTeまたは単にRSTe）を使うことになっていたので、バージョン3.2を入れ、幾つかの基本的なソフトをインストールした。
ところが、PC起動後2～3時間経つと突如、例の怖ろしい名で呼ばれるブルースクリーン（Blue Screen of Death「死のブルースクリーン」：BSOD）に陥った。再起動後もしばらくすると再びブルースクリーンに。何も操作をしていないアイドル状態でも、2～3時間おきにブルースクリーン・再起動を繰り返すのである。
いったい何が原因なのか。
ブルースクリーン後直ぐに再起動しないように、「システム」⇒「システムの詳細設定」⇒「起動と回復」へと至り、「システムエラー」の「自動的に再起動する」のチェックを外しておいて、ブルースクリーンを見ると、"DRIVER_IRQL_NOT_LESS_OR_EQUAL"と表示されている。
また、イベントビューアーを覗くと、「このコンピューターはバグチェック後、再起動されました。バグチェック: 0x000000d1 (0x0000000000000000, 0x0000000000000002, 0x0000000000000000, 0xfffff880018ae0d2)。ダンプの保存先: C:\Windows\MEMORY.DMP。」とある。
そこで、アセンブリ言語などよく分かりもしないが、取り敢えずクラッシュ・ダンプ・ファイルをDebugging Tools for WindowsのWinDbg（Windows Debugger）で開いてみる（参照；msdnの「Windows 用デバッグ ツールのダウンロードとインストール」）。
解析結果は以下の通りである。
*******************************************************************************
Bugcheck Analysis
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck D1, {ffffffffffffffff, 2, 0, fffff880017240d2}
*** WARNING: Unable to verify timestamp for iaStorA.sys
*** ERROR: Module load completed but symbols could not be loaded for iaStorA.sys
Probably caused by : storport.sys ( storport!StorPortNotification+22 )
Followup: MachineOwner
---------
5: kd> !analyze -v
*******************************************************************************
Bugcheck Analysis
*******************************************************************************
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: ffffffffffffffff, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff880017240d2, address which referenced memory
Debugging Details:
------------------
READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80005d05100
ffffffffffffffff
CURRENT_IRQL: 2
FAULTING_IP:
storport!StorPortNotification+22
fffff880`017240d2 488b18 mov rbx,qword ptr [rax]
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0xD1
PROCESS_NAME: System
TRAP_FRAME: fffff880042cd8b0 -- (.trap 0xfffff880042cd8b0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=ffffffffffffffff rbx=0000000000000000 rcx=0000000000001003
rdx=fffffa801bcdc000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff880017240d2 rsp=fffff880042cda40 rbp=fffffa800d5825e0
r8=0000000000000002 r9=0000000000000000 r10=fffffa801bcdc000
r11=fffff880042cdab0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na po nc
storport!StorPortNotification+0x22:
fffff880`017240d2 488b18 mov rbx,qword ptr [rax] ds:ffffffff`ffffffff=????????????????
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff80005ad5569 to fffff80005ad5fc0
STACK_TEXT:
fffff880`042cd768 fffff800`05ad5569 : 00000000`0000000a ffffffff`ffffffff 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`042cd770 fffff800`05ad41e0 : 00000000`00000001 fffffa80`179bae00 fffffa80`18458440 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff880`042cd8b0 fffff880`017240d2 : fffffa80`0d5db943 fffff880`011014b6 00000000`00000202 fffffa80`0d5c2240 : nt!KiPageFault+0x260
fffff880`042cda40 fffff880`010ffe80 : fffffa80`0d52cb40 fffffa80`1bcdc000 00000000`00000002 00000000`00000000 : storport!StorPortNotification+0x22
fffff880`042cdac0 fffffa80`0d52cb40 : fffffa80`1bcdc000 00000000`00000002 00000000`00000000 fffff880`042cdb38 : iaStorA+0x63e80
fffff880`042cdac8 fffffa80`1bcdc000 : 00000000`00000002 00000000`00000000 fffff880`042cdb38 00000000`00000002 : 0xfffffa80`0d52cb40
fffff880`042cdad0 00000000`00000002 : 00000000`00000000 fffff880`042cdb38 00000000`00000002 00000000`00000000 : 0xfffffa80`1bcdc000
fffff880`042cdad8 00000000`00000000 : fffff880`042cdb38 00000000`00000002 00000000`00000000 fffff880`01106fc4 : 0x2
STACK_COMMAND: kb
FOLLOWUP_IP:
storport!StorPortNotification+22
fffff880`017240d2 488b18 mov rbx,qword ptr [rax]
SYMBOL_STACK_INDEX: 3
SYMBOL_NAME: storport!StorPortNotification+22
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: storport
IMAGE_NAME: storport.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4d79a55f
FAILURE_BUCKET_ID: X64_0xD1_storport!StorPortNotification+22
BUCKET_ID: X64_0xD1_storport!StorPortNotification+22
Followup: MachineOwner
---------（以下省略）---------
iaStorA.sysやstorport.sysが怪しいようなので、ウェブで検索をかけ、『Windows Internals Sixth Edition』(Microsoft)の「Crash Dump Analysis」等に目を通してみる。はっきりとした原因や改善方法は分からなかったが、どうもiaStorA.sysというIntelのチィップセット・ドライバ本体が悪さをしているらしい。
ともかく、RSTeのバージョンをv3.2からv3.5にアップしてみた。しかし、相変わらずBSODに落ちる。仕方なくGA-X79-UD5に付属するDVDに入っているv3.0にバージョンダウンすることにした。図らずも、BSODに陥ることはなくなった。
ウェブで調べ直してみると、GIGABYTEだけでなくASUS等のX79のM/Bでも同様の症状が発生しているようであり、M/BのUEFI BIOS、チィップセットX79、RSTeの間に何らかの不整合が横たわっており、使用環境如何、特に接続するSSDや光学ドライブによって不具合が生ずるようである。しかし、RSTeにおいて、それは容易に修正し難いもののようである。Intelさんもenterpriseの付かない従前からのIntel Rapid Storage Technology（IRSTまたは単にRST）のバージョン11.6.0.1030のRelease Notes（2012年9月12日）で「RST 11.6 is the first RST release to contain support for X79 platforms (HEDT).」と、RSTもX79で使用できるようにしたと発表したのである。このRSTにすれば、BSODは生じないということのようである。
ただし、X79にRSTを使用するためにはM/BのBIOSが対応していなければならないようである。残念ながら、2013年2月19日現在、X79-UD5はまだBIOSが対応しておらず、RSTは適用できないようである（私は無理に試していないが）。（※【訂正】：X79-UD5のBIOS、F13p（2012年11月16日）は、ダウンロードサイトで「Add iRST v11.6 with Smart Response support」と、RST v11.6のサポートを追加したと説明されていた。見落としていました。）
例えば、ASRrockのサイトでX79 Extreme6のBIOSのダウンロードページを見ると、バージョン1.90（2012年11月15日）では「Support Intel Rapid Storage RSTe and RST technology」と説明がなされているので、そのBIOSにバージョンアップすれば11.6以降のRSTがExtreme6では使えるようである。
結局のところ、X79のマザーボードにおけるブルースクリーン対処法は、BIOS（UEFI）がRSTに対応している場合には、v11.6以降のRSTを使うこと、RSTに対応していない場合には、RSTeのバージョンアップ又はバージョンダウンを試してみること、それで改善しなければ、RST及びRSTeを使わないこと（つまり、Windows標準のStandard AHCI 1.0 Serial ATA Controller又はIntel(R) C600/X79 series chipset 6-Port SATA AHCI Controller - 1D02を使うこと）、になろうか。
現状ではRSTeをインストールしないという選択をとる人も少なくないようである。IntelのSupport Communityにもこの問題を早く解決してほしいという要望が挙がっており、Intelさんも鋭意努力されているでしょうが、少し時間がかかり過ぎであることは否めない。RSTをX79に対応させたということは、RSTe本家の修正が難航している証左と考えられなくもない。
ともかく、Intelさんには頑張ってもらうほかない。
因みに、storport.sysについて『Windows Internals Sixth Edition』には、「新しいドライバの大部分はScsiport.sys（ほとんど使われなくなった古いポートドライバ；筆者注）の替わりに%SystemRoot%\System32\Drivers\Storport.sysのポートドライバを使用する。Storport.sysはハードウェアRAIDやファイバーチャンネルのアダプターの持つ高いパフォーマンス能力を活かすために設計されたものである。そのStorportのモデルはScsiportと類似したものであり、そのためベンダーが既存のScsiportのminiportドライバをStorportに移植することが容易となっている。開発者達がStorportを使用するように作成したminiportドライバは、Storportのパフォーマンスを高める機能のいくつかをうまく利用している。その機能には、マルチプロセッサ・システム上で入出力の開始と終了を平行して実行するためのサポートや入出力request-queueをさらにコントロール可能にするアーキテクチャのためのサポート、ハードウェアの割り込みを遮断する時間を最小限に抑えるように下位のIRQLのコードをさらに多く実行するためのサポートが含まれている。」（p.132, Part2）と解説されている。
なお、GA-X79-UD5には、その母板固有の不具合もあるようで、後日取り上げることにする。
マザーボードは、ひいきのGIGABYTEからGA-X79-UD5を選んだ。この板は発売初期に発火したなどとして評判が芳しくなく、とりわけオーバークロックマニアには不評であったものの、定格で使用する分には大事ないと踏んで決めたのである。
Windows7 Professional SP1 x64をPLEXTOR 256M5Pにインストールし、UEFI BIOSを最新のバージョンF13ｐにした。チィップセットX79のドライバはIntel Rapid Storage Technology enterprise（IRSTeまたは単にRSTe）を使うことになっていたので、バージョン3.2を入れ、幾つかの基本的なソフトをインストールした。
ところが、PC起動後2～3時間経つと突如、例の怖ろしい名で呼ばれるブルースクリーン（Blue Screen of Death「死のブルースクリーン」：BSOD）に陥った。再起動後もしばらくすると再びブルースクリーンに。何も操作をしていないアイドル状態でも、2～3時間おきにブルースクリーン・再起動を繰り返すのである。
いったい何が原因なのか。
ブルースクリーン後直ぐに再起動しないように、「システム」⇒「システムの詳細設定」⇒「起動と回復」へと至り、「システムエラー」の「自動的に再起動する」のチェックを外しておいて、ブルースクリーンを見ると、"DRIVER_IRQL_NOT_LESS_OR_EQUAL"と表示されている。
また、イベントビューアーを覗くと、「このコンピューターはバグチェック後、再起動されました。バグチェック: 0x000000d1 (0x0000000000000000, 0x0000000000000002, 0x0000000000000000, 0xfffff880018ae0d2)。ダンプの保存先: C:\Windows\MEMORY.DMP。」とある。
そこで、アセンブリ言語などよく分かりもしないが、取り敢えずクラッシュ・ダンプ・ファイルをDebugging Tools for WindowsのWinDbg（Windows Debugger）で開いてみる（参照；msdnの「Windows 用デバッグ ツールのダウンロードとインストール」）。
解析結果は以下の通りである。
*******************************************************************************
Bugcheck Analysis
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck D1, {ffffffffffffffff, 2, 0, fffff880017240d2}
*** WARNING: Unable to verify timestamp for iaStorA.sys
*** ERROR: Module load completed but symbols could not be loaded for iaStorA.sys
Probably caused by : storport.sys ( storport!StorPortNotification+22 )
Followup: MachineOwner
---------
5: kd> !analyze -v
*******************************************************************************
Bugcheck Analysis
*******************************************************************************
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: ffffffffffffffff, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
Arg4: fffff880017240d2, address which referenced memory
Debugging Details:
------------------
READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80005d05100
ffffffffffffffff
CURRENT_IRQL: 2
FAULTING_IP:
storport!StorPortNotification+22
fffff880`017240d2 488b18 mov rbx,qword ptr [rax]
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0xD1
PROCESS_NAME: System
TRAP_FRAME: fffff880042cd8b0 -- (.trap 0xfffff880042cd8b0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=ffffffffffffffff rbx=0000000000000000 rcx=0000000000001003
rdx=fffffa801bcdc000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff880017240d2 rsp=fffff880042cda40 rbp=fffffa800d5825e0
r8=0000000000000002 r9=0000000000000000 r10=fffffa801bcdc000
r11=fffff880042cdab0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz na po nc
storport!StorPortNotification+0x22:
fffff880`017240d2 488b18 mov rbx,qword ptr [rax] ds:ffffffff`ffffffff=????????????????
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff80005ad5569 to fffff80005ad5fc0
STACK_TEXT:
fffff880`042cd768 fffff800`05ad5569 : 00000000`0000000a ffffffff`ffffffff 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`042cd770 fffff800`05ad41e0 : 00000000`00000001 fffffa80`179bae00 fffffa80`18458440 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff880`042cd8b0 fffff880`017240d2 : fffffa80`0d5db943 fffff880`011014b6 00000000`00000202 fffffa80`0d5c2240 : nt!KiPageFault+0x260
fffff880`042cda40 fffff880`010ffe80 : fffffa80`0d52cb40 fffffa80`1bcdc000 00000000`00000002 00000000`00000000 : storport!StorPortNotification+0x22
fffff880`042cdac0 fffffa80`0d52cb40 : fffffa80`1bcdc000 00000000`00000002 00000000`00000000 fffff880`042cdb38 : iaStorA+0x63e80
fffff880`042cdac8 fffffa80`1bcdc000 : 00000000`00000002 00000000`00000000 fffff880`042cdb38 00000000`00000002 : 0xfffffa80`0d52cb40
fffff880`042cdad0 00000000`00000002 : 00000000`00000000 fffff880`042cdb38 00000000`00000002 00000000`00000000 : 0xfffffa80`1bcdc000
fffff880`042cdad8 00000000`00000000 : fffff880`042cdb38 00000000`00000002 00000000`00000000 fffff880`01106fc4 : 0x2
STACK_COMMAND: kb
FOLLOWUP_IP:
storport!StorPortNotification+22
fffff880`017240d2 488b18 mov rbx,qword ptr [rax]
SYMBOL_STACK_INDEX: 3
SYMBOL_NAME: storport!StorPortNotification+22
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: storport
IMAGE_NAME: storport.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4d79a55f
FAILURE_BUCKET_ID: X64_0xD1_storport!StorPortNotification+22
BUCKET_ID: X64_0xD1_storport!StorPortNotification+22
Followup: MachineOwner
---------（以下省略）---------
iaStorA.sysやstorport.sysが怪しいようなので、ウェブで検索をかけ、『Windows Internals Sixth Edition』(Microsoft)の「Crash Dump Analysis」等に目を通してみる。はっきりとした原因や改善方法は分からなかったが、どうもiaStorA.sysというIntelのチィップセット・ドライバ本体が悪さをしているらしい。
ともかく、RSTeのバージョンをv3.2からv3.5にアップしてみた。しかし、相変わらずBSODに落ちる。仕方なくGA-X79-UD5に付属するDVDに入っているv3.0にバージョンダウンすることにした。図らずも、BSODに陥ることはなくなった。
ウェブで調べ直してみると、GIGABYTEだけでなくASUS等のX79のM/Bでも同様の症状が発生しているようであり、M/BのUEFI BIOS、チィップセットX79、RSTeの間に何らかの不整合が横たわっており、使用環境如何、特に接続するSSDや光学ドライブによって不具合が生ずるようである。しかし、RSTeにおいて、それは容易に修正し難いもののようである。Intelさんもenterpriseの付かない従前からのIntel Rapid Storage Technology（IRSTまたは単にRST）のバージョン11.6.0.1030のRelease Notes（2012年9月12日）で「RST 11.6 is the first RST release to contain support for X79 platforms (HEDT).」と、RSTもX79で使用できるようにしたと発表したのである。このRSTにすれば、BSODは生じないということのようである。
ただし、X79にRSTを使用するためにはM/BのBIOSが対応していなければならないようである。
例えば、ASRrockのサイトでX79 Extreme6のBIOSのダウンロードページを見ると、バージョン1.90（2012年11月15日）では「Support Intel Rapid Storage RSTe and RST technology」と説明がなされているので、そのBIOSにバージョンアップすれば11.6以降のRSTがExtreme6では使えるようである。
【追記】：X79-UD5でも11.6のRSTが使えるのであるから、取り敢えず、RSTeと入れ替えることにした。その場合、注意しなければならないことは、RSTeをアンインストールする前に、BIOSでSATA Controller ModeをAHCIからIDEに変更しておくことである。そうしなければ、RSTeを完全に削除することはできない。RSTeを削除した後、IDEをAHCIに戻して、RSTをインストールする。その後、なぜかWindowsのライセンス認証が再び求められた。これには納得がいかなかったが、再認証が必要とされれば、そうするしかない。
また、RSTeでRAIDを組んでOSを入れている場合には、RSTeだけをアンインストールすることはできないので、一旦RAIDを解除して、再度OSをインストールするしかない。その際、RSTのF6ドライバを読み込んでRAIDを構成し直すことになる。
詳細は、Program Files(x86)\Intel\ja-JPフォルダ内のremovdrv.txtを御覧下さい。
また、RSTeでRAIDを組んでOSを入れている場合には、RSTeだけをアンインストールすることはできないので、一旦RAIDを解除して、再度OSをインストールするしかない。その際、RSTのF6ドライバを読み込んでRAIDを構成し直すことになる。
詳細は、Program Files(x86)\Intel\ja-JPフォルダ内のremovdrv.txtを御覧下さい。
結局のところ、X79のマザーボードにおけるブルースクリーン対処法は、BIOS（UEFI）がRSTに対応している場合には、v11.6以降のRSTを使うこと、RSTに対応していない場合には、RSTeのバージョンアップ又はバージョンダウンを試してみること、それで改善しなければ、RST及びRSTeを使わないこと（つまり、Windows標準のStandard AHCI 1.0 Serial ATA Controller又はIntel(R) C600/X79 series chipset 6-Port SATA AHCI Controller - 1D02を使うこと）、になろうか。
現状ではRSTeをインストールしないという選択をとる人も少なくないようである。IntelのSupport Communityにもこの問題を早く解決してほしいという要望が挙がっており、Intelさんも鋭意努力されているでしょうが、少し時間がかかり過ぎであることは否めない。RSTをX79に対応させたということは、RSTe本家の修正が難航している証左と考えられなくもない。
ともかく、Intelさんには頑張ってもらうほかない。
【追記】：IntelはSupport Communityにおいて、X79のプラットフォームでRSTeをインストールした環境でブルースクリーンに悩まされている投稿者に対して、RSTの最新バージョン11.7を使うように勧めている（2013年3月19日、"Intel RSTe drivers causing BSODs; stuck in RAID mode; Intel SSD optmizer not available, S.M.A.R.T. values neither"）。RSTeのこの問題に係る改善は、当分望めそうもないようである。
因みに、storport.sysについて『Windows Internals Sixth Edition』には、「新しいドライバの大部分はScsiport.sys（ほとんど使われなくなった古いポートドライバ；筆者注）の替わりに%SystemRoot%\System32\Drivers\Storport.sysのポートドライバを使用する。Storport.sysはハードウェアRAIDやファイバーチャンネルのアダプターの持つ高いパフォーマンス能力を活かすために設計されたものである。そのStorportのモデルはScsiportと類似したものであり、そのためベンダーが既存のScsiportのminiportドライバをStorportに移植することが容易となっている。開発者達がStorportを使用するように作成したminiportドライバは、Storportのパフォーマンスを高める機能のいくつかをうまく利用している。その機能には、マルチプロセッサ・システム上で入出力の開始と終了を平行して実行するためのサポートや入出力request-queueをさらにコントロール可能にするアーキテクチャのためのサポート、ハードウェアの割り込みを遮断する時間を最小限に抑えるように下位のIRQLのコードをさらに多く実行するためのサポートが含まれている。」（p.132, Part2）と解説されている。
なお、GA-X79-UD5には、その母板固有の不具合もあるようで、後日取り上げることにする。
【追記】：その後、GA-X79-UD5をしばらく使ってみたが、取り立てて不具合には遭遇しなかった。にもかかわらず、X79 Extreme6に交換してみることにした。そのあたりの事情は「X79のマザーボード交換」を御覧下さい。
【追記】：さらに、RST 11.7にはASMedia又はMarvellのSATAポートとの関係で問題があり、それについては「IRSTとASMedia･Marvell問題」を御覧下さい。
