ExDeleteResourceList does not free the memory for the structure, it just
cleans up the structure and any associated kernel bookkeeping for it.
From the DDK docs:
“After calling ExDeleteResourceLite, the caller can free the memory it
allocated for its resource.”
Since deleting the device is the equivalent of freeing the device
extension, which in turn holds the ERESOURCE, yes, you need to make the
API call. In general, if there is a delete call that matches the init
call, it would make sense that the delete call should be made.
BTW, the same logic would apply to a lookaside list as well (embedded as
a part of your device extension or maybe as a global).
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Harish Arora
Sent: Tuesday, August 30, 2005 12:49 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] processing IRP_MN_REMOVE_DEVICE
Here’s a follow up question regarding this exercise.
I’m now sending the IRP_MN_REMOVE_DEVICE Irp down asynchronously and it
works fine.
However I noticed another possible reason for the crash.
I have a ERESOURCE in my deviceExtension. I use ExInitializeResourceLite
in my AddDevice to initialize it. If I delete (ExDeleteResourceLite)
this ERESOURCE object before I detach and delete the device (in
IRP_MN_REMOVE_DEVICE), everything works fine…but If I don’t delete the
ERESOURCE object, I get following crash.
Is it required to delete the ERESOURCE (ExDeleteResourceLite) before I
delete the device even though it’s physically embedded in my
deviceExtension. ?
!analyze -v out put =>
2: kd> !analyze -v
************************************************************************
*******
*
*
* Bugcheck Analysis
*
*
*
************************************************************************
*******
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: 00001163, (reserved)
Arg3: 8511580f, Memory contents of the pool block
Arg4: 85176a48, Address of the block of pool being deallocated
Debugging Details:
POOL_ADDRESS: 85176a48 Nonpaged pool
FREED_POOL_TAG: Devi
BUGCHECK_STR: 0xc2_7_Devi
DEFAULT_BUCKET_ID: DRIVER_FAULT
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from 8087a46f to 80833f96
STACK_TEXT:
f7902714 8087a46f 00000003 00000000 000000c2
nt!RtlpBreakWithStatusInstruction
f7902760 8087b236 00000003 00000001 85176a40
nt!KiBugCheckDebugBreak+0x19
f7902af8 8087b6be 000000c2 00000007 00001163 nt!KeBugCheck2+0x5b2
f7902b18 8089c8f4 000000c2 00000007 00001163 nt!KeBugCheckEx+0x1b
f7902b80 8092abc9 85176a48 e9766544 86793ca0 nt!ExFreePoolWithTag+0x477
f7902b9c 8092ac40 85176a48 00000000 86793ca0 nt!ObpFreeObject+0x192
f7902bb0 80840172 85176a60 00000000 fecd1a10
nt!ObpRemoveObjectRoutine+0xe6
f7902bd0 8080bf10 00000000 e116d1b0 00000001
nt!ObfDereferenceObject+0x67
f7902bf0 808e149b e249b7c8 00000018 e116d1b0
nt!IopRemoveLockedDeviceNode+0x1de
f7902c08 808e18cc 85a6f3e0 00000002 e116d1b0
nt!IopDeleteLockedDeviceNode+0x50
f7902c3c 8098fd1e 8511e030 0216d1b0 00000002
nt!IopDeleteLockedDeviceNodes+0x3f
f7902c6c 8098fe32 8512cb60 80a79150 85176b28
nt!IopDelayedRemoveWorker+0x4b
f7902c84 80859f2d 8511e030 00000001 e1798a50
nt!IopChainDereferenceComplete+0xdb
f7902cb4 809580f9 859f3e78 00000001 00000000
nt!IopNotifyPnpWhenChainDereferenced+0xc9
f7902d40 808e19b6 f7902d7c 868d5d4c e1798a50
nt!PiProcessQueryRemoveAndEject+0xa33
f7902d5c 808e7879 f7902d7c 867c18d0 808b70dc
nt!PiProcessTargetDeviceEvent+0x2a
f7902d80 8083f72e 857e6b20 00000000 867c18d0 nt!PiWalkDeviceList+0x1d2
f7902dac 8092ccff 857e6b20 00000000 00000000 nt!ExpWorkerThread+0xeb
f7902ddc 80841a96 8083f671 00000001 00000000
nt!PspSystemThreadStartup+0x2e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
FOLLOWUP_IP:
nt!ExFreePoolWithTag+477
8089c8f4 cc int 3
SYMBOL_STACK_INDEX: 4
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: nt!ExFreePoolWithTag+477
MODULE_NAME: nt
IMAGE_NAME: ntkrnlmp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 42435e60
STACK_COMMAND: kb
BUCKET_ID: 0xc2_7_Devi_nt!ExFreePoolWithTag+477
Followup: MachineOwner
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-218558-
xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, August 29, 2005 10:51 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] processing IRP_MN_REMOVE_DEVICE
The pattern of
- cleaning up
- sending the irp
- detaching/deleting
Is what the DDK says you should do. The bugchecks you are referring
to
are pool errors, not pnp handling errors. Are you enabling driver
verifier on your driver?
The return status from IoCallDriver is the driver verifier making sure
that you do not inspect the return status (like expecting
STATUS_SUCCESS) explicitly and that you use the NT_SUCCESS macro
(which
0x4 would succeed). The actual return value is not important, it is
important that you use the correct macros to evaluate it.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Harish Arora
Sent: Monday, August 29, 2005 9:58 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] processing IRP_MN_REMOVE_DEVICE
Forgot to mention a couple of things.
- OS is server 2003 std + SP1
- the return status from lower driver (volsnap) is always 0x4.
What is this status ?(STATUS_WAIT_1 |STATUS_WAIT_3) ?
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:bounce-218544-
> xxxxx@lists.osr.com] On Behalf Of Harish Arora
> Sent: Monday, August 29, 2005 9:46 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] processing IRP_MN_REMOVE_DEVICE
>
> Hi,
> I have a Upper volume filter in which I was handling
> IRP_MN_REMOVE_DEVICE using following logic
> 1. IoReleaseRemoveLockAndWait. => synchronize with other dispatch
calls
> 2. Clean up resources allocated|used by my device.
> 3. forward the irp to next driver on the stack.
> 4. detach and delete device.
> 5. return status from step 3.
>
> I tried using diskpart script to create and delete partitions in a
loop.
> I was able to run the script a few times but usually it ended up
with
a
> crash. Crash symptoms vary a lot but mostly show Bug Check 0x19:
> BAD_POOL_HEADER or Bug Check 0xC2: BAD_POOL_CALLER. For the life of
me
I
> could not figure out the reason for corruption. I used pooltag.exe
to
> make sure that allocations and de-allocations match up. Verifier
also
> does not show any pool corruption.
> All my tests are on a MP machine.
>
> Then I refered to diskperf sample in ddk (3790) and it passes the
IRP
> down synchronously and does detach and delete after the IRP
completes
in
> the stack below. So essentially, it does step 3 of above mentioned
> workflow synchronously.
>
> What is the right way to detach and delete the device. Should it be
done
> asynchronously or synchronously?. Documentation tells me that I was
> doing it right.
>
> I understand that if I do it synchronously, the lower device will
not
go
> away until I detach from it (thereby decreasing it’s refcnt).
>
> Thanks for the help
> Harish
>
>
>
>
>
>
> If art interprets our dreams, the computer executes them in the
guise
of
> programs!
>
>
> —
> 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
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
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
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