C++ - Cannot See Created Mutex Using WinObj - c++

I am using this really simple code to try to create a mutex
int main(){
HANDLE hMutex = ::CreateMutex(nullptr, FALSE, L"SingleInstanceMutex");
if(!hMutex){
wchar_t buff[1000];
_snwprintf(buff, sizeof(buff), L"Failed to create mutex (Error: %d)", ::GetLastError());
::MessageBox(nullptr, buff, L"Single Instance", MB_OK);
return 0x1;
} else {
::MessageBox(nullptr, L"Mutex Created", L"Single Instance", MB_OK);
}
return 0x0;
}
And I get the message "Mutex Created" like if it is correctly created, but when I try to search it using the tool WinObj of SysInternals I can't find it.
Also if I restart the program many times while another instance is running I always get the message "Mutex Created" and never an error because the mutex already exists.
I'm trying it on a Windows 7 VM.
What I'm doing wrong?
Ah I'm compiling on Linux using:
i686-w64-mingw32-g++ -static-libgcc -static-libstdc++ Mutex.cpp
Thank you!

In order to use a Windows mutex (whether a named one like yours or an unnamed one), you need to use the following Win APIs:
CreateMutex - to obtain a handle to the mutex Windows kernel object. In case of a named mutex (like yours) multiple processes should succeed to get this handle. The first one will cause the OS to create a new named mutex, and the others will get a handle referring to that same mutex.
In case the function succeeds and you get a valid handle to the named mutex, you can determine whether the mutex already existed (i.e. that another process already created the mutex) by checking if GetLastError returns ERROR_ALREADY_EXISTS.
WaitForSingleObject - to lock the mutex for exclusive access. This function is actually not specific to mutex and is used for many kernel objects. See the link above for more info about Windows kernel objects.
ReleaseMutex - to unlock the mutex.
CloseHandle - to release the acquired mutex handle (as usual with Windows handles). The OS will automatically close the handle when the process exists, but it is good practice to do it explicitly.
A complete example:
#include <Windows.h>
#include <iostream>
int main()
{
// Create the mutex handle:
HANDLE hMutex = ::CreateMutex(nullptr, FALSE, L"SingleInstanceMutex");
if (!hMutex)
{
std::cout << "Failed to create mutex handle." << std::endl;
// Handle error: ...
return 1;
}
bool bAlreadyExisted = (GetLastError() == ERROR_ALREADY_EXISTS);
std::cout << "Succeeded to create mutex handle. Already existed: " << (bAlreadyExisted ? "YES" : "NO") << std::endl;
// Lock the mutex:
std::cout << "Atempting to lock ..." << std::endl;
DWORD dwRes = ::WaitForSingleObject(hMutex, INFINITE);
if (dwRes != WAIT_OBJECT_0)
{
std::cout << "Failed to lock the mutex" << std::endl;
// Handle error: ...
return 1;
}
std::cout << "Locked." << std::endl;
// Do something that required the lock: ...
std::cout << "Press ENTER to unlock." << std::endl;
std::getchar();
// Unlock the mutex:
if (!::ReleaseMutex(hMutex))
{
std::cout << "Failed to unlock the mutex" << std::endl;
// Handle error: ...
return 1;
}
std::cout << "Unlocked." << std::endl;
// Free the handle:
if (!CloseHandle(hMutex))
{
std::cout << "Failed to close the mutex handle" << std::endl;
// Handle error: ...
return 1;
}
return 0;
}
Error handling:
As you can see in the documentation links above, when CreateMutex,ReleaseMutex and CloseHandle fail, you should call GetLastError to get more info about the error. WaitForSingleObject will return a specific return value upon error (see the documentation link above). This should be done as a part of the // Handle error: ... sections.
Note:
Using a named mutex for IPC (interprocess communication) might be the only good use case for native Windows mutexes.
For a regular unnamed mutex it's better to use one of the available standard library types of mutexes: std::mutex,std::recursive_mutex,std::recursive_timed_mutex (the last 2 support repeated lock by a thread, similarly to Windows mutex).

Related

Execute a command line process with C++ and gracefully close on Windows 10

