Unload() vs IRP_MN_REMOVE_DEVICE

OSR_Community_User

Hello,

In my Win2K Bus Driver's DriverEntry(), I allocate some contiguous chunks
of memory using MmAllocateContiguousMemory(). Do I need to free this
memory in Unload() or when I get IRP_MN_REMOVE_DEVICE for the Bus FDO ?
Which is better and why ?

Thanks for your time and help!
Puja

OSR_Community_User

My rule of thumb has been if done in driver entry, undo it in unload. If
done in AddDevice, undo it RemoveDevice. It may not work for you, but it
has worked for me.

Mark J. Cariddi
Consulting Associate
[email protected]

OSR Open Systems Resources, Inc.
105 Route 101A, Suite 19
Amherst, New Hampshire 03031
603/595-6500
603/595-6503 Fax
http://www.osr.com

****************************************
The definitive book on writing Windows NT
device drivers, "Windows NT Device Driver
Development" by OSR consulting partners
Peter Viscarola and Tony Mason, is now
available for ordering.
****************************************





-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Thursday, April 27, 2000 1:57 PM
To: NT Developers Interest List
Subject: [ntdev] Unload() vs IRP_MN_REMOVE_DEVICE


Hello,

In my Win2K Bus Driver's DriverEntry(), I allocate some contiguous chunks
of memory using MmAllocateContiguousMemory(). Do I need to free this
memory in Unload() or when I get IRP_MN_REMOVE_DEVICE for the Bus FDO ?
Which is better and why ?

Thanks for your time and help!
Puja

---
You are currently subscribed to ntdev as: [email protected]
To unsubscribe send a blank email to $subst('Email.Unsub')

OSR_Community_User

> In my Win2K Bus Driver's DriverEntry(), I allocate some contiguous chunks
> of memory using MmAllocateContiguousMemory(). Do I need to free this
> memory in Unload() or when I get IRP_MN_REMOVE_DEVICE for the Bus FDO ?

If you allocate in DriverEntry - it must be freed in Unload.
If you allocate in AddDevice - it must be freed in MN_REMOVE_DEVICE
path somewhere near the device object destruction.

Max

OSR_Community_User

From: "Maxim S. Shatskih" <[email protected]>
Sent: Thursday, May 04, 2000 6:25 PM


> > In my Win2K Bus Driver's DriverEntry(), I allocate some contiguous
chunks
> > of memory using MmAllocateContiguousMemory(). Do I need to free this
> > memory in Unload() or when I get IRP_MN_REMOVE_DEVICE for the Bus FDO ?
>
> If you allocate in DriverEntry - it must be freed in Unload.
> If you allocate in AddDevice - it must be freed in MN_REMOVE_DEVICE
> path somewhere near the device object destruction.

However, if you initialize important stuff in DriverEntry(), it's very
dangerous to use DriverUnload() to perform the associated cleanup in a WDM
driver that will be run on Windows 98.

For some reason known only to Microsoft, Windows 98 calls DriverUnload() in
response to a driver's IoDeleteDevice() call for its *final* DEVICE_OBJECT
(that is, the DEVICE_OBJECT for which the deletion causes the associated
DRIVER_OBJECT's 'DeviceObject' member to return to NULL). In other words,
Unload() will execute *during* IoDeleteDevice() on Windows 98. This can
have some very dire consequences.

For example, after IoDeleteDevice() returns in your driver's
IRP_MN_REMOVE_DEVICE dispatch code path, you must be very careful not to
touch whatever stuff DriverEntry() initialized in the portion of the path
that returns back to the I/O Manager (because all the stuff may have already
been "unloaded").

On Windows 2000, DriverUnload() will not be called during IoDeleteDevice().
Instead, if the system decides to unload your driver after
IRP_MN_REMOVE_DEVICE, it will do so *after* the dispatch code path has
returned all the way back to the I/O Manager.

Also, because on Windows 98 calling IoDeleteDevice() will effectively cause
a driver to recurse back into itself, it is impossible to call
IoDeleteDevice() during DriverUnload() (should you ever need to for some
non-PnP device your driver may need). Due to the order that things occur
within IoDeleteDevice() -- and again for reasons known only to Microsoft --
this will generate infinite recursion (DriverUnload -> IoDeleteDevice ->
DriverUnload -> IoDeleteDevice -> ... ), eventually blowing the kernel
stack.

- Matt