I have an app where I use a mutex to prevent another instance of the app from running. I create the mutex just like the example in the doc shows, but I do not kill it as shown in the docs.
This has been working fine for several years. Now, I have one user reporting that he can’t start the app because he is getting the error message I display when the mutex cannot be created. He is running Windows 10. I tested the app in Windows 10 and I’m not getting this message unless I actually try to run a duplicate instance.
I tried creating a small app for this user that would execute an mutex.leave using the same name as the one in my app, but then he gets the error message saying that the thread which Signaled the Mutex must be the thread to Release the Mutex. Of course, this makes sense. I also had him reboot the computer. He reports the the task manager confirms there is no program with the name of my app running when he gets the error.
My question is, how can this happen? In searching the forums, I see I’m not the only one to rely on the app quitting to nil the mutex. What can be done to correct the problem?
Clearing their temporary files may help.
If the user is willing, have them download Microsoft’s Process Explorer. They can use it to search (ctrl+f) running processes for the mutex by name.
Thanks for this reply. I downloaded this software and was able to find my mutex. What I don’t understand is that it was pointing to C:\Users\Administrator\AppData\Local\Temp\BeyondCategory_SoundCatalog. I guess this is a hidden file in Windows. I could not find the AppData directory using Windows Explorer. I’m the first to admit, I’m not Windows savvy. I create Windows apps because XOJO makes it easy enough for me.
Thanks for this helpful info. I’ll pass it on to my user who is likely more savvy about Windows than I am.
Following up on this, my user was able to use Process Explorer. Unfortunately, he reports that it is not showing any mutex using the name my app uses. He also reports that he shut down the computer without first quitting the app - something out of the ordinary for him. I’m thinking that would have something to do with this.
It is easy enough for me to change the setting of the mutex in my app. Instead of quitting the second app, I’ll just throw the warning and let the user handle it. The way my app works, it is unlikely this would be needed anyway.
But it bothers me that this could happen. What if I needed the mutex? Surely this must happen with other programs. What would be the scenario a none savvy user would employ to fix this? If I need the mutex, I can’t ignore the failure to set one. I don’t see how I could protect against this in my app.
Has the user cleared the temporary files? The doc page for Mutex notes that the SpecialFolder.Temporary location is used to store the mutex so it would seem something in there is “stuck”. Getting that folder cleared out (or at least the Mutex) ought to help.
AppData is a hidden folder so you’d have to change the Explorer settings to show hidden files and folders or use the command line to get to it.
One of the side benefits of having this problem was it forced me to learn how to expose hidden files in Windows. That said, as I’m not a professional developer relying on this app to put food on the table, I’m reluctant to advise anyone to clear out the Temp folder without being there myself to see how it goes.
But, it seems I could write a small app that looks for that file and delete it. Is that correct? As mentioned before, I created a small app to release the mutex but it didn’t work because the mutex will only release if signaled by the thread creating it. It seems that deleting the file would be possible and it would solve the problem.
Am I missing anything using this approach?
That should work, presuming there are no other issues (permissions?) at play on this user’s computer. I feel like a Windows restart would clear the temp folder, but maybe that’s only a thing on Mac and not on Windows. There’s also a Disk Cleanup tool built in to Windows that can also clear temporary files.
It appears Disk Cleaner will not touch my mutex file. I created the mutex and then force quit the app via the Task Manager. The mutex file remained, but Disk Cleaner ignored it.
I changed my little app that creates and clears a mutex to also delete the file. While monitoring the temp folder in Windows explorer, I can see the file get created when I create the mutex. The Delete button returns a 104 error when I try to delete it right away. If I force quit the app and restart, then the delete button will remove the file successfully.
So, it appears I have a simple app to provide to my users for fixing this issue cleanly.
I do appreciate all the help. Even what didn’t work was educational for me and surely will be useful down the road.