Prípad dlhého vypínania PC s Blue Screenom na nových Windows 7

Upgradoval som jeden počítač s Vista Business 32bit na Windows 7 Professional 32bit. Upgrade prebehol v pohode, ale bol problém s jednou nefunkčnou CD romkou a o pár dní užívateľ vravel, že počítač sa dlho vypína, dokonca aj spadne do Blue Screenu.

Prvé informácie o BSOD sú v Event Logu:

Chybový sektor 0x9F_4_cdrom_IMAGE_jraid.sys, typ 0
Názov udalosti: BlueScreen
Odozva: Nie je k dispozícii
Identifikácia kabinetu: 0

...
Priložené súbory:
C:\Windows\Minidump\090409-106078-01.dmp

Vďaka tomuto padá prvé podozrenie na ovládač pre JMicron JMB36X Controller (jraid.sys). Keďže však tento ovládač nie je priamo spomenutý v zázname a aj pre kontrolu je dobré zanalyzovať Memory Dump ktorý je v priečinku Minidump.

Analýza výpisu pamäte (Memory Dump)

Súbor 090409–106078–01.dmp som otvoril v 32bitovej verzii programu WinDbg a spustil som analýzu príkazom !analyze.

0: kd> !analyze
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 9F, {4, 258, 855ec798, 82f66b24}

Probably caused by : cdrom.sys ( cdrom!DeviceSendPowerProcessRequest+15b )

Followup: MachineOwner

Prvá dôležitá informácie je, že Blue Screen vznikol na základe Bug Check stavu – kernel zistil, že niečo nie je v poriadku so zariadením alebo ovládačom a prepol teda na Blue Screen pretože nemôže normálne pokračovať. Súčasťou Blue Screenu je zaznamenanie stavu pamäte do .dmp súboru (ak je zapnutá voľba Zápis pamäte pre ladenie > Výpis pamäte jadra (Kernel memory dump)).

Rozšírené informácie o stave pamäte dostaneme príkazov !analyze -v:

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

DRIVER_POWER_STATE_FAILURE (9f)
A driver is causing an inconsistent power state.
Arguments:
Arg1: 00000004, The power transition timed out waiting to synchronize with the Pnp
        subsystem.
Arg2: 00000258, Timeout in seconds.
Arg3: 855ec798, The thread currently holding on to the Pnp lock.
Arg4: 82f66b24
...

Vďaka dostupnosti .pdb symbolov je možné zistiť význam jednotlivých parametrov Bug Check 0×9F priamo z analýzy. Prvý parameter Arg1 = 0x04 označuje typ problému pri DRIVER_POWER_STATE_FAILURE. Bohužial zatiaľ nie je zdokumentovaný na webe MSDN Library ani vo Windows 7 Driver Kit. Typ 0×04 bol pridaný vo Vista SP2 a Windows 7. Podľa Melissi Hannah to znamená, že došlo k deadlocku v threadoch a pokiaľ sa neodblokujú do určitého času (Arg2) bude vyvolaný Bug Check 0×9F s kódom 4.

Dlhé vypínanie

Z druhého parametru Bug Checku sa dá vyčítať, ako dlho bude systém čakať pri deadlocku threadov pri vypínaní: 0×0258 = 600, údaj je v sekundách, čiže to je 10 minút, kým systém spadne do Blue Screenu. Čo korešponduje s popisovaným problémom – že počítač sa dlho vypína. Neznamená to však, že k BSOD dojde vždy. Je možné, že ovládač sa niekedy „rozbehne“ a vypne. Bez BSOD by sa to však tak ľahko nepodarilo zistiť ;-)

Zdroj problému

Device Manager

Tretí argument Bug Checku reportuje adresu threadu, ktorý bol zablokovaný (The thread currently holding on to the Pnp lock.). Detail si zobrazíme príkazom !thread 855ec798. V tomto threade je používaný ovládač cdrom.sys. Aj podľa rozšírenej analýzy problém nastal vo funkcii volanej týmto ovládačom – DeviceSendPowerProcessRequest.

...
SYMBOL_NAME:  cdrom!DeviceSendPowerProcessRequest+15b

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: cdrom

IMAGE_NAME:  cdrom.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4a5bbf1c

FAILURE_BUCKET_ID:  0x9F_cdrom!DeviceSendPowerProcessRequest+15b

BUCKET_ID:  0x9F_cdrom!DeviceSendPowerProcessRequest+15b
...

Príkazom lmvm cdrom získame bližšie informácie o ovládači. Jedná sa o štandardný ovládač dodávaný so systémom. Z Správcu zariadení (Device Manager) je vidieť, že CD-Romky sú pripojené cez JMicron JMB36X. Skontrolovanie tohto ovládača cez lmvm jraid odhalí, že je celkom starý – z novembra 2008.

0: kd> lmvm jraid
start    end        module name
8b400000 8b418000   jraid    T (no symbols)
    Loaded symbol image file: jraid.sys
    Image path: \SystemRoot\system32\DRIVERS\jraid.sys
    Image name: jraid.sys
    Timestamp:        Fri Nov 21 16:05:38 2008 (4926CE42)
    CheckSum:         000215C8
    ImageSize:        00018000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4

Server JMicronu obsahuje novšie ovládače pre ich chip (R1.17.50 z augusta 2009) na adrese ftp://driver.jmicron.com.tw/…_Vista_Win7/. Podľa ReleaseNotes.txt odvtedy opravovali niekoľko problémov s BSOD. Ovládač som nainštaloval a teraz budem čakať, či sa chyba prejaví a budem môcť analyzovať ďalší problém, alebo je to vyriešené.

PS: Pre mnohých sú BSOD veľkou pohromou a symbolom nefunkčnosti Windows. Pre mňa sú vďaka Markovi Russinovichovi najcennejším zdrojom riešenia problémov.

0 thoughts on “Prípad dlhého vypínania PC s Blue Screenom na nových Windows 7

Comments are closed.