Possible bug in Oney's Generic.sys?

OSR_Community_User · February 22, 2005, 4:41pm

Hi All,

I am relatively new to driver development and have been given the
assignment of taking over maintenance of driver written by a former
co-worker, so any help or advice anyone can give me as I bootstrap
myself would be greatly appreciated!

I am now trying to install the driver under a checked version of the XP
kernel (sp1), and keep hitting an ASSERT within a system call, which
appears to be caused by the redistributed form of the “generic.sys”
library from Oney that the co-worker included.

The interesting part of the call stack looks like:

…
nt!IoRegisterDeviceInterface
Generic!GenericRegisterInterface
Generic!InitializeGenericExtension
OurDrv!AddDevice
…

The ASSERT msg reads, “ASSERT_PASSIVE_LEVEL failed … Irql = 1”

When I follow the call stack back, I see that GenericRegisterInterface()
calls IoRegisterDeviceInterface(), after it first gets a Mutex (calls
ExAcquireFastMutex()).

The DDK explicitly says that ExAcquireFastMutex() raises IRQL to
APC_LEVEL, and also says that IoRegisterDeviceInterface() must be
called at PASSIVE_LEVEL. It seems to me that this could never work as
written, or rather never work with a checked version of the kernel with
ASSERTS turned on.

I’ve searched in the OSR lists as well as through the lists on Google,
etc. with no results. Am I missing something obvious?

Thanks in Advance, and Best Regards,
-Mike

OSR_Community_User · February 22, 2005, 5:02pm

To avoid APC_LEVEL headache, I use the following pair.

#define ACQUIRE_MUTEX_PRETTY_SAFE(_mutex) \
{ \
ASSERT(KeGetCurrentIrql()<=APC_LEVEL); \
KeEnterCriticalRegion(); \
ExAcquireFastMutexUnsafe(_mutex); \
}

#define RELEASE_MUTEX_PRETTY_SAFE(_mutex) \
{ \
ExReleaseFastMutexUnsafe(_mutex); \
KeLeaveCriticalRegion(); \
}

Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com

-----Original Message-----
From: Michael Becker [mailto:xxxxx@hologic.com]
Sent: February 22, 2005 4:41 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Possible bug in Oney’s Generic.sys?

Hi All,

I am relatively new to driver development and have been given the
assignment of taking over maintenance of driver written by a former
co-worker, so any help or advice anyone can give me as I bootstrap
myself would be greatly appreciated!

I am now trying to install the driver under a checked version of the XP
kernel (sp1), and keep hitting an ASSERT within a system call, which
appears to be caused by the redistributed form of the “generic.sys”
library from Oney that the co-worker included.

The interesting part of the call stack looks like:

…
nt!IoRegisterDeviceInterface
Generic!GenericRegisterInterface
Generic!InitializeGenericExtension
OurDrv!AddDevice
…

The ASSERT msg reads, “ASSERT_PASSIVE_LEVEL failed … Irql = 1”

When I follow the call stack back, I see that GenericRegisterInterface()
calls IoRegisterDeviceInterface(), after it first gets a Mutex (calls
ExAcquireFastMutex()).

The DDK explicitly says that ExAcquireFastMutex() raises IRQL to
APC_LEVEL, and also says that IoRegisterDeviceInterface() must be
called at PASSIVE_LEVEL. It seems to me that this could never work as
written, or rather never work with a checked version of the kernel with
ASSERTS turned on.

I’ve searched in the OSR lists as well as through the lists on Google,
etc. with no results. Am I missing something obvious?

Thanks in Advance, and Best Regards,
-Mike

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

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

OSR_Community_User · February 22, 2005, 5:10pm

Or just replace the mutex with an event-based lock.

=====================
Mark Roddy

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Calvin Guan
Sent: Tuesday, February 22, 2005 5:03 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Possible bug in Oney’s Generic.sys?

To avoid APC_LEVEL headache, I use the following pair.

#define ACQUIRE_MUTEX_PRETTY_SAFE(_mutex) \
{ \
ASSERT(KeGetCurrentIrql()<=APC_LEVEL); \
KeEnterCriticalRegion(); \
ExAcquireFastMutexUnsafe(_mutex); \
}

#define RELEASE_MUTEX_PRETTY_SAFE(_mutex) \
{ \
ExReleaseFastMutexUnsafe(_mutex); \
KeLeaveCriticalRegion(); \
}

Calvin Guan Software Engineer
ATI Technologies Inc. www.ati.com

-----Original Message-----
From: Michael Becker [mailto:xxxxx@hologic.com]
Sent: February 22, 2005 4:41 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Possible bug in Oney’s Generic.sys?

Hi All,

I am relatively new to driver development and have been given the
assignment of taking over maintenance of driver written by a former
co-worker, so any help or advice anyone can give me as I bootstrap
myself would be greatly appreciated!

I am now trying to install the driver under a checked version of the
XP kernel (sp1), and keep hitting an ASSERT within a system call,
which appears to be caused by the redistributed form of the “generic.sys”
library from Oney that the co-worker included.

The interesting part of the call stack looks like:

…
nt!IoRegisterDeviceInterface
Generic!GenericRegisterInterface
Generic!InitializeGenericExtension
OurDrv!AddDevice
…

The ASSERT msg reads, “ASSERT_PASSIVE_LEVEL failed … Irql = 1”

When I follow the call stack back, I see that
GenericRegisterInterface() calls IoRegisterDeviceInterface(), after it
first gets a Mutex (calls ExAcquireFastMutex()).

