Summary: EventWaitHandle.OpenExisting() and MemoryMappedFile.OpenExisting() both failing but only on one PC out of a ~hundred.
Detail: I have a program that uses an EventWaitHandle to allow a client C# object to wait for a worker object to update some data shared through MMF. This is in a program that is installed probably on a hundred Win 7 and Win 10 PCs. Works great on every one expect on one stinking PC that a customer has kindly provided to test with... Acer Aspine V5 AMD A6-1450 1Ghz Win10 Home x64.
Here is the code that creates the EventWaitHandle in the client object...
var users = new SecurityIdentifier(WellKnownSidType.BuiltinUsersSid, null);
// Rule that allows anybody in the "Users" group to synchronize with us...
var rule = new EventWaitHandleAccessRule(users, EventWaitHandleRights.Synchronize | EventWaitHandleRights.Modify, AccessControlType.Allow);
var security = new EventWaitHandleSecurity();
security.AddAccessRule(rule);
Boolean created;
eventWaitHandleForCommands = new EventWaitHandle(
true,
EventResetMode.ManualReset, // Ignored. This instance doesn't reset.
"MyEventWaitHandle78AEE98", // Unique name
out created,
security
);
Here is the code that opens the EventWaitHandle in the worker object...
handleDomeCommand = EventWaitHandle.OpenExisting("MyEventWaitHandle78AEE98");
Here is the exception that occurs on that line when run on the Acer Aspine machine...
Exception = WaitHandleCannotBeOpenedException
Message = "No handle of the given name exists"
HResult = 8013152C
Now it gets more interesting... recall that I mentioned using MMF as well? So, I commented out the EventWaitHandle.OpenExisting() so that the worker object could move on to opening the MMF with the following call...
memMappedFile = MemoryMappedFile.OpenExisting("MyMMF_78AEE98", MemoryMappedFileRights.ReadWrite);
Which then bombs out with the exception below but only on this PC (about a hundred other installs it is OK!)...
Exception = System.IO.FileNotFoundException
Message = "Unable to find the specified file"
HResult = 80070002
By the way, the MMF was created in the client object as follows...
MemoryMappedFileSecurity CustomSecurity = new MemoryMappedFileSecurity();
CustomSecurity.AddAccessRule(new
AccessRule<MemoryMappedFileRights>("everyone", MemoryMappedFileRights.FullControl, AccessControlType.Allow));
mmfDome = MemoryMappedFile.CreateNew("MyMMF_78AEE98", MMF_CommandOffsets.MMF_Size,
MemoryMappedFileAccess.ReadWrite, MemoryMappedFileOptions.None, CustomSecurity, System.IO.HandleInheritability.Inheritable);
So, it seems this PC is jinxed but I've been around enough to know if it is a problem with one customers others will follow.
Other things I tried...
- Tried setting MS Visual Studio Solution Platforms from "Any CPU" to x86. Did not help.
- Thinking that this behavior might be due to the Acer Aspine PC being super slow, and the OS/NET-core might not have gotten around to creating the EventWaitHandle by the time my worker object opened it, I put 4 sequential message box pop-ups in between creation and "open existing"... did not help.
- Turn on/off Norton anti-virus... did not help.
- Install Norton anti-virus on another PC... my program works fine running with Norton on this other PC.
- Run as admin... did not help
- Tried putting "Global\" in front of the EventWaitHandle name... did not help.
So, looking for suggestions/thoughts. Thanks! /Chris