crash in atapi.sys

NTDEV
1

Yesterday I got a blue screen when my laptop got out of standby.
to my surprise it seems to have bugchecked in atapi.sys (see !analyze -v
output below).

If the atapi driver fails, how can the system create a dump file? I would
think that the system has no disk access anymore. That is obviously not
true, since I did get a complete dump file.

–

Kind regards,
Bruno van Dooren
xxxxx@hotmail.com
Remove only “_nos_pam”

Loading Dump File [C:\WINDOWS\MEMORY.DMP]
Kernel Summary Dump File: Only kernel address space is available

Symbol search path is:
D:\DebuggerSymbols;D:\Projects\DDK_projects\WDF_Usb\WDF_Usb_driver\objchk_wxp_x86\i386
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 2) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp_sp2_gdr.050301-1519
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055a420
Debug session time: Sat Apr 8 18:34:37.591 2006 (GMT+2)
System Uptime: 2 days 20:38:45.763
Loading Kernel Symbols
…
Loading User Symbols
Loading unloaded module list
…
*******************************************************************************
*
*
* Bugcheck Analysis
*
*
*
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck D1, {a0a0016, d, 0, f7601f75}

Probably caused by : atapi.sys ( atapi!IdeStartIoSynchronized+37 )

Followup: MachineOwner

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: 0a0a0016, memory referenced
Arg2: 0000000d, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: f7601f75, address which referenced memory

Debugging Details:

READ_ADDRESS: 0a0a0016

CURRENT_IRQL: d

FAULTING_IP:
atapi!IdeStartIoSynchronized+37
f7601f75 8a4102 mov al,[ecx+0x2]

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from f7601f75 to 804e187f

STACK_TEXT:
8054ff60 f7601f75 badb0d00 82d75f50 f760129e nt!KiTrap0E+0x233
8054ffe8 f7601c2d 82f6b030 82f6b030 82f6b0e8
atapi!IdeStartIoSynchronized+0x37
80550004 804da6ed 80550034 00000002 00000000
atapi!IdeResetBusSynchronized+0xe1
80550044 804e3f3b 82f6b030 00000000 804e3ef7 nt!KeSynchronizeExecution+0x17
80550064 804dc4fd 80557d40 00000000 5398d5d0 nt!IopTimerDispatch+0x42
80550180 804dc378 80558e80 80558c20 ffdff000 nt!KiTimerListExpire+0x122
805501ac 804dbbd4 80559280 00000000 01788ab1 nt!KiTimerExpiration+0xaf
805501d0 804dbb4d 00000000 0000000e 00000000 nt!KiRetireDpcList+0x46
805501d4 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x26

STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_IP:
atapi!IdeStartIoSynchronized+37
f7601f75 8a4102 mov al,[ecx+0x2]

FAULTING_SOURCE_CODE:

SYMBOL_STACK_INDEX: 1

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: atapi!IdeStartIoSynchronized+37

MODULE_NAME: atapi

IMAGE_NAME: atapi.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 41107b4d

FAILURE_BUCKET_ID: 0xD1_atapi!IdeStartIoSynchronized+37

BUCKET_ID: 0xD1_atapi!IdeStartIoSynchronized+37

Followup: MachineOwner

2

Hi Bruno;
This is with regard to solving the BSOD :).
I have experienced exact similar crashes when my driver did not do the
proper KeEnterCriticalRegion & KeLeaveCriticalRegion nesting around the
calls like ExAcquireResourceSharedLite and ExReleaseResourcelite Calls.

See the documentation for *ExAcquireResourceSharedLite* for more details.

AFAIK its not a driver developed by you causing the Laptop BSOD. But i
suspect that one of ther drivers on your laptop is causing the problem. The
faulty driver can be easily detected using the driver verifier
verifier.exeand monitor all the unsigned drivers on your system. The
verifier will point
out the driver on its first voilation of the nesting rule, that necessarily
wont be when you come out of standby.

Thanks & Regards
Faraz.

