When can WaitForSingleObject return WAIT_FAILED?

[Sean Kelly]

When both waiting on an event and a simple unnamed mutex, I'm wondering
when WaitForSingleObject might return WAIT_FAILED. These are both
execution paths I'd very much like to avoid exceptional behavior but I
haven't found much documentation on the specifics. Can anyone offer advice?

Sean

[William DePalo]

Sean Kelly <ke****@pacbell.net> wrote in message
news:uL**************@TK2MSFTNGP12.phx.gbl...

When both waiting on an event and a simple unnamed mutex, I'm wondering
when WaitForSingleObject might return WAIT_FAILED. These are both
execution paths I'd very much like to avoid exceptional behavior but I
haven't found much documentation on the specifics. Can anyone offer

advice?

Well, suppose you pass an invalid handle to the function? I'd expect that
you will get a WAIT_FAILED status and then INVALID_HANDLE in the call to
GetLastError(). I don't think there is any way you can avoid checking the
status of the code _somewhere_.

Regards,
Will

[Sean Kelly]

William DePalo wrote:

Sean Kelly <ke****@pacbell.net> wrote in message
news:uL**************@TK2MSFTNGP12.phx.gbl...

When both waiting on an event and a simple unnamed mutex, I'm wondering
when WaitForSingleObject might return WAIT_FAILED. These are both
execution paths I'd very much like to avoid exceptional behavior but I
haven't found much documentation on the specifics. Can anyone offer

advice?

Well, suppose you pass an invalid handle to the function? I'd expect that
you will get a WAIT_FAILED status and then INVALID_HANDLE in the call to
GetLastError(). I don't think there is any way you can avoid checking the
status of the code _somewhere_.

This is in an object and ensapsulation ensures that the parameters
passed will always be valid. Basically, I'm trying to avoid the
possibility that an exception may be thrown when acquiring a lock on a
mutex. Critical section operations are guranteed to succeed for this
reason. More info: it's an unnamed mutex without any security
restrictions. Basically, just an object that creates the mutex on
construction, locks/unlocks the mutex when requested, and destroys the
mutex on destruction. What I'm looking for is someone with enough
knowledge of the inner workings of the call that they could tell be what
conditions might cause a WAIT_FAILED in this instance. I'm hoping that
if I can satisfy enough preconditions before calling the function I can
be guranteed that the function will never fail in this way.

Sean

[William DePalo [MVP VC++]]

Sean Kelly <ke****@pacbell.net> wrote in message
news:uK**************@TK2MSFTNGP11.phx.gbl...

This is in an object and ensapsulation ensures that the parameters
passed will always be valid.
In an environment where "naked" pointers are used, memory corruption is not
impossible, encapsulation be damned. It is hard to imagine a Win32 program
without a single naked pointer.
What I'm looking for is someone with enough
knowledge of the inner workings of the call that they could tell be what
conditions might cause a WAIT_FAILED in this instance.
Then I suggest that you post again in the kernel group. Perhaps there you'll
run into someone who has seen the source or reverse engineered it.
I'm hoping that if I can satisfy enough preconditions
before calling the function I can be guranteed that
the function will never fail in this way.

Good luck.

Regards,
Will

[Carl Daniel [VC++ MVP]]

William DePalo [MVP VC++] wrote:

Sean Kelly <ke****@pacbell.net> wrote in message
news:uK**************@TK2MSFTNGP11.phx.gbl...

This is in an object and ensapsulation ensures that the parameters
passed will always be valid.

In an environment where "naked" pointers are used, memory corruption
is not impossible, encapsulation be damned. It is hard to imagine a
Win32 program without a single naked pointer.

What I'm looking for is someone with enough
knowledge of the inner workings of the call that they could tell be
what conditions might cause a WAIT_FAILED in this instance.

Then I suggest that you post again in the kernel group. Perhaps there
you'll run into someone who has seen the source or reverse engineered
it.

If you're waiting on a mutex, you'll normally get WAIT_FAILED for only two
reasons: 1. The HANDLE you passed in is invalid. 2. Another thread that
owned the mutex was terminated without releasing ownership.

There's no guarantee that those are the only two circumstances though.
There are probably other, extremely rare and esoteric failures possible.

-cd

[Sean Kelly]

Carl Daniel [VC++ MVP] wrote:

If you're waiting on a mutex, you'll normally get WAIT_FAILED for only two
reasons: 1. The HANDLE you passed in is invalid. 2. Another thread that
owned the mutex was terminated without releasing ownership.
From what I read in MSDN I thought that case 2 would return
WAIT_ABANDONED and mutex ownership would be transferred.
There's no guarantee that those are the only two circumstances though.
There are probably other, extremely rare and esoteric failures possible.

That's what I'm afraid of. Worst case I suppose I can just always use
critical sections to avoid the possibility of failure.

Sean

[Carl Daniel [VC++ MVP]]

Sean Kelly wrote:

Carl Daniel [VC++ MVP] wrote:

If you're waiting on a mutex, you'll normally get WAIT_FAILED for
only two reasons: 1. The HANDLE you passed in is invalid. 2.
Another thread that owned the mutex was terminated without releasing
ownership.

From what I read in MSDN I thought that case 2 would return
WAIT_ABANDONED and mutex ownership would be transferred.

You're right about that.

-cd