BSOD in ataport ,my god.

NTDEV
1

It’s the result of windbg’s analyze command.
We checked the disk by chkdisk command and found there was no error about the disk.
The BSOD is only seen in several computers of windows 7 after we checked both windows 7 and windows XP.

Dump address: http://sdrv.ms/XIXEq6

Any idea about it?
Thank you in advance!

KERNEL_DATA_INPAGE_ERROR (7a)
The requested page of kernel data could not be read in. Typically caused by
a bad block in the paging file or disk controller error. Also see
KERNEL_STACK_INPAGE_ERROR.
If the error status is 0xC000000E, 0xC000009C, 0xC000009D or 0xC0000185,
it means the disk subsystem has experienced a failure.
If the error status is 0xC000009A, then it means the request failed because
a filesystem failed to make forward progress.

Arguments:
Arg1: c04350c0, lock type that was held (value 1,2,3, or PTE address)
Arg2: c0000185, error status (normally i/o status code)
Arg3: 3a9a5860, current process (virtual address for lock type 3, or PTE)
Arg4: 86a189cc, virtual address that could not be in-paged (or PTE contents if arg1 is a PTE address)

Debugging Details:

ERROR_CODE: (NTSTATUS) 0xc0000185 - I/O

DISK_HARDWARE_ERROR: There was error with disk hardware

BUGCHECK_STR: 0x7a_c0000185

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 0

TRAP_FRAME: 87ca094c – (.trap 0xffffffff87ca094c)
ErrCode = 00000010
eax=86a12320 ebx=842b8608 ecx=00000007 edx=842b8608 esi=84e5c028 edi=842b86c0
eip=86a189cc esp=87ca09c0 ebp=87ca09d0 iopl=0 nv up ei ng nz ac pe cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010297
ataport!ChannelQueryDeviceRelations:
86a189cc fe ???
Resetting default scope

LOCK_ADDRESS: 825a9be0 – (!locks 825a9be0)

Resource @ nt!PiEngineLock (0x825a9be0) Exclusively owned
Contention Count = 134
Threads: 841834c0-01<*>
1 total locks, 1 locks currently held

PNP_TRIAGE:
Lock address : 0x825a9be0
Thread Count : 1
Thread address: 0x841834c0
Thread wait : 0x514a5

LAST_CONTROL_TRANSFER: from 824e5442 to 82520e98

STACK_TEXT:
87ca07b4 824e5442 0000007a c04350c0 c0000185 nt!KeBugCheckEx+0x1e
87ca0824 824e8d25 87ca0878 825ad300 87ca0898 nt!MiWaitForInPageComplete+0x302
87ca08b4 824d2446 825ad300 86a189cc a668bca0 nt!MiIssueHardFault+0x3b3
87ca0934 82482ae8 00000008 86a189cc 00000000 nt!MmAccessFault+0x29fc
87ca0934 86a189cc 00000008 86a189cc 00000000 nt!KiTrap0E+0xdc
87ca09bc 86a15da3 84e5c028 842b8608 84e5c028 ataport!ChannelQueryDeviceRelations
87ca09d0 82478c29 84e5c028 842b8608 87ca0a48 ataport!IdePortDispatchPnp+0x25
87ca09e8 826017a0 00000000 84e523b8 84202c48 nt!IofCallDriver+0x63
87ca0a04 826016d7 87ca0a24 8245709f 84202c48 nt!PnpAsynchronousCall+0x92
87ca0a64 82601459 00000000 8245709f 84202c48 nt!PnpQueryDeviceRelations+0xc5
87ca0aa8 82600089 84202c48 0000001f aa0f5a08 nt!PipEnumerateDevice+0xf9
87ca0ca4 82600e4d 84e5be78 aa0f5a08 87ca0cd0 nt!PipProcessDevNodeTree+0x32c
87ca0cd8 82456d10 825a7b00 841834c0 8257e3bc nt!PiProcessReenumeration+0x74
87ca0d00 824bf1eb 00000000 00000000 841834c0 nt!PnpDeviceActionWorker+0x224
87ca0d50 8264c07a 00000001 9e0a24ba 00000000 nt!ExpWorkerThread+0x10d
87ca0d90 824f2819 824bf0de 00000001 00000000 nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19

