Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 557
  • Last Modified:

How to determine which process created a named mutex?

Is it possible to determine which process created a named mutex?

For example, let's say you have 5 applications (or perhaps 5 instances of the same app). Each one attempts to create a named mutex. Obviously only one can succeed. Is it possible to tell from another application which one of the 5 created the mutex? Is it possible to tell which (if any) has the mutex locked?

The number of apps/instances doesn't matter (just that it's more than one).
0
Melange
Asked:
Melange
1 Solution
 
robpittCommented:
If an application calls CreateMutex for a named mutex and that mutex already exists then a handle to the existing mutex is returned. This scenario can be detected by testing whether GetLastError()==ERROR_ALREADY_EXISTS

See the CreateMutex documentation for more info.

Does that help?
0
 
jkrCommented:
There is no way to do that. I checked the NT Native API, and even NT does not keep track of that (IOW: 'ZwQueryObject()' does not provide any info about the creator of an object).
0
 
makerpCommented:
Easy, as robpit said if the mutes already exists then it returns ERROR_ALREADY_EXISTS. So if you don’t get this back then you are the first process to call CreateMutex with that name. So in your code if this is the case set a bool to true indicating you created it. if you do get back ERROR_ALREADY_EXISTS set the bool to false. now using some sort of process communication you could ask each process if they created the mutex. alternativley using sockets broadcast a 'Who created the mutex' message, the client who did could send back a message with their process-id in (they would not have to send their IP as you can get that from the Recv call in the sockaddr_in struct). if all prcesses are on the same machine then have the mutex creator to write a process-id file to a known location on disk...

there is one serious limintaion of my suggestion, that limitation being you must have the source code for the applications so you can code this in.
0
Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

 
robpittCommented:
Yeah I assumed that he realy didn't need to know exactly which other process created the mutex... if you need that then as JKR says you need an additional interprocess mechanism (e.g. shared memory to which you could write a process id - see CreateFileMapping for info)
0
 
dpodvalnCommented:
makerp : you not necessarily need a source code to do it. You may inject your dll into all processes and override CreateMutex function with something as :

shared_processId = GetProcessId()
OriginalCreateMutex();
this technique described in the Richman's book.
0
 
MelangeAuthor Commented:
Yeah, I was specifically looking for which process created a mutex as opposed to if it existed. That's easy with OpenMutex.

Unfortunately in the situation I was looking for neither interprocess communication or dll injection would work. I was looking at this as a diagnostic tool to see why some apps were hanging or causing problems (that naturally seem to occur only at customer sites).

Dll injection wouldn't work because the mutex would already exist by the time I got to take a look at it. Interprocess communication wouldn't work because the app might not be responsive.

At least I may have indirectly figured out what the hangups were. Seems it wasn't even related to the mutex after all. But, it's one of those situations where I won't know if I succeeded in solving it or not unless it just doesn't happen again.

I'm still interested to see if there is a way to get this kind of diagnostic information. But, if the OS doesn't save the creating process id anywhere, then I guess it's not possible.
0

Featured Post

Become an Android App Developer

Ready to kick start your career in 2018? Learn how to build an Android app in January’s Course of the Month and open the door to new opportunities.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now