As part of my automated test suite, I have a C++ Program (A) that executes a command line Process (B) using CreateProcess().
The process only terminates when it receives a SIGINT signal (for reasons outside of my control).
I can terminate the process (B) from (A) using CloseHandle() and/or TerminateProcess(), however, this does not call the destructor of (B), preventing it from closing gracefully (writing stuff to disk and closing DB connections) and causing the tests to fail.
What is the best approach to gracefully close (B), allowing it clean up after itself? Should I be using a helper executable with IPC, a remote thread...?
I have tried the solutions in these SA questions:
Can I send a ctrl-C (SIGINT) to an application on Windows? (If I detach my console the test suite fails)
How do I send ctrl+c to a process in c#? (Modified for C+)
How to get GenerateConsoleCtrlEvent to work with cmd.exe
Edit: #Remy Lebeau is right I should have posted some code:
Current Approach:
Close the process handle. This kills the process immediately.
PROCESS_INFORMATION process_info;
... // CreateProcess()
CloseHandle(process.hProcess);
CloseHandle(process.hThread);
Approach 2:
Detach the current console and then re-attach. This causes the initial test suite to fail.
PROCESS_INFORMATION process_info;
... // CreateProcess
DWORD thisConsoleId = GetCurrentProcessId();
bool consoleDetached = (FreeConsole() != FALSE);
if (AttachConsole(process_info.dwProcessId)) {
std::cout << "Attached process to console" << std::endl;
SetConsoleCtrlHandler(NULL, true);
if (GenerateConsoleCtrlEvent(CTRL_C_EVENT, 0)) {
std::cout << "Ctrl-c sent to process" << std::endl;
} else {
std::cout << "Could not send ctrl-c (" << GetLastError() << ")" << std::endl;
}
FreeConsole();
} else {
std::cout << "Unable to attach process to console (" << GetLastError() << ")" << std::endl;
}
if (consoleDetached) {
// Create a new console if previous was deleted by OS
if (AttachConsole(thisConsoleId)) {
int errorCode = GetLastError();
// 31=ERROR_GEN_FAILURE
if (errorCode == 31) {
AllocConsole();
}
}
}
Approach 3:
Attach to console without freeing. This kills everything including the test suite.
PROCESS_INFORMATION process_info;
... // CreateProcess
AttachConsole(process_info.dwProcessId);
SetConsoleCtrlHandler(NULL, TRUE);
GenerateConsoleCtrlEvent(CTRL_C_EVENT, 0);

Windows Named Semaphore Not Getting Locked

