Driver Verifier - The driver is unloading without first freeing all its memory pools

NTDEV
1

Hi,

I wrote a code of two different drivers.
Driver “D1” is a driver that loads on boot time and
never unloads.
Driver “D2” is a driver that loads on demand.
a while after Driver “D2” loads, it creates a device
(IoCreateDevice) and allocates some memory for it’s
device extension.
The device pointer is transferred to “Driver D2” that
holds it and handle it after Driver “D1” unloads.
From the experience until now, there is no problem
with this flow.
I ran Drvier Verifier and it The problem is the the
driver verifier raises “Bug Check 0xC4:
DRIVER_VERIFIER_DETECTED_VIOLATION” with first
parameter 60 “The driver is unloading without first
freeing all its memory pools”
This is very reasonable since “D1” unloads without
freeing the memory it allocated for device extension
of the device it created.
From the other hand - the device created still exists
so no reason to free the memory.
My questions:

  1. Is there a real problem or it is just that the
    Verifier “can not know” that the memory allocated is
    for a device still exists (until system shutdown)
  2. Is there any way to tell the Driver Verifier to
    “acknowledge” specific issues like this

Thanks in advance

Alon

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

2

Why not have the unloadable driver do the allocation instead? Then the
unanswerable question ‘is there a real problem?’ will remain unanswered and
your D2 driver will pass driver verifier.

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alon
Sent: Sunday, December 11, 2005 5:34 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Driver Verifier - The driver is unloading
without first freeing all its memory pools

Hi,

I wrote a code of two different drivers.
Driver “D1” is a driver that loads on boot time and never unloads.
Driver “D2” is a driver that loads on demand.
a while after Driver “D2” loads, it creates a device
(IoCreateDevice) and allocates some memory for it’s device extension.
The device pointer is transferred to “Driver D2” that holds
it and handle it after Driver “D1” unloads.
From the experience until now, there is no problem with this flow.
I ran Drvier Verifier and it The problem is the the driver
verifier raises “Bug Check 0xC4:
DRIVER_VERIFIER_DETECTED_VIOLATION” with first parameter 60
“The driver is unloading without first freeing all its memory pools”
This is very reasonable since “D1” unloads without freeing
the memory it allocated for device extension of the device it created.
From the other hand - the device created still exists so no
reason to free the memory.
My questions:

  1. Is there a real problem or it is just that the Verifier
    “can not know” that the memory allocated is for a device
    still exists (until system shutdown) 2. Is there any way to
    tell the Driver Verifier to “acknowledge” specific issues like this

Thanks in advance

Alon

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection
around http://mail.yahoo.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@hollistech.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

There is no way to tell driver verifier about this. The design is
fragile and should be fixed. The assumption that the driver will not
unload may change in the future, thus breaking this design.

The best way to fix this is to pass a function pointer which will do the
allocation to the driver which is allocating the memory. This way, the
allocation is local to the driver that is *not* unloading and is bound
to the lifetime of the devobj which is sticking around. I am not sure
if this is D2 or d1 b/c you say that D1 will not unload and then you
state that D1 unloads.

d

– I can spell, I just can’t type.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alon
Sent: Sunday, December 11, 2005 2:34 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Driver Verifier - The driver is unloading without first
freeing all its memory pools

Hi,

I wrote a code of two different drivers.
Driver “D1” is a driver that loads on boot time and
never unloads.
Driver “D2” is a driver that loads on demand.
a while after Driver “D2” loads, it creates a device
(IoCreateDevice) and allocates some memory for it’s
device extension.
The device pointer is transferred to “Driver D2” that
holds it and handle it after Driver “D1” unloads.
From the experience until now, there is no problem
with this flow.
I ran Drvier Verifier and it The problem is the the
driver verifier raises “Bug Check 0xC4:
DRIVER_VERIFIER_DETECTED_VIOLATION” with first
parameter 60 “The driver is unloading without first
freeing all its memory pools”
This is very reasonable since “D1” unloads without
freeing the memory it allocated for device extension
of the device it created.
From the other hand - the device created still exists
so no reason to free the memory.
My questions:

  1. Is there a real problem or it is just that the
    Verifier “can not know” that the memory allocated is
    for a device still exists (until system shutdown)
  2. Is there any way to tell the Driver Verifier to
    “acknowledge” specific issues like this

