!handle displays information about a handle or handles that one or all processes in the target system own.
0:000> !handle c0dedbad f
Object Specific Information
Mutex is Owned
Mutant Owner 11bc.1418
Here are some other ideas in case you don't know how to use WinDbg:
You do realize you don't pass the handle around between threads right?
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 usingthis 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.
That is a alot of synchronization objects for a single thread. Please perform an audit/review on your code and check to see if your application is using greater than MAXIMUM_WAIT_OBJECTS which is probably defined as 64 on your operating system. Exceeding this number will cause failures at run-time that the compiler does not catch.
You might want to ask your engineers to design a better architecture that does not require single threads to wait on such a large number of handles.
Also please paste the entire contents of the "Debug Assertion Failed!" error message so we can further assist.
Please find the contents of the "Debug Assertion Failed!" error message as:
Debug Assertion Failed!
For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.
(Press Retry to debug the application)
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\winfrm.cpp(1628) : AppMsg - Warning: no message line prompt for ID 0xE001.
Even though I restricted the synchronization objects to 2 only, then also I am getting the above same error.
Please let me know if you need more information on this?
Look at the call stack to see what the assertion was checking, that should give you clues as to where the actual problem may be. Are you using the same exact MFC version (other than 32v64bit) on both compilations?
Just hold make an internal array of PCore pointers and pass them out an Index number ... call it a handle ... I guess a HPCORE.
So they hold onto an index number and when they call a function the pass in the index number and you grab back the PCore pointer out of your array.
That is what all the HANDLES are in Windows, they have a number it tells them nothing about what happens internally it just a index to a internal pointer that never comes out. So you code becomes more like Windows API and they can have multiple HPCore handles.
EDIT: Actually I am being slow do what windows does exactly pass back a pointer to the position in the internal array rather than the index as the handle. First saves having to use the number to traverse the array to get the pointer (so much much faster). Second you can test the handle being valid if you need because it must lie between PCoreArray ... PCoreArray[Last] of your internal PCore pointer array. It's index position in the array which you only need to know when you dispose to empty the slot is straight forward
Handle Index = (Handle - &PCoreArray)/sizeof(Pointer).
So a handle is a PCore** .. that is a pointer to a pointer to a PCore but I would just typedef it as size_t and internally typecast it because you can check it via the above. So ...
typedef size_t HPCORE;
In vino veritas
modified 10-Nov-16 21:33pm.
Last Visit: 31-Dec-99 19:00 Last Update: 2-Dec-23 2:29