IPC unavailable under WINE

[garyttierney]

Describe the bug

minidumper uses Unix domain sockets for IPC on Windows, which are currently unimplemented in wine and Proton.

To Reproduce
Steps to reproduce the behavior:

fn main() {
    minidumper::Server::new("socket-name").expect("unable to create socket")
}

CARGO_TARGET_x86_64_pc_windows_msvc_RUNNER=wine cargo run --target x86_64-pc-windows-msvc

Creating the socket will fail with an unsupported address family error.

Expected behavior
IPC works under wine.

Screenshots
If applicable, add screenshots to help explain your problem.

Device:

• wine-9.5-1

Additional context
Appreciate this is an odd use case, but figured I'd file it in case anyone runs into the same issue. For background my use case is catching crashes of a game I'm modding on Steam.

There is a patch available on the wine list but IIRC it needs tests: https://www.winehq.org/pipermail/wine-devel/2020-September/173277.html. I'll maybe see if I can pick it up and get it landed or maybe fork minidumper with support for named pipes (or send it upstream if it could be feature-gated or something?).

[Jake-Shadle]

Looking back on it, using unix domain sockets on Windows was a bit of a mistake, as it won't work on Windows versions that are a little older as well, and was mainly an excuse to have "the same" implementation on all platforms. If it would be changed though, named pipes would definitely be out of the question as they are far too different and annoying, but a simple regular loopback socket would be fine.

[garyttierney]

If it would be changed though, named pipes would definitely be out of the question as they are far too different and annoying

Tbh, that's a relief to hear for the reasons you've mentioned. I wondered if there was any reason crashpad was using named pipes instead of a simple loopback socket.

Happy for me to put a patch together for that or will I leave it to you?

[Jake-Shadle]

It's extremely low priority for me, so PRs welcome.

[gabrielesvelto]

Tbh, that's a relief to hear for the reasons you've mentioned. I wondered if there was any reason crashpad was using named pipes instead of a simple loopback socket.

There are reasons for that but they are tied to the way crashpad is used in Chrome. They use specific security descriptors to allow the pipe to work through an AppContainer sandbox. Additionally they enforce that only the processes that have been registered with the server can connect to it, by using GetNamedPipeClientProcessId() to ensure that the PID of the process connecting to the server matches what the server expects.

I don't think either thing can be done via regular sockets over loopback, but I also don't think either is needed for minidumper.

[garyttierney]

Ah, that makes sense! Thanks for the explanation and background. I'll have a PR up to swap to loopback by this weekend.