Hello,
I have a blue screen that I get from the ATAPI device when it tries to read
some data from a paged out buffer in high IRQL (0xd). In my filter driver I
issue a write request with a buffer that is allocated from paged pool and is
PAGE aligned (0x1000), and build the IRP using the
IoBuildAsynchronousFsdRequest. The I/O manager locks only the write length
part of the buffer, and it seems that the ATAPI is trying to read some more
data from the buffer than is requested from it. Is it possible that I need
to lock the buffer myself and to align the lock to sector size (512 bytes)?
Doesn’t the NTFS or the I/O manager should take care of the sector alignment
details for me? Is it a different problem altogether (I went over my code
more than once and everything seems ok, and the read that I see in the ATAPI
device is larger than the write length I passed to the
IoBuildAsynchronousFsdRequest)?
Here is the info from the windbg:
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pagable (or completely invalid) address at
an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: be6a7000, memory referenced
Arg2: 0000000d, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 80067a1e, address which referenced memory
Debugging Details:
READ_ADDRESS: be6a7000 Nonpaged pool
CURRENT_IRQL: d
FAULTING_IP:
hal!WRITE_PORT_BUFFER_USHORT+e
80067a1e f3666f rep outsw
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: A
LAST_CONTROL_TRANSFER: from 8042bcb9 to 80452e70
STACK_TEXT:
ed41f978 8042bcb9 00000003 ed41f9c0 be6a7000
nt!RtlpBreakWithStatusInstruction
ed41f9a8 8042c068 00000003 be6a7000 80067a1e nt!KiBugCheckDebugBreak+0x31
ed41fd30 80464b1f 00000000 be6a7000 0000000d nt!KeBugCheckEx+0x37b
ed41fd30 80067a1e 00000000 be6a7000 0000000d nt!KiTrap0E+0x27c
ed41fdbc bff24f92 000001f0 be6a6820 00000400
hal!WRITE_PORT_BUFFER_USHORT+0xe
ed41fdf0 bff28e3c 00000000 8136decc 0000000e atapi!AtapiInterrupt+0x380
ed41fe00 8046586a 8136dc68 81352150 be68e002 atapi!ScsiPortInterrupt+0x14
ed41fe00 80062f38 8136dc68 81352150 be68e002 nt!KiInterruptDispatch+0x2a
ed41fe88 8046573c 81352208 8136d702 80436c02 hal!KfLowerIrql+0x38
ed41fe9c bff29b07 8136dc68 bff29448 81352150 nt!KeSynchronizeExecution+0x2c
ed41febc bff29abc 00000000 00000000 00000000
atapi!CallSpStartIoSynchronized+0x39
ed41fed0 bff28d73 81352150 81352150 87799488
atapi!IdePortAllocateAccessToken+0x1a
ed41fee8 80420d4a 81352150 87799488 87799488 atapi!ScsiPortStartIo+0x12f
ed41ff0c bff29d13 81352150 87799488 00000000 nt!IoStartPacket+0x93
ed41ff34 bff2a1ad 81352208 8136d7c8 813522e0 atapi!GetNextLuRequest+0xff
ed41ff70 bff29027 81352208 813522e0 ed41ffdf
atapi!SpProcessCompletedRequest+0x199
ed41ffe0 80460bd4 813521c4 81352150 00000000
atapi!ScsiPortCompletionDpc+0x1c7
ed41fff4 80403a82 bef17d54 00000000 00000000 nt!KiRetireDpcList+0x30
FOLLOWUP_IP:
atapi!AtapiInterrupt+380
bff24f92 f6c301 test bl,0x1
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: atapi!AtapiInterrupt+380
MODULE_NAME: atapi
IMAGE_NAME: atapi.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 38497754
STACK_COMMAND: kb
BUCKET_ID: 0xA_atapi!AtapiInterrupt+380
Followup: MachineOwner
Gilad.
“For those who bear the instruments of war - and we are among them,
Some in practice,
Some by a hug of approval -
Are sucked, mumbling “necessity” and “vengeance”,
Into the domain of war crimes.”
Nathan Alterman, 1948