You will need to allocate memory to hold the bits. That size is slightly tricky it depends on what color depth you are going to ask for in bits. Typically you want RGB24 or RGB32 and the size also needs to be aligned to a 4 byte boundary. Anyhow long story short its a funny maths calc and we need to setup a bitmap header info for the call ... Lets do 24 bit colour.
!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?