Pewnego chłodnego jesiennego dnia zdarzyło mi się doświadczyć bardzo niemiłej niespodzianki ze strony nowo zakupionego komputera. Był to świeży, jeszcze ciepły komputer Dell Optiplex 740, wprost z Limerick, na którym zainstalowałem Windows Server 2003 R2 EE z zamiarem wykorzystania pudełka jako hosta do wirtualnych maszyn działających na Virtual Server 2005 R2.
Instalacja systemu, konfiguracja, później instalacja VS przebiegły bez zakłóceń. Dopiero, gdy zacząłem instalować pierwszego gościa na serwerze wirtualnym, mój komputer znieruchomiał. Nie reagował na żadne klawisze, myszka zastygła bez ruchu tam gdzie ją zostawiłem, tzw. stan zamrożenia (freeze).
Powtórzyłem więc operację w celu otrzymania chociaż BSOD (Blue Screen Of Death, czyli po polsku niebieski ekran). Znów ta sama reakcja. Powtórzyłem próbę jeszcze kilka razy wciąż bez spodziewanego niebieskiego ekranu błędu. Zacząłem szukać po Intra- i Internecie materiałów na podstawie których mógłbym zlokalizować błąd. Niestety rozrzut tematyki był na tyle duży, że aż nieprzydatny.
Eliminując z łamigłówki poszczególne klocki układanki postanowiłem zainstalować gościa na Virtual PC 2007. Efekt był dokładnie ten sam - zamrożenie systemu. Wypadło jeszcze kilka innych czynników, łącznie ze sprzętem - klawiatura, myszka, inne urządzenia USB; wyeliminowanie systemu operacyjnego już nie było takie proste.
Zainstalowałem Windows Vista Enterprise i Virtual PC 2007. Za pierwszym razem efekt był podobny do tego otrzymanego na Windows Server 2003, ale już za drugim podejściem dostałem to, czego szukałem - BSOD.
Oto wycinek z windbg:
BugCheck 101, {61, 0, 8a4c7120, 1}
PEB is paged out (Peb.Ldr = 7ffd300c). Type “.hh dbgerr001″ for details
PEB is paged out (Peb.Ldr = 7ffd300c). Type “.hh dbgerr001″ for details
Probably caused by : ntkrpamp.exe ( nt!KeFlushProcessWriteBuffers+5f )
Followup: MachineOwner
Dalsza analiza z użyciem !analyze -v pokazała mi już nieco więcej szczegółów:
CLOCK_WATCHDOG_TIMEOUT (101)
An expected clock interrupt was not received on a secondary processor in an
MP system within the allocated interval. This indicates that the specified
processor is hung and not processing interrupts.
Arguments:
Arg1: 00000061, Clock interrupt time out interval in nominal clock ticks.
Arg2: 00000000, 0.
Arg3: 8a4c7120, The PRCB address of the hung processor.
Arg4: 00000001, 0.
I dalej:
PEB is paged out (Peb.Ldr = 7ffd300c). Type “.hh dbgerr001″ for details
PEB is paged out (Peb.Ldr = 7ffd300c). Type “.hh dbgerr001″ for details
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0×101
PROCESS_NAME: SearchProtocolH
CURRENT_IRQL: 1c
LAST_CONTROL_TRANSFER: from 81828448 to 818d85c9STACK_TEXT:
[cut] nt!KeBugCheckEx+0×1e
[cut] nt!KeUpdateRunTime+0xd4
[cut] nt!KeUpdateSystemTime+0xed
[cut] nt!KeFlushProcessWriteBuffers+0×5f
[cut] nt!KeSetPriorityAndQuantumProcess+0×6a
[cut] nt!PsSetProcessPriorityByClass+0×20
[cut] nt!NtSetInformationProcess+0×219
[cut] nt!KiFastCallEntry+0×12a
WARNING: Frame IP not in any known module. Following frames may be wrong.
[cut]STACK_COMMAND: kb
FOLLOWUP_IP:
nt!KeFlushProcessWriteBuffers+5f
81811c63 8b08 mov ecx,dword ptr [eax]
SYMBOL_STACK_INDEX: 3
SYMBOL_NAME: nt!KeFlushProcessWriteBuffers+5f
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrpamp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 4549ae00
FAILURE_BUCKET_ID: 0×101_nt!KeFlushProcessWriteBuffers+5f
Pozwoliłem sobie powycinać co dłuższe kawałki z powyższego tesktu z windbg dla jasności obrazu.
Poszukałem co to takiego jest ten bugcheck 0×101: The specified processor is not processing interrupts. Typically, this occurs when the processor is nonresponsive or is deadlocked.
Procesor nie odpowiadał? Z uwagi na już drugi sprawdzany system operacyjny, wyglądało to dla mnie całkiem sprzętowo. Nie pierwszy i zapewne nie ostatni raz widziałem nowe komputery (serwery) z błędami sprzętowymi. Niestety nie miałem okazji sprawdzić tego zachownia na innych Optiplexach 740 z identyczną konfiguracją, ale postanowiłem szukać szczęścia na stronach pomocy technicznej Della, mojego poprzedniego pracodawcy.
Niespodziewanie okazało się, że istniała nowa wersja BIOSu, która uaktualniła wersję 1.1.8 do 1.2.2. Z samych cyferek widać, że to dość duży skok.
Zainstalowałem nową wersję BIOS’u i … jak ręką odjął. Na nowym komputerku już działają sobie dwie maszyny wirtualne radośnie komunikując się między sobą.
Nie po raz pierwszy byłem cierpliwy w poszukiwaniu błędu, choć tym razem moja cierpliwość była posunięta do granic. Niestety Dell nie precyzuje dokładnie w czym różniła się nowa wersja BIOS’u od pozostałych poza ulepszeniem kompatybilności z niektórymi urządzeniami USB i poprawnieniem zarządzania energią. Jeśli jednak to był problem z USB, to zastanawiające czemu błąd rodził się tylko podczas instalacji maszyn wirtualnych? Jeśli ktoś drążył ten temat głębiej, chętnie postiuduję materiał.
Ostatnie komentarze