The DDK explicitly says that ExAcquireFastMutex() raises IRQL to
APC_LEVEL, and also says that IoRegisterDeviceInterface() must be
called at PASSIVE_LEVEL. It seems to me that this could never work
as written, or rather never work with a checked version of the kernel
with ASSERTS turned on.

I’ve searched in the OSR lists as well as through the lists on Google,
etc. with no results. Am I missing something obvious?

Thanks in Advance, and Best Regards,
-Mike

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

You are currently subscribed to ntdev as: xxxxx@ati.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: xxxxx@stratus.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

Maxim_S_Shatskih · February 25, 2005, 2:24pm

> When I follow the call stack back, I see that GenericRegisterInterface()

calls IoRegisterDeviceInterface(), after it first gets a Mutex (calls
ExAcquireFastMutex()).

A bug. Move IoRegisterDeviceInterface out of the path guarded by mutex.

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

Andrew_Sha · February 28, 2005, 8:00pm

Just keep in mind that calling ACQUIRE_MUTEX_PRETTY_SAFE() has the net
effect slightly different from ExAcquireFastMutex()

“Calvin Guan” wrote in message news:xxxxx@ntdev…
> To avoid APC_LEVEL headache, I use the following pair.
>
> #define ACQUIRE_MUTEX_PRETTY_SAFE(_mutex) > { > ASSERT(KeGetCurrentIrql()<=APC_LEVEL); > KeEnterCriticalRegion(); > ExAcquireFastMutexUnsafe(_mutex); > }
>
> #define RELEASE_MUTEX_PRETTY_SAFE(_mutex) > { > ExReleaseFastMutexUnsafe(_mutex); > KeLeaveCriticalRegion(); > }
>
> -
> Calvin Guan Software Engineer
> ATI Technologies Inc. www.ati.com
>
> > -----Original Message-----
> > From: Michael Becker [mailto:xxxxx@hologic.com]
> > Sent: February 22, 2005 4:41 PM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] Possible bug in Oney’s Generic.sys?
> >
> > Hi All,
> >
> > I am relatively new to driver development and have been given the
> > assignment of taking over maintenance of driver written by a former
> > co-worker, so any help or advice anyone can give me as I bootstrap
> > myself would be greatly appreciated!
> >
> > I am now trying to install the driver under a checked version of the XP
> > kernel (sp1), and keep hitting an ASSERT within a system call, which
> > appears to be caused by the redistributed form of the “generic.sys”
> > library from Oney that the co-worker included.
> >
> >
> > The interesting part of the call stack looks like:
> > -------------------------------------------------
> > …
> > nt!IoRegisterDeviceInterface
> > Generic!GenericRegisterInterface
> > Generic!InitializeGenericExtension
> > OurDrv!AddDevice
> > …
> >
> >
> > The ASSERT msg reads, “ASSERT_PASSIVE_LEVEL failed … Irql = 1”
> >
> >
> > When I follow the call stack back, I see that GenericRegisterInterface()
> > calls IoRegisterDeviceInterface(), after it first gets a Mutex (calls
> > ExAcquireFastMutex()).
> >
> > The DDK explicitly says that ExAcquireFastMutex() raises IRQL to
> > APC_LEVEL, and also says that IoRegisterDeviceInterface() must be
> > called at PASSIVE_LEVEL. It seems to me that this could never work as
> > written, or rather never work with a checked version of the kernel with
> > ASSERTS turned on.
> >
> >
> > I’ve searched in the OSR lists as well as through the lists on Google,
> > etc. with no results. Am I missing something obvious?
> >
> >
> > Thanks in Advance, and Best Regards,
> > -Mike
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@ati.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>

OSR_Community_User · March 1, 2005, 4:23pm

Thank you to everyone for the advice and suggestions. After a bit more
review as to what was actually going on, I discovered a few more places
where IoXxxInterface calls were being made at APC_LEVEL and corrected
these also. It looks like there is a doubly linked list of interfaces
and the mutex in question is being used to protect the list, except that
its the elements of the list that need to be passed to the
IoXxxInterface calls.

Thanks Again!
-Mike

OSR_Community_User · March 4, 2005, 5:30pm

Just a quick update to this thread before I let it die. As I was
working on this, I missed the fact that the Oney libraries being used
were from the first edition of the book, which was incidentally targeted
at Win2000. I have diff’ed these with the libraries from the second
edition and all of this (and more) is fixed for XP. Just though I’d
share my screw-up in case it saves some other newbie from making the
same mistake.

Best Regards,
-Mike

Michael Becker wrote:

Thank you to everyone for the advice and suggestions. After a bit
more review as to what was actually going on, I discovered a few more
places where IoXxxInterface calls were being made at APC_LEVEL and
corrected these also. It looks like there is a doubly linked list of
interfaces and the mutex in question is being used to protect the
list, except that its the elements of the list that need to be passed
to the IoXxxInterface calls.

Thanks Again!
-Mike

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

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

Peter_Viscarola_OSR · March 4, 2005, 7:16pm

Michael Becker wrote:

Just a quick update to this thread before I let it die. As I was
working on this, I missed the fact that the Oney libraries being used
were from the first edition of the book, which was incidentally targeted
at Win2000. I have diff’ed these with the libraries from the second
edition and all of this (and more) is fixed for XP. Just though I’d
share my screw-up in case it saves some other newbie from making the
same mistake.

Thanks for taking the time to sum this up for the archive.

Bravo! That’s good practice!

Peter
OSR