Ok, after considerable digging with a debugger, and doing some experimentation, I have a much better handle on what's going on here.
The failing CreateMutex call is trying to create the Named Mutex "_NICAN_FRM_DEVICE@CAN9". The call is failing the second time I call ncOpenObject. The way my application uses NI-CAN is by opening the interface using a set of default attributes. Then, under some circumstances, it closes the interface, changes some attributes, and attempts to re-open the interface. It is the second open attempt that is failing. Since I can't change attributes without closing and re-opening, I have to make a second ncOpenObject call. One of the key aspects of this failure is that the second ncOpenObject call is made on a different thread from the first call. Now the parameters to the CreateMutex call in the NI-CAN DLL specifies NULL in the lpSecurityDescriptor of the SECURITY_ATTRIBUTES structure. This implies the use of the DEFAULT SecurityDescriptor for the newly created Mutex. The problem arises because the default SecurityDescriptor within the ASPNET web service process is different from the default SecurityDescriptor of a user application. Because I close and re-open the interface on a different thread from the one used to originally open it, the second call fails in the web service context but not in the normal user context due to the different SecurityDescriptor's.
This documentation: http://msdn.microsoft.com/en-us/library/ms682411(VS.85).aspx addresses the situation in which a second call to CreateMutex is made with the same NAME. It says "The handle returned by CreateMutex has the MUTEX_ALL_ACCESS access right; it can be used in any function that requires a handle to a mutex object, provided that the caller has been granted access. If a mutex is created from a service or a thread that is impersonating a different user, you can either apply a security descriptor to the mutex when you create it, or change the default security descriptor for the creating process by changing its default DACL. For more information, see Synchronization Object Security and Access Rights."
I see several ways of addressing this problem. First though, I have a question. Why is a second attempt to call CreateMutex happening at all? Mutex handles can be shared among multiple threads, as I understand them so there is no reason to call CreateMutex a second time for a given interface. If the second call is necessary, then, if it fails with the ACCESS_DENIED error, it would be appropriate to call OpenMutex which should succeed in getting a second handle to the already existing Mutex. A third approach would be to specify a SecurityDescriptor which would allow other threads to successfully call CreateMutex after the Mutex already exists. This last method would address the situation in which multiple Applications were attempting to concurrently access the same interface regardless of the default SecurityDescriptor they were running with.
I hope this clarifies the situation and points the way to a timely correction to this problem.
Thanks for reading.
Richard
