Hi, thanks for your answwer(s),
“Lookaside lists are just lists of memory allocated from pool” - that’s
what I thought too.
I’m really not aware of touching the memory after it’s freed, but that’s
indeed what some of the BSODs say.
Am I so blind ?
I didn’t send a callstack, because the BSODs vary.
(I’m using DbgTools Version 6.5.3.8 and since then have trouble with
LoadLibrary(exts),
I skipped output of this.)
Here we go:
- XP with Verifier, I used IoBuildSynchronousFsdRequest here
my own last output:
sent pIrp 81C51ED8 for pDO 80E599E8
IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000004, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: 806474e2, address which referenced memory
CURRENT_IRQL: 2
FAULTING_IP:
nt!IovpCompleteRequest2+123
806474e2 895004 mov [eax+0x4],edx
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xA
LAST_CONTROL_TRANSFER: from 8063cc2f to 806474e2
TRAP_FRAME: fc91b838 – (.trap fffffffffc91b838)
.trap fffffffffc91b838
ErrCode = 00000002
eax=00000000 ebx=81be7db8 ecx=80d9bfe8 edx=80d9bf04 esi=80dff5a0
edi=80e3bb10
eip=806474e2 esp=fc91b8ac ebp=fc91b8d8 iopl=0 nv up ei pl nz ac po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010216
nt!IovpCompleteRequest2+0x123:
806474e2 895004 mov [eax+0x4],edx
ds:0023:00000004=???
.trap
Resetting default scope
STACK_TEXT:
fc91b8d8 8063cc2f 81be7f93 81be7db8 00000000 nt!IovpCompleteRequest2+0x123
fc91b8f0 804ec0ae 80e00420 81be7db8 fc91b934
nt!IovpLocalCompletionRoutine+0x61
fc91b920 8063d0b6 00000000 00000000 81be7db8 nt!IopfCompleteRequest+0xa0
fc91b988 baf84bb6 80dff820 80df1c88 80e00700 nt!IovCompleteRequest+0x90
fc91b9bc 804ec04f 81be7f48 81be7db8 806b5524
ftdisk!FtDiskDeviceControl+0xc04
fc91b9cc 8063ca91 81be7f64 81be7f88 80e007d0 nt!IopfCallDriver+0x31
fc91b9f0 80644ea1 80e00718 80e5c170 00560000 nt!IovCallDriver+0x9e
fc91ba00 804ec04f 80e00718 81be7db8 806b5524
nt!ViDriverDispatchGeneric+0x27
fc91ba10 8063ca91 80e00538 81be7db8 00560038 nt!IopfCallDriver+0x31
fc91ba34 baf311e1 80e00538 80e5c4f8 fc91baac nt!IovCallDriver+0x9e
fc91ba78 804ec04f 80e00538 81be7db8 806b5524
MyDriver!CtlDeviceControl+0x19e1
fc91ba88 8063ca91 81be7fac 81be7fd0 80e004d8 nt!IopfCallDriver+0x31
fc91baac 80644ea1 80e00420 80e5c170 80e1b000 nt!IovCallDriver+0x9e
fc91babc 804ec04f 80e00420 81be7db8 806b5524
nt!ViDriverDispatchGeneric+0x27
fc91bacc 8063ca91 81be7ffc 81be7db8 80e1b0d8 nt!IopfCallDriver+0x31
fc91baf0 fc4f3689 80e1b020 80df18a8 00000000 nt!IovCallDriver+0x9e
fc91bb00 804ec04f 80e1b020 81be7db8 806b5524
VolSnap!VolSnapDeviceControl+0x14f
fc91bb10 8063ca91 804ed7c2 fc91bc9f 00000000 nt!IopfCallDriver+0x31
fc91bb34 fc4dcd4f e14562f8 e1452bac e145a408 nt!IovCallDriver+0x9e
fc91bc10 fc4e3500 0091bd64 fc91bc6c fc91bc98
MountMgr!QueryDeviceInformation+0xbb
fc91bca4 fc4e3b3b 80df1e38 fc91bd64 00000000
MountMgr!MountMgrMountedDeviceArrival+0xd8
fc91bcc8 8054c75a fc91bd1c 80df1e38 8063f96d
MountMgr!MountMgrMountedDeviceNotification+0x49
fc91bcf0 805a1908 fc4e3af2 fc91bd1c 80df1e38 nt!PiNotifyDriverCallback+0x6d
fc91bd44 805a1fca e1454e80 8065d578 00000001
nt!IopNotifyDeviceClassChange+0xab
fc91bd74 804ebd08 80e9c0c8 00000000 80e8a8b8 nt!PiWalkDeviceList+0xae
fc91bdac 80559026 80e9c0c8 00000000 00000000 nt!ExpWorkerThread+0xfe
fc91bddc 8050f513 804ebc35 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
FOLLOWUP_IP:
ftdisk!FtDiskDeviceControl+c04
baf84bb6 8bc6 mov eax,esi
SYMBOL_STACK_INDEX: 4
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: ftdisk!FtDiskDeviceControl+c04
MODULE_NAME: ftdisk
IMAGE_NAME: ftdisk.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 3b7d8419
STACK_COMMAND: .trap fffffffffc91b838 ; kb
BUCKET_ID: 0xA_W_ftdisk!FtDiskDeviceControl+c04
IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000004, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: 806474e2, address which referenced memory
- XP with Verifier, I used IoAllocateIrp etc here
my own last output:
send pIrp 81C4CED8 for pDO 80E599E8
IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000004, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: 806474e2, address which referenced memory
CURRENT_IRQL: 2
FAULTING_IP:
nt!IovpCompleteRequest2+123
806474e2 895004 mov [eax+0x4],edx
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xA
LAST_CONTROL_TRANSFER: from 8063cc2f to 806474e2
TRAP_FRAME: fc91b838 – (.trap fffffffffc91b838)
.trap fffffffffc91b838
ErrCode = 00000002
eax=00000000 ebx=81be4db8 ecx=80d9bfe8 edx=80d9beb4 esi=80dff5a0
edi=80e3bb10
eip=806474e2 esp=fc91b8ac ebp=fc91b8d8 iopl=0 nv up ei pl nz ac po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010216
nt!IovpCompleteRequest2+0x123:
806474e2 895004 mov [eax+0x4],edx
ds:0023:00000004=???
.trap
Resetting default scope
STACK_TEXT:
fc91b8d8 8063cc2f 81be4f6f 81be4db8 00000000 nt!IovpCompleteRequest2+0x123
fc91b8f0 804ec0ae 80e00538 81be4db8 fc91b934
nt!IovpLocalCompletionRoutine+0x61
fc91b920 8063d0b6 00000000 00000000 81be4db8 nt!IopfCompleteRequest+0xa0
fc91b988 baf84bb6 80dff820 80df1c88 80e00700 nt!IovCompleteRequest+0x90
fc91b9bc 804ec04f 81be4f48 81be4db8 806b5524
ftdisk!FtDiskDeviceControl+0xc04
fc91b9cc 8063ca91 81be4f64 81be4f88 80e007d0 nt!IopfCallDriver+0x31
fc91b9f0 80644ea1 80e00718 80e5c170 00560000 nt!IovCallDriver+0x9e
fc91ba00 804ec04f 80e00718 81be4db8 806b5524
nt!ViDriverDispatchGeneric+0x27
fc91ba10 8063ca91 81be4db8 80e3bea0 00560038 nt!IopfCallDriver+0x31
fc91ba34 baf2d10a 80e00538 80e5c4f8 fc91baac nt!IovCallDriver+0x9e
fc91ba78 804ec04f 80e00538 81be4db8 806b5524
MyDriver!CtlDeviceControl+0xa4a
fc91ba88 8063ca91 81be4fac 81be4fd0 80e004d8 nt!IopfCallDriver+0x31
fc91baac 80644ea1 80e00420 80e5c170 80e1b000 nt!IovCallDriver+0x9e
fc91babc 804ec04f 80e00420 81be4db8 806b5524
nt!ViDriverDispatchGeneric+0x27
fc91bacc 8063ca91 81be4ffc 81be4db8 80e1b0d8 nt!IopfCallDriver+0x31
fc91baf0 fc4f3689 80e1b020 80df18a8 00000000 nt!IovCallDriver+0x9e
fc91bb00 804ec04f 80e1b020 81be4db8 806b5524
VolSnap!VolSnapDeviceControl+0x14f
fc91bb10 8063ca91 804ed7c2 fc91bc9f 00000000 nt!IopfCallDriver+0x31
fc91bb34 fc4dcd4f e14562f8 e145a2bc e1445a58 nt!IovCallDriver+0x9e
fc91bc10 fc4e3500 0091bd64 fc91bc6c fc91bc98
MountMgr!QueryDeviceInformation+0xbb
fc91bca4 fc4e3b3b 80df1e38 fc91bd64 00000000
MountMgr!MountMgrMountedDeviceArrival+0xd8
fc91bcc8 8054c75a fc91bd1c 80df1e38 8063f96d
MountMgr!MountMgrMountedDeviceNotification+0x49
fc91bcf0 805a1908 fc4e3af2 fc91bd1c 80df1e38 nt!PiNotifyDriverCallback+0x6d
fc91bd44 805a1fca e1454e80 8065d578 00000001
nt!IopNotifyDeviceClassChange+0xab
fc91bd74 804ebd08 80e9d910 00000000 80e8a8b8 nt!PiWalkDeviceList+0xae
fc91bdac 80559026 80e9d910 00000000 00000000 nt!ExpWorkerThread+0xfe
fc91bddc 8050f513 804ebc35 00000001 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
FOLLOWUP_IP:
ftdisk!FtDiskDeviceControl+c04
baf84bb6 8bc6 mov eax,esi
SYMBOL_STACK_INDEX: 4
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: ftdisk!FtDiskDeviceControl+c04
MODULE_NAME: ftdisk
IMAGE_NAME: ftdisk.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 3b7d8419
STACK_COMMAND: .trap fffffffffc91b838 ; kb
BUCKET_ID: 0xA_W_ftdisk!FtDiskDeviceControl+c04
- XP (without Verifier), I used IoAllocateIrp etc here
BAD_POOL_CALLER (c2)
The current thread is making a bad pool request. Typically this is at a
bad IRQL level or double freeing the same allocation, etc.
Arguments:
Arg1: 00000007, Attempt to free pool which was already freed
Arg2: 00000cd4, (reserved)
Arg3: 00000000, Memory contents of the pool block
Arg4: 80e936d8, Address of the block of pool being deallocated
BUGCHECK_STR: 0xc2_7
DEFAULT_BUCKET_ID: DRIVER_FAULT
LAST_CONTROL_TRANSFER: from 805226a5 to 8050d064
IRP_ADDRESS: 80e936d8
STACK_TEXT:
fc8de898 805226a5 00000004 00000000 00000000
nt!RtlpBreakWithStatusInstruction
fc8de8e4 80523255 00000004 00000000 80e936d0 nt!KiBugCheckDebugBreak+0x19
fc8decac 804fc1bb 000000c2 00000007 00000cd4 nt!KeBugCheck2+0x8a7
fc8deccc 8053757e 000000c2 00000007 00000cd4 nt!KeBugCheckEx+0x19
fc8ded14 804db414 80e936d8 00000000 00000000 nt!ExFreePoolWithTag+0x237
fc8ded30 804ed17d 80e936d8 80e92550 80e93718 nt!IopFreeIrp+0xf0
fc8ded80 804ed013 80e93718 fc8dedc8 fc8dedbc nt!IopCompleteRequest+0x316
fc8dedcc 806ba5b0 00000000 00000000 fc8dede4 nt!KiDeliverApc+0xa2
fc8dedcc 806b5333 00000000 00000000 fc8dede4
hal!HalpApcInterrupt2ndEntry+0x31
fc8dee58 804ecfb7 80e93718 80e936d8 00000000 hal!KfLowerIrql+0x43
fc8dee78 804ed19c 80e93718 00000000 00000000 nt!KeInsertQueueApc+0x49
fc8deeac fc4fd10d fc4fffce 80dc6a80 80e936d8 nt!IopfCompleteRequest+0x1d7
fc8deeb0 fc4fffce 80dc6a80 80e936d8 00000000
CLASSPNP!ClassCompleteRequest+0xe
fc8def34 fc51d1a2 80dc6a80 80e937fc 80e936d8
CLASSPNP!ClassDeviceControl+0x6bf
fc8defbc fc4fefd1 80dc6a80 00e936d8 80dc4968 disk!DiskDeviceControl+0xac8
fc8defd4 804ec04f 80dc6a80 80e936d8 804ec022
CLASSPNP!ClassDeviceControlDispatch+0x45
fc8defe4 fc43ab7c 80eaf3b8 00000000 80e02aa8 nt!IopfCallDriver+0x31
fc8df0b8 fc4402ed 80dc6a80 80eaf3b8 8052ab7f
ftdisk!FtpGetVolumeDiskExtents+0x80
fc8df0f4 804ec04f 80eaf500 80eaf3b8 80e029f0
ftdisk!FtDiskDeviceControl+0x33b
fc8df104 fc3ddb7c 80dc4f80 80dc4c78 00000000 nt!IopfCallDriver+0x31
fc8df128 fc3e93fd 00560000 80e029f0 00000000
MyDriver!AuxSendSyncIoCtl+0x15c
fc8df174 fc3eed26 80e3e5a8 00000000 00000000
MyDriver!CtlGetVolumeExtents+0x7d
fc8df1ec fc3f1d7e 80e3e5a8 00000002 80dc53bc
MyDriver!FltInitializeDevice+0x316
fc8df228 804ec04f 80e3e5a8 80dc5208 80e9a908 MyDriver!FltDispatchPnP+0xc3e
fc8df238 fc4f4ad5 80dc53bc 80e9a908 80dc5208 nt!IopfCallDriver+0x31
fc8df268 804ec04f 80e3e250 80dc5208 fc8df2e0 VolSnap!VolSnapPnp+0x4f
fc8df278 8055b50d fc8df2e0 80e3eee8 00000000 nt!IopfCallDriver+0x31
fc8df2a4 805ae0d9 80e3e250 fc8df2bc 00000000 nt!IopSynchronousCall+0xb8
fc8df2e0 805ae214 80e3eee8 fc8df2f0 00010040
nt!PipQueryDeviceCapabilities+0x4c
fc8df330 805053a4 80e3eee8 00000001 c00002ce
nt!IopQueryAndSaveDeviceNodeCapabilities+0x12
fc8df388 805b1d6e 80e3eee8 80e995b8 80dc6360 nt!PipProcessStartPhase3+0x2d1
fc8df5cc 805af082 80e7c4c8 00000000 00000000 nt!PipProcessDevNodeTree+0x18d
fc8df600 805057fa 00000003 00000005 80e64488 nt!PiProcessReenumeration+0x5e
fc8df628 804fe559 00000000 00000000 e13edd68 nt!PipDeviceActionWorker+0x133
fc8df640 80673da2 00000000 00000005 00000000
nt!PipRequestDeviceAction+0x105
fc8df6a4 8067f996 80087000 fc8df7ec 00034000
nt!IopInitializeBootDrivers+0x380
fc8df844 80680727 80087000 00000000 80e92550 nt!IoInitSystem+0x60a
fc8dfdac 80559026 80087000 00000000 00000000 nt!Phase1Initialization+0x83b
fc8dfddc 8050f513 806800f7 80087000 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
FOLLOWUP_IP:
CLASSPNP!ClassCompleteRequest+e
fc4fd10d c20c00 ret 0xc
SYMBOL_STACK_INDEX: c
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: CLASSPNP!ClassCompleteRequest+e
MODULE_NAME: CLASSPNP
IMAGE_NAME: CLASSPNP.SYS
DEBUG_FLR_IMAGE_TIMESTAMP: 3b7dc5af
STACK_COMMAND: kb
BUCKET_ID: 0xc2_7_CLASSPNP!ClassCompleteRequest+e
- XP without Verifier, I used IoBuildSynchronousFsdRequest here
BAD_POOL_CALLER (c2)
The current thread is making a bad pool request. Typically this is at a
bad IRQL level or double freeing the same allocation, etc.
Arguments:
Arg1: 00000007, Attempt to free pool which was already freed
Arg2: 00000cd4, (reserved)
Arg3: 00000000, Memory contents of the pool block
Arg4: 80e936d8, Address of the block of pool being deallocated
BUGCHECK_STR: 0xc2_7
DEFAULT_BUCKET_ID: DRIVER_FAULT
LAST_CONTROL_TRANSFER: from 805226a5 to 8050d064
STACK_TEXT:
fc8debcc 805226a5 00000003 00000000 000000c2
nt!RtlpBreakWithStatusInstruction
fc8dec18 80522dea 00000003 00000001 80e936d0 nt!KiBugCheckDebugBreak+0x19
fc8defe0 804fc1bb 000000c2 00000007 00000cd4 nt!KeBugCheck2+0x43c
fc8df000 8053757e 000000c2 00000007 00000cd4 nt!KeBugCheckEx+0x19
fc8df048 805032cf 80e936d8 00000000 80e43020 nt!ExFreePoolWithTag+0x237
fc8df09c 804ec5b3 80e93604 00000000 80e43e40 nt!IopAllocateIrpPrivate+0xe6
fc8df0d8 804dbd46 00000003 80e43020 80e93548
nt!IoBuildAsynchronousFsdRequest+0x20
fc8df0fc fc3ddc91 00000003 80e43020 80e93548
nt!IoBuildSynchronousFsdRequest+0x1b
fc8df144 fc3f4fae 80e43e40 3b3d8600 00000001
MyDriver!AuxSendSyncReadWrite+0xe1
fc8df17c fc3ef441 80e42ea0 00000000 80db8008
MyDriver!SaSetSGMVolumeAreas+0xfe
fc8df1ec fc3f1c8e 80e42de8 00000002 80db81bc
MyDriver!FltInitializeDevice+0xb21
fc8df228 804ec04f 80e42de8 80db8008 80e09908 MyDriver!FltDispatchPnP+0xc3e
fc8df238 fc4f4ad5 80db81bc 80e09908 80db8008 nt!IopfCallDriver+0x31
fc8df268 804ec04f 80e42a90 80db8008 fc8df2e0 VolSnap!VolSnapPnp+0x4f
fc8df278 8055b50d fc8df2e0 80db9dc8 00000000 nt!IopfCallDriver+0x31
fc8df2a4 805ae0d9 80e42a90 fc8df2bc 00000000 nt!IopSynchronousCall+0xb8
fc8df2e0 805ae214 80db9dc8 fc8df2f0 00010040
nt!PipQueryDeviceCapabilities+0x4c
fc8df330 805053a4 80db9dc8 00000001 c00002ce
nt!IopQueryAndSaveDeviceNodeCapabilities+0x12
fc8df388 805b1d6e 80db9dc8 80e605b8 80e1c360 nt!PipProcessStartPhase3+0x2d1
fc8df5cc 805af082 80e7c4c8 00000000 00000000 nt!PipProcessDevNodeTree+0x18d
fc8df600 805057fa 00000003 00000005 80e64488 nt!PiProcessReenumeration+0x5e
fc8df628 804fe559 00000000 00000000 e13edd68 nt!PipDeviceActionWorker+0x133
fc8df640 80673da2 00000000 00000005 00000000
nt!PipRequestDeviceAction+0x105
fc8df6a4 8067f996 80087000 fc8df7ec 00034000
nt!IopInitializeBootDrivers+0x380
fc8df844 80680727 80087000 00000000 80e92550 nt!IoInitSystem+0x60a
fc8dfdac 80559026 80087000 00000000 00000000 nt!Phase1Initialization+0x83b
fc8dfddc 8050f513 806800f7 80087000 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
FOLLOWUP_IP:
MyDriver!AuxSendSyncReadWrite+e1
fc3ddc91 8bf0 mov esi,eax
SYMBOL_STACK_INDEX: 8
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: MyDriver!AuxSendSyncReadWrite+e1
MODULE_NAME: MyDriver
IMAGE_NAME: MyDriver.SYS
DEBUG_FLR_IMAGE_TIMESTAMP: 4333c6c9
STACK_COMMAND: kb
BUCKET_ID: 0xc2_7_MyDriver!AuxSendSyncReadWrite+e1
- Another one: 80e3ee40 is my IRP, it’s the first one of 4 sent, then the
system crashed:
MULTIPLE_IRP_COMPLETE_REQUESTS (44)
A driver has requested that an IRP be completed (IoCompleteRequest()), but
the packet has already been completed. This is a tough bug to find because
the easiest case, a driver actually attempted to complete its own packet
twice, is generally not what happened. Rather, two separate drivers each
believe that they own the packet, and each attempts to complete it. The
first actually works, and the second fails. Tracking down which drivers
in the system actually did this is difficult, generally because the trails
of the first driver have been covered by the second. However, the driver
stack for the current request can be found by examining the DeviceObject
fields in each of the stack locations.
Arguments:
Arg1: 80e3ee40, Address of the IRP
Arg2: 00000d60
Arg3: 00000000
Arg4: 00000000
IRP_ADDRESS: 80e3ee40
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x44
LAST_CONTROL_TRANSFER: from 805226a5 to 8050d064
STACK_TEXT:
8053b944 805226a5 00000003 00000000 00000044
nt!RtlpBreakWithStatusInstruction
8053b990 80522dea 00000003 80df80e8 80e3ee40 nt!KiBugCheckDebugBreak+0x19
8053bd58 804fc1bb 00000044 80e3ee40 00000d60 nt!KeBugCheck2+0x43c
8053bd78 805135f6 00000044 80e3ee40 00000d60 nt!KeBugCheckEx+0x19
8053bdb0 fc4fd10d fc4fcfb6 80df8030 80e3ee40 nt!IopfCompleteRequest+0x2c4
8053bdb4 fc4fcfb6 80df8030 80e3ee40 00000001
CLASSPNP!ClassCompleteRequest+0xe
8053bddc 804ec0ae 00000000 80dff280 80df8978
CLASSPNP!TransferPktComplete+0x17e
8053be0c fc423eae 80e9b458 80e560e8 00000000 nt!IopfCompleteRequest+0xa0
8053be40 fc424424 80e560e8 80dff280 8053bebb
atapi!IdeProcessCompletedRequest+0x698
8053bebc 804f02eb 80e560a4 80e56030 00000000
atapi!IdePortCompletionDpc+0x202
8053bed0 804f027a 00000000 0000000e 00000000 nt!KiRetireDpcList+0x30
8053bed4 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x26
FOLLOWUP_IP:
CLASSPNP!ClassCompleteRequest+e
fc4fd10d c20c00 ret 0xc
SYMBOL_STACK_INDEX: 5
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: CLASSPNP!ClassCompleteRequest+e
MODULE_NAME: CLASSPNP
IMAGE_NAME: CLASSPNP.SYS
DEBUG_FLR_IMAGE_TIMESTAMP: 3b7dc5af
STACK_COMMAND: kb
BUCKET_ID: 0x44_CLASSPNP!ClassCompleteRequest+e
kind regards
Else
|---------±-------------------------------->
| | “Peter Wieland” |
| | | | osoft.com> |
| | Sent by: |
| | bounce-221304-16691@li|
| | sts.osr.com |
| | |
| | |
| | 09/29/2005 06:49 PM |
| | Please respond to |
| | “Windows System |
| | Software Devs Interest|
| | List” |
|---------±-------------------------------->
>-----------------------------------------------------------------------------------------------------------|
| |
| To: “Windows System Software Devs Interest List” |
| cc: |
| Subject: RE: [ntdev] LookAsideList and sending IRPs (Unsigned Mail) |
>-----------------------------------------------------------------------------------------------------------|
Lookaside lists are just lists of memory allocated from pool. There’s
no difference in the memory you get back, but you need to be more
careful about not accessing the memory after you’ve put it back on the
list.
My first guess is that you’re writing to the memory after it’s on the
list, or that you’re in some other way corrupting the list. Something
that the pool system wouldn’t detect, but which becomes much more
obvious when you reuse a small set of memory allocations.
Have you tried running with the driver verfier enabled?
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Else Kluger
Sent: Thursday, September 29, 2005 2:50 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] LookAsideList and sending IRPs
Hi all,
in my Disk UpperFillter I try to read disk sectors synchronously sending
my own IRPs (either by using IoBuildSynchronousFsdRequest or by
IoAllocateIRp, IoSetCompletion …).
I have a problem with the buffer I send along with the Irp.
pIrp = IoBuildSynchronousFsdRequest
( IRP_MJ_READ
pDeviceObject,
pBuffer,
ulLength,
&Offset,
&NotifyEvent,
&iosb )
It all works fine as long as pBuffer points to memory allocated by
ExAllocatePoolWithTag or some local declaration, but it fails later, in
various ways (=BSODs) if I use ExAllocateFromNPagedLookasideList.
It’s XP and W2KSP4, all is runnning on PASSIVE_LEVEL => can’t I use
LookAsideLists for sending own IRPs ?
kind regards
Else
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com