Mutex blocks CreateFileMapping

Maxwell Chen

I am adding a feature into my application programs which will be using shared (mapped) memory to communicate between two programs. I made a demo1 program to test and verify the class implementations. It works well. So I started to do one of the real application program. To prevent two instances in the system, I used CreateMutex for that.

HANDLE hMutex = CreateMutex(NULL, FALSE, MUTEX\_NAME);
if(hMutex) {
    if(ERROR\_ALREADY\_EXISTS == GetLastError()) {
        return FALSE;    // Exit.
    }
}

Later during the initialization of the program, I found CreateFileMapping failed.

m\_hFile = CreateFileMapping(
    INVALID\_HANDLE\_VALUE,        // use paging file
    NULL,                        // default security 
    PAGE\_READWRITE,                // read/write access
    0,                            // maximum object size (high-order DWORD) 
    m\_dwBufSize,                // maximum object size (low-order DWORD)  
    m\_sMappingName);            // name of mapping object

When I removed the CreateMutex line, CreateFileMapping returned a valid handle. Are they using the same system resource?

Maxwell Chen

Code o mat

What did CreateFileMapping fail with, call GetLastError and see what it says, maybe it helps to decypher the problem.

> The problem with computers is that they do what you tell them to do and not what you want them to do. < > "It doesn't work, fix it" does not qualify as a bug report. < > Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <

Maxwell Chen

Code-o-mat wrote:

What did CreateFileMapping fail with, call GetLastError and see what it says, maybe it helps to decypher the problem.

When CreateMutex is used in the code in CDemoApp::InitInstance, CreateFileMapping returns a NULL value. GetLastError() returns 0x00000006 (invalid handle). When CreateMutex is NOT used in the code, CreateFileMapping returns a valid handle to the mapped memory.

Maxwell Chen

Code o mat

This is strange, i find it very unlikely that CreateMutex would affect CreateFileMapping. I have worked with a project that used quite a few mutexes for synchronization and also used file mappings to access data (not using the paging file though) and there was no trouble with working altogether. Are you completely sure that the only difference between the two "versions" is the creation of the mutex?

> The problem with computers is that they do what you tell them to do and not what you want them to do. < > "It doesn't work, fix it" does not qualify as a bug report. < > Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <

Maxwell Chen

Code-o-mat wrote:

Are you completely sure that the only difference between the two "versions" is the creation of the mutex?

Yes! I just used // to comment out the lines. :-D

Maxwell Chen

Code o mat

Is it possible that you specified the same name for the mutex and the file mapping object?

> The problem with computers is that they do what you tell them to do and not what you want them to do. < > "It doesn't work, fix it" does not qualify as a bug report. < > Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <

Maxwell Chen

Code-o-mat wrote:

Is it possible that you specified the same name for the mutex and the file mapping object?

I had also considered this possibility, too. So I have tried using different names for the mutex and the mapped memory individually. Not working... :-D

Maxwell Chen

Code o mat

Try creating an unnamed mutex and see if that changes anything. I know you will need a named one but this is just for testing.

> The problem with computers is that they do what you tell them to do and not what you want them to do. < > "It doesn't work, fix it" does not qualify as a bug report. < > Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <

Code o mat

Also, the documentation[^] of CreateFileMapping states this: "If lpName matches the name of an existing event, semaphore, mutex, waitable timer, or job object, the function fails, and the GetLastError function returns ERROR_INVALID_HANDLE. This occurs because these objects share the same namespace.", this should be a name-collision issue. Just to test this, try explicitly specifying "appleappleapple" for your mutex and "pearpearpear" for your mapping object, i mean, directly where you call the creation methods, not using a macro or any member variable.

> The problem with computers is that they do what you tell them to do and not what you want them to do. < > "It doesn't work, fix it" does not qualify as a bug report. < > Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <

Maxwell Chen

Code-o-mat wrote:

Try creating an unnamed mutex and see if that changes anything. I know you will need a named one but this is just for testing.

I just tried this, and it works. And I also tried again the mutex with name A and the mapped memory with name B. It also works now. I think my system was getting crazy. X| But thank you anyway. :)

Maxwell Chen

_Superman_

The APIs are not related in anyway. Just to be sure I tried to run the piece of code and it works perfectly. So the only thing relating both the APIs in the code above is the name. By giving the same name for both the mutex and the mapping, I'm able to reproduce the error with GetLastError returning the error code 6.

«_Superman_»
I love work. It gives me something to do between weekends.

Microsoft MVP (Visual C++)

Polymorphism in C

Aescleal

I've given this a 5, not 'cause of the original answer but because of the way code-o-mat followed the problem through to it's solution. Class act! Cheers, Ash

Code o mat

Thanks. :)

> The problem with computers is that they do what you tell them to do and not what you want them to do. < > "It doesn't work, fix it" does not qualify as a bug report. < > Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <

Luc Pattyn

Maxwell Chen wrote:

if(hMutex) {

shouldn't that be if(!hMutex) { ? :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum

Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.

Maxwell Chen

Luc Pattyn wrote:

shouldn't that be if(!hMutex) { ?

Nope, my original code snippet as the below is correct.

HANDLE hMutex = CreateMutex(NULL, FALSE, MUTEX\_NAME);
if(hMutex) { // Returning a valid handle means that this mutex object has been successfully created.
    if(ERROR\_ALREADY\_EXISTS == GetLastError()) {
        // So we check the system error. 
        // It says the mutex object has already been existing.
        // Meaning this is a second instance of the program.
        return FALSE;    // So we have this one exit.
    }
    // The other case is no error. :-)
}

Maxwell Chen

Luc Pattyn

My mistake. This is one of the exceptional cases where calling GetLastError makes sense even when the function succeeded. :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum

Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.

Maxwell Chen

:)

Maxwell Chen

Blake Miller

What happens after you return FALSE ? Otherwise, I think you just leaked a system object handle. Your program should technically close the mutex handle if you are not going to use it.