Windows Xp-maskin med bugcheck 0xA (IRQL not less or equal)

Windows maskinen ville gi blåskjerm hver gang bruker logget seg på-bestandig samme type bugcheck og parametre hver gang.
Hentet ut kjerneminnedump fra maskinen og åpnet den i Windbg og dumpet deretter ut stakken:

kd> kv
ChildEBP RetAddr Args to Child
f8959e08 804dbda3 badb0d00 00000000 82266008 nt!KiTrap0E+0x233 (FPO: [0,0] TrapFrame @ f8959e08)
f8959e98 804dc4a8 f8959fc0 0000003e f8959fc0 nt!KiWaitTest+0x30 (FPO: [Non-Fpo])
f8959fa4 804dc378 18d1bda0 00000000 ffdff000 nt!KiTimerListExpire+0x7a (FPO: [Non-Fpo])
f8959fd0 804dbbd4 8055a020 00000000 0000103d nt!KiTimerExpiration+0xaf (FPO: [Non-Fpo])
f8959ff4 804db89e baeead54 00000000 00000000 nt!KiRetireDpcList+0x46 (FPO: [0,0,0])
f8959ff8 baeead54 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x2a (FPO: [Uses EBP] [0,0,1])
WARNING: Frame IP not in any known module. Following frames may be wrong.804db89e 00000000 00000009 bb835675 00000128 0xbaeead54

Nederste stakkramme ser ut til å være ugyldig og referer ikke til noen gyldig instruksjon-men for nå skal vi se på hva som egentlig trigget blåskjermen. Vi ser at feilen er fanget av KiTrap ved f8959e08 la oss endre kontekst ved å sette først .trap f8959e08 og deretter dumpe ut registrene:

kd> .trap f8959e08
ErrCode = 00000000
eax=00000000 ebx=81fd9fe8 ecx=f8959e88 edx=00000000 esi=81fd9fe0 edi=81fda008 eip=804dbda3 esp=f8959e7c ebp=f8959e98 iopl=0 nv up ei pl nz ac pe cycs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010217
nt!KiWaitTest+0x30:804dbda3 6683781601 cmp word ptr [eax+16h],1 ds:0023:00000016=????

Vi kan av dette se at instruksen som feilet var en cmp (compare) instruksjon som hentet en peker fra eax+16. Denne instruksen feiler da fordi at som vi ser er eax registeret nullet ut og dette igjen får oss da til å lese fra minneområde 00000016 som da er et område i minnet som er resverert nullpekere og dermed er et ugyldig område i minnet. Første spørsmål vi har er hva som gjorde at eax ble satt til 0? Vi tar derfor en nærmere titt på instruksjone som ble kjørt innunder KiWaitTest.

kd> uf nt!KiWaitTest+0x30
nt!KiWaitTest:
804dbd7b 8bff mov edi,edi
804dbd7d 55 push ebp
804dbd7e 8bec mov ebp,esp
804dbd80 83ec10 sub esp,10h
804dbd83 53 push ebx
804dbd84 56 push esi
804dbd85 8bf1 mov esi,ecx
804dbd87 837e0400 cmp dword ptr [esi+4],0
804dbd8b 8d4df0 lea ecx,[ebp-10h]
804dbd8e 8d5e08 lea ebx,[esi+8]
804dbd91 8b03 mov eax,dword ptr [ebx]
804dbd93 8955f8 mov dword ptr [ebp-8],edx
804dbd96 894df4 mov dword ptr [ebp-0Ch],ecx
804dbd99 894df0 mov dword ptr [ebp-10h],ecx
804dbd9c 7e5f jle nt!KiWaitTest+0xd7 (804dbdfd)

nt!KiWaitTest+0x27:
804dbd9e 57 push edi

nt!KiWaitTest+0x28:
804dbd9f 3bc3 cmp eax,ebx
804dbda1 744f je nt!KiWaitTest+0xb7 (804dbdf2)

nt!KiWaitTest+0x30:
804dbda3 6683781601 cmp word ptr [eax+16h],1

Vi kan se dermed se at eax registeret blir satt ved instruksjonen:
804dbd91 8b03 mov eax,dword ptr [ebx]

Som henter en dword peker lagret i registeret ebx-hva ligger lagret i ebx?

kd> dd ebx
81fd9fe8 00000000 00000000 18d1af90 00000000
81fd9ff8 f8959fc0 f8959fc0 81fda008 00000000
81fda008 01000013 00000000 00000000 f8370f1a
81fda018 81fd9fe0 00000000 00000000 00000000
81fda028 bad67b5a 81fd7000 820e5ad0 00000000
81fda038 000a0008 00000001 81fda040 81fda040
81fda048 00000000 00000000 00000000 00000000
81fda058 81fda060 00000000 01000013 ffdff980

Som vi kan se er pekerne nullet ut og det er altså slik eax registret har blitt nullet ut.
Jeg slo på pool tagging med gflags for å forsøke å finne ut hvem som eide dette området av minnet og derettet kjøre
!pool opp mot denne addressen.

kd> !pool 81fd9fe8
Pool page 81fd9fe8 region is Nonpaged pool
*81fd7000 : large page allocation, Tag is NALW, size is 0x5000 bytes
Owning component : Unknown (update pooltag.txt)

Som vi kan se har modulen som har allokert dette minneområdet en ukjent minnetag "NALW" og vi kan derfor anta at dette tilhører en tredjepartsmodul. Hvordan finner vi ut hvilken driver som bruker denne tag'en?
Det enkleste er da å bruke programmet strings om kan lastes ned herfra:
http://technet.microsoft.com/en-us/sysinternals/bb897439.aspx

Deretter startet jeg det og kjøte det opp mot den vanligste lokasjonen for systemdrivere (c:\windows\system32\drivers)

Slik så resultatet ut:

Kom da frem til at pool-taggen tilhørte wlcom51b.sys. Som Windows beskrev som en miniport driver for wlan-kortet.

kd> lm kv m wlcom51b
start end module name
bad5e000 bad8ac00 wlcom51b (deferred)
Image path: \SystemRoot\system32\DRIVERS\wlcom51b.sys
Image name: wlcom51b.sys
Timestamp: Fri Oct 22 15:59:55 2004 (4179125B)
CheckSum: 00033C12
ImageSize: 0002CC00
Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0

Ved oppdatering av denne forsvant problemet, så det ser ut til at det er denne driveren som har gjort stakken korrupt og skrevet over registeret ebx (som lå på stakken.)