Thanks in advance

Alon

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

I’m sorry, The correct sentence in my original email
should be:

“This is very reasonable since “D2” unloads without
freeing the memory it allocated for device extension
of the device it created.”

Anyway, I understand that the best solution you
suggest is that
“D2” will use “D1” to allcoate memory and than the
verifier will not complain, anyhow, as far as I can
understand, if “D1” keep not unloading, there is no
real problem with the current flow.

“Doron Holan” wrote in
message news:xxxxx@ntdev…
There is no way to tell driver verifier about this.
The design is
fragile and should be fixed. The assumption that the
driver will not
unload may change in the future, thus breaking this
design.

The best way to fix this is to pass a function pointer
which will do the
allocation to the driver which is allocating the
memory. This way, the
allocation is local to the driver that is not
unloading and is bound
to the lifetime of the devobj which is sticking
around. I am not sure
if this is D2 or d1 b/c you say that D1 will not
unload and then you
state that D1 unloads.

d

– I can spell, I just can’t type.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf
Of Alon
Sent: Sunday, December 11, 2005 2:34 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Driver Verifier - The driver is
unloading without first
freeing all its memory pools

Hi,

I wrote a code of two different drivers.
Driver “D1” is a driver that loads on boot time and
never unloads.
Driver “D2” is a driver that loads on demand.
a while after Driver “D2” loads, it creates a device
(IoCreateDevice) and allocates some memory for it’s
device extension.
The device pointer is transferred to “Driver D2” that
holds it and handle it after Driver “D1” unloads.
From the experience until now, there is no problem
with this flow.
I ran Drvier Verifier and it The problem is the the
driver verifier raises “Bug Check 0xC4:
DRIVER_VERIFIER_DETECTED_VIOLATION” with first
parameter 60 “The driver is unloading without first
freeing all its memory pools”
This is very reasonable since “D1” unloads without
freeing the memory it allocated for device extension
of the device it created.
From the other hand - the device created still exists
so no reason to free the memory.
My questions:
1. Is there a real problem or it is just that the
Verifier “can not know” that the memory allocated is
for a device still exists (until system shutdown)
2. Is there any way to tell the Driver Verifier to
“acknowledge” specific issues like this

Thanks in advance

Alon


Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam
protection around
http://mail.yahoo.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@microsoft.com
To unsubscribe send a blank email to
xxxxx@lists.osr.com
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam
protection around
http://mail.yahoo.com

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

5

This is still an issue since the machine will crash when driver verifier
is enabled on your driver. You can personally justify this by saying
you won’t enable DV when testing (and you will lose valuable feedback),
but once you release your driver into the field, you cannot make this
assumption. The company that installs your driver might need to enable
DV on their system for all drivers and they will bugcheck on this issue.
They will call you, demand a fix the next day and then you are going to
have to fix this. In the end, this is a bad practice and you should fix
it now before any of your customers see it.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alon
Sent: Monday, December 12, 2005 12:22 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Driver Verifier - The driver is unloading without
first freeing all its memory pools

I’m sorry, The correct sentence in my original email
should be:

“This is very reasonable since “D2” unloads without
freeing the memory it allocated for device extension
of the device it created.”

Anyway, I understand that the best solution you
suggest is that
“D2” will use “D1” to allcoate memory and than the
verifier will not complain, anyhow, as far as I can
understand, if “D1” keep not unloading, there is no
real problem with the current flow.

“Doron Holan” wrote in
message news:xxxxx@ntdev…
There is no way to tell driver verifier about this.
The design is
fragile and should be fixed. The assumption that the
driver will not
unload may change in the future, thus breaking this
design.