STACK_COMMAND: kb

FOLLOWUP_IP:
ataport!IdePortDispatchPnp+25
86a15da3 eb03 jmp ataport!IdePortDispatchPnp+0x2a (86a15da8)

SYMBOL_STACK_INDEX: 6

SYMBOL_NAME: ataport!IdePortDispatchPnp+25

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: ataport

IMAGE_NAME: ataport.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 4ce788e8

FAILURE_BUCKET_ID: 0x7a_c0000185_ataport!IdePortDispatchPnp+25

BUCKET_ID: 0x7a_c0000185_ataport!IdePortDispatchPnp+25

Followup: MachineOwner

2

What’s the system disk brand and type?

3

what does this all have to do with some deity?

Mark Roddy

On Mon, Dec 10, 2012 at 10:21 AM, wrote:

> What’s the system disk brand and type?
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

4

>what does this all have to do with some deity?

I’ve had same in-page fault recently, in the same stack. It failed to page-in the code section where ataport!ChannelQueryDeviceRelations resides. So I wonder if it’s a genuine device fault, or just a side benefit of those wonderful paged sections in storage stack.

5

Consider setting DisablePagingExecutive to 1 and see if it obfuscates the
bug. I know, while the bug does not appear you know nothing except that it
can appear but if you got a gut feeling it did fix the problem then then
consider setting DisablePagingExecutive to 1on your customers machine, to be
done with the EVIL.

See where MS reasoning has gone wrong:
“DisablePagingExecutive Setting this value to 1 is useful when debugging
drivers, because all of the code and data is always memory resident.”

They should make that
“DisablePagingExecutive Setting this value to 1 is **NOT** useful when
debugging drivers, because all of the code and data is always memory
resident and thus obfuscates bugs because of drivers using code sections
that can be paged out while getting called at IRQL>=DISPATCH_LEVEL.”

//Daniel

wrote in message news:xxxxx@ntdev…
> I’ve had same in-page fault recently, in the same stack. It failed to
> page-in the code section where ataport!ChannelQueryDeviceRelations
> resides. So I wonder if it’s a genuine device fault, or just a side
> benefit of those wonderful paged sections in storage stack.
>
>

6

It depends on the type of issue that you are trying to debug. You have to take it in context with the actual underlying problem.

Sometimes, that is a useful setting. Other times, it gets in the way.

  • S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@resplendence.com
Sent: Monday, December 10, 2012 9:13 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] BSOD in ataport ,my god.

Consider setting DisablePagingExecutive to 1 and see if it obfuscates the bug. I know, while the bug does not appear you know nothing except that it can appear but if you got a gut feeling it did fix the problem then then consider setting DisablePagingExecutive to 1on your customers machine, to be done with the EVIL.

See where MS reasoning has gone wrong:
“DisablePagingExecutive Setting this value to 1 is useful when debugging drivers, because all of the code and data is always memory resident.”

They should make that
“DisablePagingExecutive Setting this value to 1 is **NOT** useful when debugging drivers, because all of the code and data is always memory resident and thus obfuscates bugs because of drivers using code sections that can be paged out while getting called at IRQL>=DISPATCH_LEVEL.”

//Daniel

wrote in message news:xxxxx@ntdev…
> I’ve had same in-page fault recently, in the same stack. It failed to
> page-in the code section where ataport!ChannelQueryDeviceRelations
> resides. So I wonder if it’s a genuine device fault, or just a side
> benefit of those wonderful paged sections in storage stack.
>
>

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

7

> KERNEL_DATA_INPAGE_ERROR (7a)

Usually, this is due to faulty disk/controller hardware.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com