Share named mutex between UWP and desktop app

Question

Is there any way to share a mutex between a UWP app and a desktop bridge app in the same package? They seem to have different namespaces; using the same name doesn't yield the same object between the processes. The UWP app's objects are, according to WinObj, stored in a special namespace under AppContainerNamedObjects\{APP_SID} rather than under BaseNamedObjects like usual. However, the desktop app - despite running from the same app bundle - does use the BaseNamedObjects namespace, and consequently the two processes can't share synchronization objects.

Is there any way around this? The best I've thought of involves silly things like checking for files to exist or not, but this is both overly complicated and underperformant. Mutexes are simple, fast, and designed for exactly this use case (synchronization across processes); can they just not be used here?

Telophase

did you solve this issue? – Kamalakamaria

@Kamalakamaria Not exactly, no. Desktop apps can access the AppContainerNamedObjects namespace (and its sub-namespaces), but this is a total hack; per MSDN, you're not supposed to have path separators in mutex names, and it's easy to code for the case where either the Store or desktop app reliably starts first, but kind of tricky for when either one might. – Telophase

How can a desktop app access the AppContainerNamedObjects namespace? What is the total hack? I need this just for testing, not for a production app. – Drawback

@ericfrazer Using winobj from Sysinternals, you can find the path that is used for AppContainerNamedObjects. It's in a subdirectory of BaseNamedObjects, IIRC (I'm not at a Windows box right now). You can (even though MSDN says you can't) access or create that path by putting ` characters in your object name, just like you would for a file. The object path will be treated as relative to BaseNamedObjects`. Watch for weird behavior, like the UWP app might not be able to open the object if it is created by the desktop app, and the path won't exist if the UWP isn't running. – Telophase

EDIT to the above comment: you do it by putting `\` characters in your object name, just like you would for a file. – Telophase

Answer 1

You can share a mutex between UWP and desktop, though I don't know if it's a hack. I know, I just tried it. On the C++ side, you call CreateMutex, then (somehow), you get told via interprocess communication the PID of the UWP app. Then, you call DuplicateHandle with SYNCHRONIZE acess on the mutex you created. Then, you pass these handle ID's to the UWP app which now owns the mutex and can wait on it. In the UWP app, you need to create the mutex, then call SetSafeWaitHandle( ) on it with the mutex ID you passed it. it's hacky, but it seems to work. What I can't figure out is why it won't work for AutoResetEvents. Crazy.

Drawback

This works, but requires that the Win32 app start first (or at least, that the UWP app doesn't need the mutex until the Win32 app starts) and that you have an IPC channel between the apps already. – Telophase