【備忘】：KP41エラーが出たときの対策
KP41エラーが出て困っている人がいるという噂を聞いたので、昔どこかの掲示板のためにつくったテンプレと合わせて備忘メモ。
まず、世の中で言われているような『KP41病』などと言うものはないので注意。一般的な対策としてメモリの電圧を盛るとか、PCの電源を交換するとか言われているが、いずれも結局おまじないでしかない。
何故か、あたかも「KP41と言う原因不明のエラーを吐いて止まる事象がある」と誤解されているが、「KP41と言うのは前回のOSシャットダウン時に正常な手順で完了できなかった」と言うのが正しく(と言うか、イベントビューアのKP41の詳細にはこう書いてあるよね？)、言い換えると「KP41は前回、BSoD(Blue Screen of Dead、つまり青画面)等エラーを吐いてOSが止まった」ことを示しているに過ぎない。ので、大事なのは「KP41」と言う事象にとらわれるのではなく、「BSoDの原因が何なのか？」と言うことなのである。
と言うことで、問題解決の正しい手順は(1). BSoDが発生した原因を調査する、(2). 原因に対して対策を行う、である。で、困るのがBSoDの原因の調査方法になる。
一番確実なのは青画面が出てる真っ最中にSTOPコードが表示されているのでそのコードをメモしておくことなのだけど、まあ普通の人は青画面が出ると焦ってしまうし、青画面のメッセージは英語のメッセージなので混乱して、正しくSTOPコードを記録しておくことができない。
だけど焦ることはない。過去のBSoDメッセージはメモリダンプと言う形でOSの中に保存されているので(エラー状態の中なので、稀に保存されない場合もあるが)その過去のメモリダンプを解析してBSoDのSTOPコードを調べればよい。『メモリダンプの解析』とか言うと、16進のバイナリを解読しなきゃいけないのかと焦ってしまうかもしれないが、そんな心配はないのでご安心。Windows純正でメモリダンプを解析してくれる『Debugging Tools for Windows』と言うアプリが配布されているので、手順に従ってアプリをパソコンにインストールし、メッセージを冷静に読み取ればいい。
Debugging Tools for Windowsのインストール、およびSTOPコードの出し方に関しては、以下に非常に丁寧にインストール方法が書かれているので省略。
実際には、Debugging Tools for WindowsのうちWinDbg.exe(32bit版か64bit版、自分のPCに合わせて選択しましょう)をインストールすればよい。
と言うことで手順を軽く抜粋していくと、
(1). Microsoftが無償公開しているDebugging Tools for Windowsをインストールする。
(2). フォルダc:\websymbolsを作る。
(3). WinDbg.exeを起動する。
(4). メニューの[File ]-[Symbol File Path]を選ぶ。
(5). 入力欄に下記の文字列を書いてOKを押す。
SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
(6). 調査したいダンプファイルをWinDbgのウインドウにドラッグ＆ドロップする。
(7). !analyze -vコマンドを実行する。
(8). ウインドウに表示された内容から、原因を究明する。
(9). まずはバグチェック文字列（STOP CODE、BUGCHECK_STR:などとも）と呼ばれる文字列を探す。
0x00000nnn とか0xnnnと書かれてる文字列(16進数の数字)になるので、その文字列と同じ数字を以下のページで探す。
STOPエラー （全てのコード ： 2015年版）
(10). または、ダンプファイルから原因のドライバー（IMAGE_NAME:）を探してもよい。これはBSODを引き起こしたアプリないしドライバになる。
よく見る症例としては、nvlddmkm.sysなどnvで始まる文字列の時はビデオドライバ(nVidia)が原因。
また、atapi.sysだったら繋いでるSSDやHDDの異常になる。などなど、その他の場合も地道にドライバ名を検索して同じ症例を探せばよい。
(11). 上記の手順を踏んでもまだ解決しない場合、初めて「おまじない」の登場になる。
・特定の操作（特定のアプリを起動）を行った際限定でBSODになるなら
→ドライバ含むソフトウェア要因の可能性が高いのでBSODが発生し出した前後のシステム変更を見直し、
心当たりがあればその対処（アプリやドライバのアンインストール、アップデート）を行う
・BSODの発生に一意性がなく「不定期に」固まったり落ちたりする
→ハードウェアの故障や相性の可能性が高いので、メモリやCPUの電圧を盛っていればそれを解除（OCなども）。
メモリを複数枚搭載している場合は1本だけにして問題なければ2本、3本と徐々に追加して切り分けを行う。
・その他、地道に丹念に調べる時の目安
→メモリを疑うなら、とりあえずMemtest86+を回す
複数本メモリを差してるなら、一本ずつ差して様子を見たり、差す場所を交換したりしてみよう
→ビデオカードを疑う時は、まずドライバのバージョンを変えよう
ビデオドライバだけでなく、Flashのバージョン、ブラウザのバージョンも変えてみよう
最新のバージョンだけでなく古いドライバも試してみよう
古いドライバがうまく消えない時もあるので、ビデオドライバの完全アンインストールできるツールを試すのもよい
→HDDやSSDを疑う時は、chkdskを実行しよう（ただしデータ消失のリスクがあるのでバックアップを優先しよう）
CrystalDiskInfo等でS.M.A.R.T.情報の代替不能セクタ等も調べた方がいい
→USBなどで付けている周辺機器が悪いと言うこともよくあるので、気付いた周辺機器は外そう
特に最近新しい機器をつけた思い当たりがあるなら、それは絶対はずした方がいい
→夏場になって異常が増えたなら熱暴走を疑おう(PCの中身あけて特にファン周りを重点的に掃除しよう)
→その他、インストールされているアプリが原因の場合も稀にだがある
アンチウイルスソフトの障害でBSODをはくことがあるので、セキュリティ板で情報収集をしよう
Windows Update由来でBSODをはくこともあるので、この板のWindowsUpdateスレの情報もチェック
・どこかのハードが壊れかけ、電源の壊れかけ、電源容量不足などの場合
→PCのログからはもはや推測できない場合がある、これはもう地道に部品交換していくしかない
などなどの手順を踏んでいくことになる。
試しに、僕のPCでWinDbgを実行し、残っているBSoDメッセージを開いてみたら、以下のようなものがあった。メモリダンプの日付は去年の11月になっていた。
<code>
Microsoft (R) Windows Debugger Version 6.2.9200.20512 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Windows\Minidump\110314-9204-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*c:\windows\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.18526.amd64fre.win7sp1_gdr.140706-1506
Machine Name:
Kernel base = 0xfffff800`03463000 PsLoadedModuleList = 0xfffff800`036a6890
Debug session time: Mon Nov 3 04:26:34.787 2014 (UTC + 9:00)
System Uptime: 3 days 17:12:42.914
Loading Kernel Symbols
...............................................................
................................................................
............................
Loading User Symbols
Loading unloaded module list
.......
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck A, {fffffa8830b957a8, 2, 0, fffff800035551db}
Probably caused by : tcpip.sys ( tcpip!TcpTcbKeepAliveSend+320 )
Followup: MachineOwner
---------
2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: fffffa8830b957a8, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000000, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4: fffff800035551db, address which referenced memory
Debugging Details:
------------------
READ_ADDRESS: GetPointerFromAddress: unable to read from fffff80003710100
GetUlongFromAddress: unable to read from fffff800037101c0
fffffa8830b957a8 Nonpaged pool
CURRENT_IRQL: 2
FAULTING_IP:
nt! ?? ::FNODOBFM::`string'+433d3
fffff800`035551db 488b4128 mov rax,qword ptr [rcx+28h]
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT
BUGCHECK_STR: 0xA
PROCESS_NAME: System
TAG_NOT_DEFINED_c000000f: FFFFF88003994FB0
TRAP_FRAME: fffff8800398cfd0 -- (.trap 0xfffff8800398cfd0)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=000000000000ffff rbx=0000000000000000 rcx=000000000000cfec
rdx=fffffa802bdd1cf0 rsi=0000000000000000 rdi=0000000000000000
rip=fffff88001730f80 rsp=fffff8800398d160 rbp=fffffa802c7a1530
r8=0000000000000001 r9=0000000000000001 r10=0000000000003f8c
r11=fffff880082e5448 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei ng nz ac po cy
tcpip!TcpTcbKeepAliveSend+0x320:
fffff880`01730f80 6641890b mov word ptr [r11],cx ds:fffff880`082e5448=????
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff800034d8169 to fffff800034d8bc0
STACK_TEXT:
fffff880`0398cb98 fffff800`034d8169 : 00000000`0000000a fffffa88`30b957a8 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`0398cba0 fffff800`034d6de0 : fffffa80`2c2eaa70 fffff880`0398cee0 00000000`00000000 fffff6fb`7dbf1000 : nt!KiBugCheckDispatch+0x69
fffff880`0398cce0 fffff800`035551db : fffff880`0398ce58 fffffa80`2bfd5530 00000000`0000000e fffffa80`2bfd5470 : nt!KiPageFault+0x260
fffff880`0398ce70 fffff800`034d6cee : fffffa80`2ae730c0 fffffa80`2beb5270 fffffa80`2beb5270 fffffa80`2bdd1cf0 : nt! ?? ::FNODOBFM::`string'+0x433d3
fffff880`0398cfd0 fffff880`01730f80 : fffffa80`2c7a1600 00000000`00000001 00000000`00000001 fffffa80`2c7a1530 : nt!KiPageFault+0x16e
fffff880`0398d160 fffff880`016be156 : 00000000`00000000 fffff880`01686b18 00000000`00000000 fffffa80`2bdd1cf0 : tcpip!TcpTcbKeepAliveSend+0x320
fffff880`0398d2d0 fffff880`016871a6 : 00000000`00000000 00000000`00000000 00000000`00000e10 00000000`01ea0ca3 : tcpip! ?? ::FNODOBFM::`string'+0x3959d
fffff880`0398d3b0 fffff800`034e385c : fffff880`0398d4c0 fffffa80`0133259c 00000000`00000000 00000000`00000001 : tcpip!TcpPeriodicTimeoutHandler+0x3f9
fffff880`0398d430 fffff800`034e36f6 : fffffa80`1c2c7708 fffffa80`1c2c7708 00000000`00000000 00000000`00000000 : nt!KiProcessTimerDpcTable+0x6c
fffff880`0398d4a0 fffff800`034e35de : 000002eb`c4039f43 fffff880`0398db18 00000000`013a22e2 fffff880`039691c8 : nt!KiProcessExpiredTimerList+0xc6
fffff880`0398daf0 fffff800`034e33c7 : 000000f1`cb3a17c2 000000f1`013a22e2 000000f1`cb3a176b 00000000`000000e2 : nt!KiTimerExpiration+0x1be
fffff880`0398db90 fffff800`034d08ca : fffff880`03965180 fffff880`0396ffc0 00000000`00000000 fffff800`00000000 : nt!KiRetireDpcList+0x277
fffff880`0398dc40 00000000`00000000 : fffff880`0398e000 fffff880`03988000 fffff880`0398dc00 00000000`00000000 : nt!KiIdleLoop+0x5a
STACK_COMMAND: kb
FOLLOWUP_IP:
tcpip!TcpTcbKeepAliveSend+320
fffff880`01730f80 6641890b mov word ptr [r11],cx
SYMBOL_STACK_INDEX: 5
SYMBOL_NAME: tcpip!TcpTcbKeepAliveSend+320
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: tcpip
IMAGE_NAME: tcpip.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 533f5bd4
FAILURE_BUCKET_ID: X64_0xA_tcpip!TcpTcbKeepAliveSend+320
BUCKET_ID: X64_0xA_tcpip!TcpTcbKeepAliveSend+320
Followup: MachineOwner
---------
</code>
見れば分かる通り、このエラーは
＞Probably caused by : tcpip.sys ( tcpip!TcpTcbKeepAliveSend+320 )
とあるのでネットワーク関連で発生したエラーだと推測される。文面を読んでいくと
＞BUGCHECK_STR: 0xA ←0x0Aと言うこと
とあり、先ほど紹介したサイトの説明と合わせて解読すると、「tcpip関連のドライバのエラーで、メモリに不正アクセスしたらしい」と言うことになる。
このケースではこれ一回しか発生しなかったので放置したが、このエラーが頻発するようなら
(a). イーサネットカードのドライバを新しいものにしたり、あるいは古くて安定しているバージョンに差し替える
(b). このエラー自体はOS由来の可能性が高いが、もしかしたら特定のアプリ由来かもしれないので、エラー発生前後のアプリを推測していく。
tcpipのエラーなんだから、なんらかの通信ソフトが原因なことは分かる。たとえば、ブラウザでネットワーク動画を見たのがきっかけとか…
と類推で解決の道を探すようになる。
なお、こんなことを書いているのだから当然僕もうちのWindows7でBSoDエラーが頻発(毎週とか毎月とか)して困った経験がある。僕の場合、原因を追究していくと一つにはIEEE1394でオーディオインターフェースをつなげていたのが原因だった。
もう一つはSTOPコードがSTOP: 0x00000101(CLOCK_WATCHDOG_TIMEOUT)と言うやつで、これはなかなか原因が特定できなかった。CPUのクロックが原因と言われてもなあ…だったが、クロックが変わるということはTurboBoostとかSpeedStepとか類のものだろうと推察して、BIOSの中で気になった「C1Eステート」設定を無効にしたら、BSoDが発生しなくなって問題解決した、などと言うことがあった。
ご参考までに。
Comment
[…] […]