No. The only way to avoid the bugcheck is to actually fix your driver. What you propose doesn’t do that - it just tries to ignore the problem.
You are not the poor victim here. This isn’t “just happening” to you. There is something wrong with your driver and you should want to find it and fix it. You shouldn’t want to “get on with [your] work” when your driver has done something wrong. You should want to fix it.
Can you reproduce this on your test machine? Do you have a customer who can reproduce it reliably? If so then you should debug the driver. Keep track of the mutex owner yourself and use assertions to verify that you do own it when you think you do, and that you’ve acquired it on the thread you think you did. Log what you’re doing to the debugger and verify the trace. You should do this so that you can find the problem, not so you can avoid it.
-p
From: xxxxx@lists.osr.com on behalf of Mr.A.Srijith K Unni
Sent: Wed 3/29/2006 1:54 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] avoiding exception STATUS_MUTANT_NOT_OWNED
Hi Peter,
I am not trying to catch a bug check. What i am asking is whether I can avoid a bug check of 8E or 1E by handling the exception in my code.
I am not deliberately trying to release the mutex from another thread, but it just happens, somehow during a reboot. I want to know, whether I can handle the exception raised by KeReleaseMutex, in this context and log a message and get on with my work, without having a bug check of 8E.
I had earlier found this from this site
For a driver, structured exception handling must be used whenever calling a routine that might generate an exception. A failure to do so will cause the default OS-provided exception handler to be invoked. This exception handler calls KeBugCheckEx with the bug code KMODE_EXCEPTION_NOT_HANDLED.
In addition, a driver should use structured exception handling whenever performing an operation on a user virtual address. If the address is invalid, the exception handler will be invoked and the driver can process the access violation as necessary.
and so the question…
Thanks for all your help in advance.
On 3/23/06, Peter Wieland wrote:
Bugchecks aren’t exceptions. They can’t be caught. You’ll have to fix your driver.
Are you perhaps trying to release the mutex from a thread other than the one which acquired it?
-p
________________________________
From: xxxxx@lists.osr.com on behalf of Mr.A.Srijith K Unni
Sent: Thu 3/23/2006 7:33 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] avoiding exception STATUS_MUTANT_NOT_OWNED
Thanks Loren for your extensive ideas.
As per what you suggested, I have created complete flow charts and checked if there is any place where I am releasing the mutex, without having first acquired it.( This is assuming, that that is what you have told me to do ) I could not find any such discrepancy in the code.
Also, in addition to this I had another query.
if I were to modify my code as…
__try
{
…
KeReleaseMutex();
…
}
__except
{
// handle exception.
}
Will doing this be enough to handle the exception STATUS_MUTANT_NOT_OWNED and avoid a bug check, unmindful of the fact that according to MSDN, calling KeReleaseMutex, without owning it will result in a bugcheck.
Thanks for all your help
Regards,
Srijith
On 3/22/06, Loren Wilton wrote:
> Is there any way I can atleast check whether the current thread owns the
mutex
> before the mutex is released or is it enough, if I just handle the
exception, in
> my driver code ?
You have a basic problem here, and the solution you propose is almost
certainly the wrong solution.
The basic problem is that you are not correctly using the mutex as it should
be used. The purpose of the mutex, one supposes, is to protect some
resource from simultaneous access from two different threads. In your case,
one of the threads has released the mutex, and then later tries to release
it a second time. (The fact that the other thread has already acquire the
mutex before the second release is immaterial.)
If your thread has already released the mutex, and you DON’T KNOW WHERE IT
DID IT, then you aren’t succeeding in protecting the critical resource,
because you never know whether it is protected (you own the mutex) or not.
“Knowing whether you own it before releasing it” is a band-aid that may
prevent this particular crash from happening. However, it will still not
solve the basic problem that you don’t know when the resource is protected
and when it isn’t. So sooner or later you are going to get a dump that will
be REALLY hard to analyze, where one of the threads did something to the
object when they both thought that they owned it, but at least one of the
threads was wrong. Or worse, you might not get a dump at all. Maybe
various users will just occasionally get random unreproducable data
corruption.
There is only one solution to this problem, and it is hard. You have to go
in an ANALYZE, CAREFULLY, all of the paths where you are attempting to use
this mutex to protect the resource. You need to make flow graphs so you
KNOW where the thread owns the mutex, and where it doesn’t own it. You need
to add comments to the code at procedure entries and exits saying whether
the mutex should be owned at that point.
This is a big lot of work, especially in a complex driver. And there just
aren’t any shortcuts to doing it right. But once you have done it, you will
have probably found anywhere from three to a dozen places where you are
either holding the lock when you don’t need to, or worse, not holding it
when you do need to. Once you fix those places, you will KNOW where a
thread owns the lock, and you will KNOW that it owns the lock in the right
places. Then your driver will work correctly, even on multiprocessor
systems, and even on random user’s systems.
Loren
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Thanks & Regards,
–
A.Srijith.K.Unni
Opportunities Are Divine And Grabbing Them Is Salvation — Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
— Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer