ERROR_INVALID_HANDLE returned From WaitForSingleObject after CreateMutex
-
ForNow wrote:
go to disassembly mode
Shouldn't be necessary. You should be able to step through with your debugger to check if the handle is valid. Remember, it could easily have been corrupted by your (or someone's) code.
-
ForNow wrote:
It's the handle I guess the next step is to go to disassembly mode and see
Since you are such an expert at x86/x64 assembler perhaps you should utilize WinDbg: Common WinDBG Commands Reference[^]
!handle displays information about a handle or handles that one or all processes in the target system own.
0:000> !handle c0dedbad f
Handle 38
Type Mutant
Attributes 0
GrantedAccess 0x1f0001:
Delete,ReadControl,WriteDac,WriteOwner,Synch
QueryState
HandleCount 1
PointerCount 96605
Name Object Specific Information
Mutex is Owned
Mutant Owner 11bc.1418Here are some other ideas in case you don't know how to use WinDbg:
//Windows 8.1 and below:
BOOL IsValidHandle(HANDLE h)
{
DWORD dwFlags = 0;
return GetHandleInformation(h,&dwFlags);
}//Windows 10 and above:
BOOL IsValidHandle(HANDLE h)
{
return CompareObjectHandles(h,h);
}use it like this to debug your code:
if (IsValidHandle(h))
{
DWORD dwResult = ::WaitForSingleObject(h, INFINITE);
DWORD dwError = GetLastError();
}Best Wishes, -David Delaune
-
Hi I am getting ERROR_INVALID_HANDLE on GetLastError after WaitForSingleObject returns -1 I more or Less followed the MSDN example Using Mutex My main thread does muthandle = CreateMutex(NULL,FALSE,NULL); Second parameter is FALSE indicating it is not owned Later a second Thread calls WaitForSingleObject(muthandle,INFINITE) and gets a -1 which GetLastError retuns ERROR_INVALID_HANDLE THANKS
How are you passing muthandle to your second thread? ...is it possible that you're not passing that correctly (for example, if you passed by pointer that you're not dereferencing your pointer)?
-
How are you passing muthandle to your second thread? ...is it possible that you're not passing that correctly (for example, if you passed by pointer that you're not dereferencing your pointer)?
-
There is a global block accessible to all the threads This is one of the fields I going to double check that The handle has the value initialized by CreateMutex later in tonite
Since it's a different thread... also check that the thread going to the wait state isn't waiting on a handle that hasn't been created yet.
-
For some reason i am not able to display certain data areas on quick watch That's the only reason I got intobinto disassembly mode Thanks
You are inside a thread the debugger doesn't always have access to all the memory.
In vino veritas
-
There is a global block accessible to all the threads This is one of the fields I going to double check that The handle has the value initialized by CreateMutex later in tonite
You do realize you don't pass the handle around between threads right? Read carefully
Two or more processes can call CreateMutex to create the same named mutex. The first process actually creates the mutex, and subsequent processes open a handle to the existing mutex. This enables multiple processes to get handles of the same mutex, while relieving the user of the responsibility of ensuring that the creating process is started first. When using this technique, you should set the bInitialOwner flag to FALSE; otherwise, it can be difficult to be certain which process has initial ownership.
If you go the other way and guarantee the inital thread opens it first you need to set the bInitialOwner flag and do a release. So your other choice.
The creating thread can use the bInitialOwner flag to request immediate ownership of the mutex. Otherwise, a thread must use one of the wait functions to request ownership. When the mutex's state is signaled, one waiting thread is granted ownership, the mutex's state changes to nonsignaled, and the wait function returns. Only one thread can own a mutex at any given time. The owning thread uses the ReleaseMutex function to release its ownership.
You seem to get getting confused between the two modes from what I am reading. You need to make a choice (a) or (b). So I think you are getting this error because you are using the named technique without a name.
If lpName matches the name of an existing event, semaphore, waitable timer, job, or file-mapping object, the function fails and the GetLastError function returns ERROR_INVALID_HANDLE. This occurs because these objects share the same namespace.
In vino veritas
-
You are inside a thread the debugger doesn't always have access to all the memory.
In vino veritas
-
You do realize you don't pass the handle around between threads right? Read carefully
Two or more processes can call CreateMutex to create the same named mutex. The first process actually creates the mutex, and subsequent processes open a handle to the existing mutex. This enables multiple processes to get handles of the same mutex, while relieving the user of the responsibility of ensuring that the creating process is started first. When using this technique, you should set the bInitialOwner flag to FALSE; otherwise, it can be difficult to be certain which process has initial ownership.
If you go the other way and guarantee the inital thread opens it first you need to set the bInitialOwner flag and do a release. So your other choice.
The creating thread can use the bInitialOwner flag to request immediate ownership of the mutex. Otherwise, a thread must use one of the wait functions to request ownership. When the mutex's state is signaled, one waiting thread is granted ownership, the mutex's state changes to nonsignaled, and the wait function returns. Only one thread can own a mutex at any given time. The owning thread uses the ReleaseMutex function to release its ownership.
You seem to get getting confused between the two modes from what I am reading. You need to make a choice (a) or (b). So I think you are getting this error because you are using the named technique without a name.
If lpName matches the name of an existing event, semaphore, waitable timer, job, or file-mapping object, the function fails and the GetLastError function returns ERROR_INVALID_HANDLE. This occurs because these objects share the same namespace.
In vino veritas