The best way to fix this is to pass a function pointer
which will do the
allocation to the driver which is allocating the
memory. This way, the
allocation is local to the driver that is not
unloading and is bound
to the lifetime of the devobj which is sticking
around. I am not sure
if this is D2 or d1 b/c you say that D1 will not
unload and then you
state that D1 unloads.

d

– I can spell, I just can’t type.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf
Of Alon
Sent: Sunday, December 11, 2005 2:34 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Driver Verifier - The driver is
unloading without first
freeing all its memory pools

Hi,

I wrote a code of two different drivers.
Driver “D1” is a driver that loads on boot time and
never unloads.
Driver “D2” is a driver that loads on demand.
a while after Driver “D2” loads, it creates a device
(IoCreateDevice) and allocates some memory for it’s
device extension.
The device pointer is transferred to “Driver D2” that
holds it and handle it after Driver “D1” unloads.
From the experience until now, there is no problem
with this flow.
I ran Drvier Verifier and it The problem is the the
driver verifier raises “Bug Check 0xC4:
DRIVER_VERIFIER_DETECTED_VIOLATION” with first
parameter 60 “The driver is unloading without first
freeing all its memory pools”
This is very reasonable since “D1” unloads without
freeing the memory it allocated for device extension
of the device it created.
From the other hand - the device created still exists
so no reason to free the memory.
My questions:
1. Is there a real problem or it is just that the
Verifier “can not know” that the memory allocated is
for a device still exists (until system shutdown)
2. Is there any way to tell the Driver Verifier to
“acknowledge” specific issues like this

Thanks in advance

Alon


Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam
protection around
http://mail.yahoo.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@microsoft.com
To unsubscribe send a blank email to
xxxxx@lists.osr.com
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam
protection around
http://mail.yahoo.com

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

6

Alon wrote:

My questions:

  1. Is there a real problem or it is just that the
    Verifier “can not know” that the memory allocated is
    for a device still exists (until system shutdown)
  2. Is there any way to tell the Driver Verifier to
    “acknowledge” specific issues like this

Recently I was discussing a similar question and I
suggested that the driver needing to unload without
freeing allocated memory could use a System Worker
thread to do the allocation, hoping that Verifier
would see the allocation as belonging to System and
thus not a problem.

Has anyone tried this, and does it work (or will work
at least until the next release of DV improves it’s
tracking abilities and begins to catch it)? Inquiring
mind wants to know…

Jerry

7

DV works by changing the import of ExAllocatePoolXxx to another function
which captures the caller. It does not matter the context in which you
allocate pool, it will be tracked. DV will not be updated to ignore
abandoned allocations on unload.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jerry Schneider
Sent: Monday, December 12, 2005 4:59 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Driver Verifier - The driver is unloading without
first freeing all its memory pools

Alon wrote:

My questions:

  1. Is there a real problem or it is just that the
    Verifier “can not know” that the memory allocated is
    for a device still exists (until system shutdown)
  2. Is there any way to tell the Driver Verifier to
    “acknowledge” specific issues like this

Recently I was discussing a similar question and I
suggested that the driver needing to unload without
freeing allocated memory could use a System Worker
thread to do the allocation, hoping that Verifier
would see the allocation as belonging to System and
thus not a problem.

Has anyone tried this, and does it work (or will work
at least until the next release of DV improves it’s
tracking abilities and begins to catch it)? Inquiring
mind wants to know…

Jerry

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

8

Drivers that do not free allocations are then, by their very nature
unloadable. For example, this applies to physical media file system
drivers because of the shared allocation responsibilities for Vpb
structures (which are allocated by the I/O manager and/or the physical
media file system drivers.)

In general, though, I agree with the consensus opinion here: it is not a
good architecture to allocate in one driver and free in another driver.
While I can point to the Vpb management as an aberration, it is
certainly *not* the norm and should not be an element of a well designed
driver. As several people suggested, you are much better off to build
an interface for allocating buffers so they are always managed within
the context of the same driver. Since this isn’t an onerous task, it
seems it is something you should consider including in your driver.

