IRP_MJ_CLOSE, IRP_MJ_CLEANUP and mutexes

NTDEV
1

Hi There,

A WDM driver which I have inherited releases some resources in response to IRP_MJ_CLOSE. We haven?t had any problems with this device driver for many years and it has been deployed on XP64 for some time. On windows 7 64-bit when we kill a process that has a handle open to the driver using task manager the wait on a mutex (KeWaitForSingleObject) fails. I have a time out of 1 second and it returns STATUS_ALERTED which is unexpected. The same call to KeWaitForSingleObject on XP64 returns STATUS_SUCCESS as I would expect.

I have shown that the problem is not specific to one mutex object but all. I can only assume that the mutex object is no longer valid for some reason but I can confirm that the mutex is not being destroyed programmatically by code in the driver.

We run into the same issue when the system shuts down.

Any pointers would be appreciated.

Many thanks,

Mike D

2

wrote in message news:xxxxx@ntdev…
>I have a time out of 1 second and it returns STATUS_ALERTED which is
>unexpected. The same call to KeWaitForSingleObject on >XP64 returns
>STATUS_SUCCESS as I would expect.

Are you waiting with Alertable set to TRUE? If so then you have to handle
this status coming back. If you don’t want to deal with it then set
Alertable to FALSE.

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntdev…
> Hi There,
>
> A WDM driver which I have inherited releases some resources in response to
> IRP_MJ_CLOSE. We haven?t had any problems with this device driver for many
> years and it has been deployed on XP64 for some time. On windows 7 64-bit
> when we kill a process that has a handle open to the driver using task
> manager the wait on a mutex (KeWaitForSingleObject) fails. I have a time
> out of 1 second and it returns STATUS_ALERTED which is unexpected. The
> same call to KeWaitForSingleObject on XP64 returns STATUS_SUCCESS as I
> would expect.
>
> I have shown that the problem is not specific to one mutex object but all.
> I can only assume that the mutex object is no longer valid for some reason
> but I can confirm that the mutex is not being destroyed programmatically
> by code in the driver.
>
> We run into the same issue when the system shuts down.
>
> Any pointers would be appreciated.
>
> Many thanks,
>
> Mike D
>
>

3

Thanks Scott,
Yes Alertable is set to true and I’m handling it in the instance that’s giving me trouble and it’s returning STATUS_ALERTED. Now at the moment I’m using this information to generate a bug check but I intend to make changes throughout the driver to ensure that Alertable is set to true for all calls that do not handle the return code properly. Am I likely to see any adverse effect from making this switch, as far as I can tell from the documentation making the switch to true is the correct thing to do.
Mike D

4

wrote in message news:xxxxx@ntdev…
>Am I likely to see any adverse effect from making this switch, as far as I
>can tell from the documentation making the >switch to true is the correct
>thing to do.

Did you mean, “making the switch to false”? If so, you shouldn’t see any
problems, it just means your thread won’t be woken up as a result of someone
calling ZwAlertThread on it.

-scott

–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

wrote in message news:xxxxx@ntdev…
> Thanks Scott,
> Yes Alertable is set to true and I’m handling it in the instance that’s
> giving me trouble and it’s returning STATUS_ALERTED. Now at the moment I’m
> using this information to generate a bug check but I intend to make
> changes throughout the driver to ensure that Alertable is set to true for
> all calls that do not handle the return code properly. Am I likely to see
> any adverse effect from making this switch, as far as I can tell from the
> documentation making the switch to true is the correct thing to do.
> Mike D
>

5

Sorry, yes I meant “making the switch to false”.

I’ve now made the change throughout our code and have begun testing. The wait on the mutex that was stalling then returning STATUS_ALERTED now drops straight through as it should do in response to IRP_MJ_CLOSE initiated by task manager killing the process.

It’s still not clear to me why we get a difference in behaviour between XP64 and Windows 7. That is, the WaitForSingleObject blocks sometimes on Windows 7 when servicing IRP_MJ_CLOSE but never on XP and Win 2000.

Mike D

6

I guess we could look it up, but changes from version to version like this really aren’t unexpected. KeWaitForSingleObject is working as specified, it’s just that the overall environment changed and your wait is being triggered. If you (er, the original developer) didn’t specifically want to be awoken on alerts, he/she should have set Alertable to FALSE.

So, what you’re seeing is effectively a latent bug in the code. The Alertable parameter is famous for this (most people don’t really know what it is and just set it to TRUE)… the other parameter that comes to mind on this function that gives unsuspecting devs a good chance to screw-up is WaitMode. You want KernelMode. Period.

Peter
OSr

7

w7 removed the global dispatcher lock so the timing could have changed.

d

dent from a phpne with no keynoard

-----Original Message-----
From: xxxxx@osr.com
Sent: July 22, 2010 6:12 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] IRP_MJ_CLOSE, IRP_MJ_CLEANUP and mutexes



I guess we could look it up, but changes from version to version like this really aren’t unexpected. KeWaitForSingleObject is working as specified, it’s just that the overall environment changed and your wait is being triggered. If you (er, the original developer) didn’t specifically want to be awoken on alerts, he/she should have set Alertable to FALSE.

So, what you’re seeing is effectively a latent bug in the code. The Alertable parameter is famous for this (most people don’t really know what it is and just set it to TRUE)… the other parameter that comes to mind on this function that gives unsuspecting devs a good chance to screw-up is WaitMode. You want KernelMode. Period.

Peter
OSr

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

8

> So, what you’re seeing is effectively a latent bug in the code. The Alertable parameter is famous for

this (most people don’t really know what it is and just set it to TRUE)… the other parameter that comes
to mind on this function that gives unsuspecting devs a good chance to screw-up is WaitMode. You
want KernelMode. Period.

FALSE+KernelMode - the wait cannot be interrupted by any APCs, and by process killing too. This is the usual wait in a driver.

IIRC FALSE+UserMode - then wait can be interrupted by the process killing sequence, and will return STATUS_USER_APC in this case. It cannot be interrupted by other user APCs.

TRUE+KernelMode - the wait can be interrupted by kernel APCs. In case of such interruption, it will return STATUS_ALERTED.

TRUE+UserMode - the wait can be interrupted by any APCs and by the process killing sequence.

In case of STATUS_ALERTED or STATUS_USER_APC, the caller must return from all functions in the code path ASAP back to the topmost level from where it was called.

User-mode wait with Alertable set to FALSE is mapped to FALSE+UserMode. It cannot be interrupted by user APC, but can be interrupted by process killing.

User-mode wait with Alertable set to TRUE is mapped to TRUE+UserMode. It can be interrupted by user APC, and also can be interrupted by process killing.

Also note that specifying UserMode will make the kernel stack pageable.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com