[Bug]: UNIX domain sockets fail when created in VFS virtualized directories

[mikehearn]

Version

Windows 10/11

Repro Steps

1. Write a Java 20 app that tries to establish an outbound TCP socket to any arbitrary internet domain.
2. Package it with MSIX. It doesn't have to use App Isolation, just Helium is enough of an app container to trigger this.
3. Install it.
4. Run the app. Observe that it crashes with an exception.

Unexpected Results

Exception as discussed here: https://mail.openjdk.org/pipermail/nio-dev/2022-November/012525.html

Analysis:

• The Java API supports cancellation/interruption, which requires a thread that's waiting on a socket to be wake-up-able from another thread. To implement this Java opens either a loopback TCP connection or in recent versions a UNIX domain socket, so it can use e.g. WaitForMultipleObjectsEx to wake up either on TCP traffic or when another thread tries to cancel the operation, which it does by writing a single byte to the wakeup channel.
• Outside of app containers this works.
• Inside of app containers this fails in a rather inexplicable way, in which creating the UNIX domain socket in %TEMP% works but connecting to it as a client does not.
• This causes Java to fail to establish the local cancellation connection and therefore the entire outbound network connection.

De-virtualizing %TEMP% using the AppManifest.xml fixes the problem, so the bug is definitely in Windows, most likely somewhere in bindflt or the UNIX domain sockets driver. Unfortunately, whilst de-virtualizing %TEMP% does fix the issue, it then causes the Microsoft Store to throw a fit and demand explanations about why it's being done, which seems to then trigger extended reviews and pushback.

So for App Isolation to work, bugs like this need to be fixed. Also please note: bugs need to be fixed in Win10 too, because the decision to ship an app as MSIX can't really be isolated to just Win11 users. But at the moment MS is not backporting fixes to Win10 and this makes MSIX harder to use. My company makes a product that packages apps for the desktop and this is one of the bugs we automatically work around.

[tiangao-ms]

Hi @mikehearn , it seems like this is an MSIX issue? We'll send this to our colleagues and see how they would proceed with this.

[mikehearn]

@tiangao-ms It's an app container issue, I'm not sure what team is responsible for that inside MS but as this is about Win32 sandboxing I guess it's not that important which team is responsible? Someone has to fix the bugs, right? The sandbox would depend on app containers regardless of whether MSIX existed or not.

[mikehearn]

@tiangao-ms Any update on this bug?

[iamcalledrob]

We are experiencing this issue as well, and it's not isolated to Java code.

We are creating unix domain sockets in Golang, and approx 5% of our Windows users are unable to successfully create them.

This occurs both when:

1. Writing to virtualized AppData path, e.g C:\Users\user\AppData\Local\Packages\MyApp_abcdefghijk\LocalCache\....
2. Explicitly writing to the non-virtualized path, e.g. C:\Users\user\AppData\Local\...

Creating the socket elsewhere, e.g. on the user's desktop, appears to work.

This is our #1 user-facing bug and is an absolute showstopper for those affected.

@tiangao-ms any updates here? This appears to be a significant bug in Windows.

[mikehearn]

@iamcalledrob the second path isn't non-virtualized, that's the virtualized path.

You can add some XML to your AppXManifest to de-virtualize a location under %TEMP% and that should then be usable without errors. See the discussion in the Conveyor user guide. Unfortunately I don't remember the XML equivalent - I think you need to express it in two different ways to handle different versions of Windows - but it's a free download so you could grab Conveyor and see what XML it produces.

Alternatively I suspect this bug may be fixed in newer versions of Windows? You could try asking affected users to apply all pending software updates, or otherwise ensure they're on the latest version. If that doesn't fix it then devirtualizing the FS is the way to go.

[iamcalledrob]

@mikehearn I appreciate the context, thank you.

De-virtualizing the temp folder has fixed the issue -- domain sockets created in both JVM and Golang code now work reliably. Linking to this thread when explaining why this was necessary to the Microsoft Store was sufficient to get this approved.

The issue seemed to be creating a domain socket in any virtualized folder, and we just to happened to be using LocalAppData\Temp as a sensible default location for these.

Regarding updates, this appears to be a bug in the current version of Windows -- at least to 24H2.

We even had some users reformat and reinstall Windows on their machine and the issue persisted, which makes me think this may be influenced by the hardware configuration, though there was no obvious commonality between affected users.

[mominshaikhdevs]

• Public Spec for Microsoft.Windows.Storage.Pickers WindowsAppSDK#5155 (comment)

---

this is yet another MSIX Issue, like this one:

• Immediate crash when trying to run as a different user WindowsAppSDK#2555.

and

• [MSIX] Provide Public API for launching App Execution Aliases over both WinRM and SSH. WindowsAppSDK#5258.