Regards,

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, December 13, 2005 12:12 AM
To: ntdev redirect
Subject: RE: [ntdev] Driver Verifier - The driver is unloading without
first freeing all its memory pools

DV works by changing the import of ExAllocatePoolXxx to another function
which captures the caller. It does not matter the context in which you
allocate pool, it will be tracked. DV will not be updated to ignore
abandoned allocations on unload.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jerry Schneider
Sent: Monday, December 12, 2005 4:59 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Driver Verifier - The driver is unloading without
first freeing all its memory pools

Alon wrote:

My questions:

  1. Is there a real problem or it is just that the
    Verifier “can not know” that the memory allocated is
    for a device still exists (until system shutdown)
  2. Is there any way to tell the Driver Verifier to
    “acknowledge” specific issues like this

Recently I was discussing a similar question and I
suggested that the driver needing to unload without
freeing allocated memory could use a System Worker
thread to do the allocation, hoping that Verifier
would see the allocation as belonging to System and
thus not a problem.

Has anyone tried this, and does it work (or will work
at least until the next release of DV improves it’s
tracking abilities and begins to catch it)? Inquiring
mind wants to know…

Jerry

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as: xxxxx@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

9

Tony Mason wrote:

In general, though, I agree with the consensus opinion here: it is not a
good architecture to allocate in one driver and free in another driver.

Agreed! My discussion was initiated by the question of how, without
forcing a reboot, to upgrade a driver that can not be unloaded because
a small amount of nonpaged data alloc’ed by the driver was still being
referenced by another driver or had some code targeted as a callback.

The two choices seem to be hotpatching the in-memory driver or to let
some data and code be allocated in a way that DV wouldn’t object to.
Unfortunately, as newer hardware and the OS embraces NoExecute (i.e.
non-writable code), hot-patching appears doomed for in-memory updating
of kernel-mode driver code.

The only alternative I see is to load a small driver that holds only
the “unloadable” data and callback code stubs; our main driver then
locates this unloadable data and referenced code arena at startup,
and can put that data & code in “stasis” before it is unloaded. An
upgraded driver then wakes up the code/data in the minidriver.

My $0.2: It’s too bad that some sloppy programming that allows buffer
overflows is now forcing the OS to enforce nonwritable code, making
my otherwise careful coding into a complex mess of workarounds. I
wonder if Microsoft will continue to promote kernel hot-patching for
non-rebootable upgrades, given the constraints of nonwritable kernel
code?

Jerry

10

> This is very reasonable since “D1” unloads without

freeing the memory it allocated for device extension
of the device it created.

You cannot unload the driver and retain the device object.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

11

> Recently I was discussing a similar question and I

suggested that the driver needing to unload without
freeing allocated memory could use a System Worker
thread to do the allocation, hoping that Verifier
would see the allocation as belonging to System and
thus not a problem.

Has anyone tried this, and does it work (or will work

Why even trying this? this is a bad design.

Instead of calling ExAllocateXxx in Driver A (unloadable), call the exported
function of DriverB!MyAlloc, where Driver B is not unloadable.

DriverB!MyAlloc is just a wrapper around ExAllocateXxx.

If the entity you’re allocating is the device object - then use the usual
port-miniport model, where the unloadable miniport is the owner of the DO (the
DO is created using the miniport’s driver object).

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

12

> The only alternative I see is to load a small driver that holds only

the “unloadable” data and callback code stubs; our main driver then
locates this unloadable data and referenced code arena at startup,
and can put that data & code in “stasis” before it is unloaded. An
upgraded driver then wakes up the code/data in the minidriver.

Why? rename ExAllocatePool in unloadable driver to MyAlloc or such, and write
the MyAlloc function in non-unloadable driver which will be a wrapper around
ExAllocatePool.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com