On 4/9/06, Bruno van Dooren wrote:
>
> Yesterday I got a blue screen when my laptop got out of standby.
> to my surprise it seems to have bugchecked in atapi.sys (see !analyze -v
> output below).
>
> If the atapi driver fails, how can the system create a dump file? I would
> think that the system has no disk access anymore. That is obviously not
> true, since I did get a complete dump file.
>
> –
>
> Kind regards,
> Bruno van Dooren
> xxxxx@hotmail.com
> Remove only “_nos_pam”
>
>
> Loading Dump File [C:\WINDOWS\MEMORY.DMP]
> Kernel Summary Dump File: Only kernel address space is available
>
> Symbol search path is:
>
> D:\DebuggerSymbols;D:\Projects\DDK_projects\WDF_Usb\WDF_Usb_driver\objchk_wxp_x86\i386
> Executable search path is:
> Windows XP Kernel Version 2600 (Service Pack 2) UP Free x86 compatible
> Product: WinNt, suite: TerminalServer SingleUserTS
> Built by: 2600.xpsp_sp2_gdr.050301-1519
> Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055a420
> Debug session time: Sat Apr 8 18:34:37.591 2006 (GMT+2)
> System Uptime: 2 days 20:38:45.763
> Loading Kernel Symbols
>
> …
> Loading User Symbols
> Loading unloaded module list
> …
>
> *****
>
>
> * Bugcheck Analysis
>
>
>
>
>
>
> Use !analyze -v to get detailed debugging information.
>
> BugCheck D1, {a0a0016, d, 0, f7601f75}
>
> Probably caused by : atapi.sys ( atapi!IdeStartIoSynchronized+37 )
>
> Followup: MachineOwner
> ---------
>
> 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: 0a0a0016, memory referenced
> Arg2: 0000000d, IRQL
> Arg3: 00000000, value 0 = read operation, 1 = write operation
> Arg4: f7601f75, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: 0a0a0016
>
> CURRENT_IRQL: d
>
> FAULTING_IP:
> atapi!IdeStartIoSynchronized+37
> f7601f75 8a4102 mov al,[ecx+0x2]
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0xD1
>
> LAST_CONTROL_TRANSFER: from f7601f75 to 804e187f
>
> STACK_TEXT:
> 8054ff60 f7601f75 badb0d00 82d75f50 f760129e nt!KiTrap0E+0x233
> 8054ffe8 f7601c2d 82f6b030 82f6b030 82f6b0e8
> atapi!IdeStartIoSynchronized+0x37
> 80550004 804da6ed 80550034 00000002 00000000
> atapi!IdeResetBusSynchronized+0xe1
> 80550044 804e3f3b 82f6b030 00000000 804e3ef7
> nt!KeSynchronizeExecution+0x17
> 80550064 804dc4fd 80557d40 00000000 5398d5d0 nt!IopTimerDispatch+0x42
> 80550180 804dc378 80558e80 80558c20 ffdff000 nt!KiTimerListExpire+0x122
> 805501ac 804dbbd4 80559280 00000000 01788ab1 nt!KiTimerExpiration+0xaf
> 805501d0 804dbb4d 00000000 0000000e 00000000 nt!KiRetireDpcList+0x46
> 805501d4 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x26
>
>
> STACK_COMMAND: .bugcheck ; kb
>
> FOLLOWUP_IP:
> atapi!IdeStartIoSynchronized+37
> f7601f75 8a4102 mov al,[ecx+0x2]
>
> FAULTING_SOURCE_CODE:
>
>
> SYMBOL_STACK_INDEX: 1
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: atapi!IdeStartIoSynchronized+37
>
> MODULE_NAME: atapi
>
> IMAGE_NAME: atapi.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 41107b4d
>
> FAILURE_BUCKET_ID: 0xD1_atapi!IdeStartIoSynchronized+37
>
> BUCKET_ID: 0xD1_atapi!IdeStartIoSynchronized+37
>
> Followup: MachineOwner
> ---------
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

3

> AFAIK its not a driver developed by you causing the Laptop BSOD. But i suspect that one of ther drivers

on your laptop is causing the problem. The faulty driver can be easily detected using the driver verifier
verifier.exe and monitor all the unsigned drivers on your system. The verifier will point out the driver on its first
voilation of the nesting rule, that necessarily wont be when you come out of standby.

I wasn’t running any of my own drivers at the moment of the crash.
The crash dump traces the crash into the atapi.sys driver. wouldn’t it seem logical then that it is that one who is responsible?

–

Kind regards,
Bruno van Dooren
xxxxx@hotmail.com
Remove only “_nos_pam”

4

There is a second copy of the disk driver that is used to take the dump.

Loren

5

The OS preloads a second instance of the whole ATAPI binary early on boot
stage, with a second driver object named like “dump_atapi.sys”. This image is
activated only in the beginning of the dump sequence. This effectively mean the
controller reset, so, even if the main instance of ATAPI have left the
controller in a bad state, it will be reset nevertheless.

Same is for SCSI controllers, where we have the second instance of the
miniport loaded (and initialized only in dump path).