I am developing C++ class with calls to Windows API C libraries.
I am using the Semaphores for a task, let's say I have two processes:
ProcessA has two semaphores:
Global\processA_receiving_semaphore
Global\processA_waiting_semaphore
ProcessB has two semaphores:
Global\processB_receiving_semaphore
Global\processB_waiting_semaphore
I have two threads in each process:
Sending thread in processA:
Wait on "Global\processB_waiting_semaphore"
// do something
Signal "Global\processB_receiving_semaphore"
Receiving thread on processB:
Wait on "Global\processB_receiving_semaphore"
// do something
Signal "Global\processB_waiting_semaphore
I removed ALL code that Releases "Global\processB_waiting_semaphore" but it can still be acquired. Calling WaitForSingleObject on that semaphore always returns successful wait and immediately. I tried setting the timeout period to 0 and it still acquires the semaphore while NOTHING is releasing it.
The receiving semaphore has initial count = 0 and max count = 1 while the waiting semaphore has initial count = 1 and max count = 1.
Calling WaitForSingleObject on the receiving semaphore works great and blocks until it is released by the other process. The problem is with the waiting semaphore and I cannot figure out why. The code is very big and I have made sure the names of the semaphores are set correctly.
Is this a common issue? If you need more explanation please comment and I will modify the post.
EDIT: CODE ADDED:
Receiver semaphores:
bool intr_process_comm::create_rcvr_semaphores()
{
std::cout << "\n Creating semaphore: " << "Global\\" << this_name << "_rcvr_sem";
rcvr_sem = CreateSemaphore(NULL, 0, 1, ("Global\\" + this_name + "_rcvr_sem").c_str());
std::cout << "\n Creating semaphore: " << "Global\\" << this_name << "_wait_sem";
wait_sem = CreateSemaphore(NULL, 1, 1, ("Global\\" + this_name + "_wait_sem").c_str());
return (rcvr_sem && wait_sem);
}
Sender semaphores:
// this sender connects to the wait semaphore in the target process
sndr_sem = OpenSemaphore(SEMAPHORE_MODIFY_STATE, FALSE, ("Global\\" + target_name + "_wait_sem").c_str());
// this target connects to the receiver semaphore in the target process
trgt_sem = OpenSemaphore(SEMAPHORE_MODIFY_STATE, FALSE, ("Global\\" + target_name + "_rcvr_sem").c_str());
DWORD intr_process_locking::wait(unsigned long period)
{
return WaitForSingleObject(sndr_sem, period);
}
void intr_process_locking::signal()
{
ReleaseSemaphore(trgt_sem, 1, 0);
}
Receiving thread function:
void intr_process_comm::rcvr_thread_proc()
{
while (conn_state == intr_process_comm::opened) {
try {
// wait on rcvr_semaphore for an infinite time
WaitForSingleObject(rcvr_sem, INFINITE);
if (inner_release) // if the semaphore was released within this process
return;
// once signaled by another process, get the message
std::string msg_str((LPCSTR)hmf_mapview);
// signal one of the waiters that want to put messages
// in this process's memory area
//
// this doesn't change ANYTHING in execution, commented or not..
//ReleaseSemaphore(wait_sem, 1, 0);
// put this message in this process's queue
Msg msg = Msg::from_xml(msg_str);
if (msg.command == "connection")
process_connection_message(msg);
in_messages.enQ(msg);
//std::cout << "\n Message: \n"<< msg << "\n";
}
catch (std::exception e) {
std::cout << "\n Ran into trouble getting the message. Details: " << e.what();
}
}
}
Sending thread function:
void intr_process_comm::sndr_thread_proc()
{
while (conn_state == intr_process_comm::opened ||
(conn_state == intr_process_comm::closing && out_messages.size() > 0)
) {
// pull a message out of the queue
Msg msg = out_messages.deQ();
if (connections.find(msg.destination) == connections.end())
connections[msg.destination].connect(msg.destination);
if (connections[msg.destination].connect(msg.destination)
!= intr_process_locking::state::opened) {
blocked_messages[msg.destination].push_back(msg);
continue;
}
// THIS ALWAYS GETS GETS WAIT_OBJECT_0 RESULT
DWORD wait_result = connections[msg.destination].wait(wait_timeout);
if (wait_result == WAIT_TIMEOUT) { // <---- THIS IS NEVER TRUE
out_messages.enQ(msg);
continue;
}
// do things here
// release the receiver semaphore in the other process
connections[msg.destination].signal();
}
}
To clarify some things:
trgt_sem in a sender is the rcvr_sem in the receiver.
`sndr_sem' in the sender is the 'wait_sem" in the receiver.
for call WaitForSingleObject with some handle:
The handle must have the SYNCHRONIZE access right.
but you open semaphore with SEMAPHORE_MODIFY_STATE access only. with this access possible call ReleaseSemaphore (This handle must have the SEMAPHORE_MODIFY_STATE access right) but call to WaitForSingleObject fail with result WAIT_FAILED. call to GetLastError() after this must return ERROR_ACCESS_DENIED.
so if we want call both ReleaseSemaphore and any wait function - we need have SEMAPHORE_MODIFY_STATE | SYNCHRONIZE access on handle. so need open with code
OpenSemaphore(SEMAPHORE_MODIFY_STATE|SYNCHRONIZE, )
and of course always checking api return values and error codes can save a lot of time
If you set the timeout to 0 WaitForSingleObject will always return immediately, a successful WaitForSingleObject will return WAIT_OBJECT_0 (which happens to have the value 0), WFSO is not like most APIs where success is indicated by a non-zero return.

Does DebugActiveProcess also track child processes?

Here's piece of code doing the main thing - attaching to an active process. Although it appears that child processes have not got caught as CREATE_PROCESS_DEBUG_EVENT in the switch.
Only CREATE(EXIT)_THREAD_DEBUG_EVENT and LOAD_DLL_DEBUG_EVENT are printed in stderr, though I know exactly that sub-processes are created (not threads). Please advise.
DebugActiveProcess(processId);
DebugSetProcessKillOnExit(false);
while (!done) {
DWORD status = DBG_CONTINUE;
DEBUG_EVENT debugEvent;
WaitForDebugEvent(&debugEvent, INFINITE);
switch (debugEvent.dwDebugEventCode) {
cerr << "Got event " << debugEvent.dwDebugEventCode << endl;
case CREATE_PROCESS_DEBUG_EVENT:
{
CREATE_PROCESS_DEBUG_INFO &info = debugEvent.u.CreateProcessInfo;
cerr << "process created " << debugEvent.dwProcessId << endl;
break;
}
case EXIT_PROCESS_DEBUG_EVENT:
{
EXIT_PROCESS_DEBUG_INFO &info = debugEvent.u.ExitProcess;
cerr << "process exited" << endl;
break;
}
case LOAD_DLL_DEBUG_EVENT:
{
CloseHandle(debugEvent.u.LoadDll.hFile);
break;
}
}
ContinueDebugEvent(debugEvent.dwProcessId, debugEvent.dwThreadId, status);
}
The documentation at msdn.microsoft.com says: "... as if it created the process with the DEBUG_ONLY_THIS_PROCESS flag ...".
This means: When debugging a process with DebugActiveProcess all threads of the process are debugged (of course) but child processes are by not debugged.
To debug child processes too, you may set a breakpoint to the first address of CreateProcess() (to be more precise: CreateProcessA, CreateProcessW, CreateProcessAsUserA, ...). When this breakpoint is entered you modify the flags field so the process is started in suspended state and when the function returns you call DebugActiveProcess.

RegisterWaitForSingleObjectEx() & several SetEvent()

I find a tricky behavior of multiple SetEvents with RegisterWaitForSingleObjectEx().
#include <windows.h>
#include <iostream>
using namespace System;
using namespace System::Drawing;
using namespace System::Threading;
VOID CALLBACK Callback(PVOID lpParameter, BOOLEAN TimerOrWaitFired)
{
String^ string = gcnew String("");
Monitor::Enter(string->GetType());
//wait for 2 seconds
for(int i=1; i<=2;i++) {
Sleep(1000);
cout << i << " seconds \n";
}
Monitor::Exit(string->GetType());
}
void main()
{
HANDLE eventhandle = CreateEvent(
NULL, // default security attributes
FALSE, // manual-reset event
FALSE, // initial state is nonsignaled
TEXT("WriteEvent") // object name
);
//register the callback for the event
RegisterWaitForSingleObjectEx(eventhandle, Callback, nullptr, -1, WT_EXECUTELONGFUNCTION);
BOOL bEvented[3];
bEvented[0] = SetEvent(eventhandle);
//Sleep(10);
bEvented[1] = SetEvent(eventhandle);
//Sleep(10);
bEvented[2] = SetEvent(eventhandle);
cout << "event0 = " << bEvented[0] << ", event1 = " << bEvented[1] << ", event2 = " << bEvented[2] << " \n";
}
I set the Event 3 times. So, I expect the callback to be called 3 times (please correct me if I am wrong).
But I get only 2 callbacks.
If I uncomment the lines //Sleep(10); , I get 3 callbacks.
What is happening here?
I am using Win7 64bit
UPDATE:
Can you please give an example about how to achieve this using semaphore?
Actual scenario:
I have a third-party library where I have to register a HANDLE to get notified about the occurrence of an event. Most of the times, I am able to get the notification (signalling on the HANDLE). Sometimes, I am not getting the correct "number of signalling", as expected.
I am passing the HANDLE created using CreateEvent() and registered a callback for the HANDLE using RegisterWaitForSingleObjectEx().
I suspect that this race condition is the reason for the behavior.
How to overcome this?
SetEvent on an event that's already signalled is a no-op. You have a race condition between the main thread that calls SetEvent, and the worker thread that waits on it (and resets it automatically when the wait is satisfied).
Most likely, you manage to call SetEvent twice while the worker is still running the first callback.

Mutex behavior on Windows

I've the following code...
On one machine it throws ERROR_ACCESS_DENIED and on other it throws ERROR_ALREADY_EXISTS (Handle is not NULL). I'd like to understand why two different behaviors. On both the machines user is a domain user part of local system administrators group. I tried running three instances simultaneously.
#include <windows.h>
#include<iostream>
using namespace std;
void * _hMutex = NULL;
void createMyMutex()
{
_hMutex = CreateMutex(
NULL, // default security attributes
false, // initially not owned
L"LockTest"); // named mutex
if (_hMutex == NULL)
{
cout<< GetLastError()<< " Error creating mutex handle"<<endl;
Exit(0);
}
if(GetLastError() == ERROR_ALREADY_EXISTS)
{
cout<< GetLastError()<< " Mutex already created" <<endl;
}
}
void Lock()
{
cout<<"Acquiring Lock..."<< endl;
if(_hMutex != NULL)
WaitForSingleObject(_hMutex, INFINITE);
cout<< "Acquired Lock." <<endl;
}
void Unlock()
{
cout<< "Releasing Lock..." <<endl;
if(_hMutex != NULL)
ReleaseMutex(_hMutex);
}
int main(int argc, char* argv[])
{
cout<<"Creating lock"<<endl;
createMyMutex();
cout<<"Lock create success"<<endl;
cout<<"Taking lock"<<endl;
Lock();
cout<<"Got the lock"<<endl;
cout<<"Waiting for 20 seconds"<<endl;
Sleep(20000);
cout<<"Wait over"<<endl;
cout<<"Releasing lock"<<endl;
Unlock();
cout<<"Lock released successfully"<<endl;
cout<<"exiting the program"<<endl;
return 0;
}
From MSDN:
If the mutex is a named mutex and the object existed before this function call, the return value is a handle to the existing object, GetLastError returns ERROR_ALREADY_EXISTS, bInitialOwner is ignored, and the calling thread is not granted ownership. However, if the caller has limited access rights, the function will fail with ERROR_ACCESS_DENIED and the caller should use the OpenMutex function.
So try using OpenMutex instead with just the SYNCHRONIZE access right.
Also note that the Windows type BOOL is different from the C++ type bool. So you should use the corresponding values TRUE and FALSE when calling Windows API functions that take BOOL, not true and false.
I guess you're getting the ERROR_ALREADY_EXISTS when calling createMyMutex(); and the ERROR_ACCESS_DENIED when calling Lock();. I's suggest to choose an object name in the global namespace. So you better use something like
CreateMutex( NULL, FALSE, "Global\\LockTest" );
See Object Namespaces on MSDN for details.