Same is for hibernate paths.

Note that these second instances are not accessed via IRPs. Instead,
IOCTL_SCSI_GET_DUMP_POINTERS is used to get the function table, with the
functions like DumpWrite etc.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Bruno van Dooren”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Sunday, April 09, 2006 12:55 PM
Subject: [ntdev] crash in atapi.sys

> Yesterday I got a blue screen when my laptop got out of standby.
> to my surprise it seems to have bugchecked in atapi.sys (see !analyze -v
> output below).
>
> If the atapi driver fails, how can the system create a dump file? I would
> think that the system has no disk access anymore. That is obviously not
> true, since I did get a complete dump file.
>
> –
>
> Kind regards,
> Bruno van Dooren
> xxxxx@hotmail.com
> Remove only “_nos_pam”
>
>
> Loading Dump File [C:\WINDOWS\MEMORY.DMP]
> Kernel Summary Dump File: Only kernel address space is available
>
> Symbol search path is:
>
D:\DebuggerSymbols;D:\Projects\DDK_projects\WDF_Usb\WDF_Usb_driver\objchk_wxp_x
86\i386
> Executable search path is:
> Windows XP Kernel Version 2600 (Service Pack 2) UP Free x86 compatible
> Product: WinNt, suite: TerminalServer SingleUserTS
> Built by: 2600.xpsp_sp2_gdr.050301-1519
> Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055a420
> Debug session time: Sat Apr 8 18:34:37.591 2006 (GMT+2)
> System Uptime: 2 days 20:38:45.763
> Loading Kernel Symbols
>
…
…
> Loading User Symbols
> Loading unloaded module list
> …
>
*****
>
>
> * Bugcheck Analysis
>
>
>
>
>
> Use !analyze -v to get detailed debugging information.
>
> BugCheck D1, {a0a0016, d, 0, f7601f75}
>
> Probably caused by : atapi.sys ( atapi!IdeStartIoSynchronized+37 )
>
> Followup: MachineOwner
> ---------
>
> 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: 0a0a0016, memory referenced
> Arg2: 0000000d, IRQL
> Arg3: 00000000, value 0 = read operation, 1 = write operation
> Arg4: f7601f75, address which referenced memory
>
> Debugging Details:
> ------------------
>
>
> READ_ADDRESS: 0a0a0016
>
> CURRENT_IRQL: d
>
> FAULTING_IP:
> atapi!IdeStartIoSynchronized+37
> f7601f75 8a4102 mov al,[ecx+0x2]
>
> DEFAULT_BUCKET_ID: DRIVER_FAULT
>
> BUGCHECK_STR: 0xD1
>
> LAST_CONTROL_TRANSFER: from f7601f75 to 804e187f
>
> STACK_TEXT:
> 8054ff60 f7601f75 badb0d00 82d75f50 f760129e nt!KiTrap0E+0x233
> 8054ffe8 f7601c2d 82f6b030 82f6b030 82f6b0e8
> atapi!IdeStartIoSynchronized+0x37
> 80550004 804da6ed 80550034 00000002 00000000
> atapi!IdeResetBusSynchronized+0xe1
> 80550044 804e3f3b 82f6b030 00000000 804e3ef7 nt!KeSynchronizeExecution+0x17
> 80550064 804dc4fd 80557d40 00000000 5398d5d0 nt!IopTimerDispatch+0x42
> 80550180 804dc378 80558e80 80558c20 ffdff000 nt!KiTimerListExpire+0x122
> 805501ac 804dbbd4 80559280 00000000 01788ab1 nt!KiTimerExpiration+0xaf
> 805501d0 804dbb4d 00000000 0000000e 00000000 nt!KiRetireDpcList+0x46
> 805501d4 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x26
>
>
> STACK_COMMAND: .bugcheck ; kb
>
> FOLLOWUP_IP:
> atapi!IdeStartIoSynchronized+37
> f7601f75 8a4102 mov al,[ecx+0x2]
>
> FAULTING_SOURCE_CODE:
>
>
> SYMBOL_STACK_INDEX: 1
>
> FOLLOWUP_NAME: MachineOwner
>
> SYMBOL_NAME: atapi!IdeStartIoSynchronized+37
>
> MODULE_NAME: atapi
>
> IMAGE_NAME: atapi.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 41107b4d
>
> FAILURE_BUCKET_ID: 0xD1_atapi!IdeStartIoSynchronized+37
>
> BUCKET_ID: 0xD1_atapi!IdeStartIoSynchronized+37
>
> Followup: MachineOwner
> ---------
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer