Windows C# hosted libbox: memmod-loaded WinTun crashes (runtime.cgocallback / exitsyscall), file-backed loading is stable

[clever-vpn]

We observed a reproducible crash only in C# hosted mode (Go c-shared loaded by .NET), when WinTun is loaded from in-memory loader path (memmod).

Environment:

Windows
C# host (WinUI app process + service process model)
libbox built as Go c-shared
inbound tun enabled
Symptoms:

fatal error: exitsyscall: syscall frame is no longer valid
runtime.cgocallback in stack
sometimes process exit code -1073741819
Key comparison:

inbound tun disabled: stable
inbound tun enabled + memmod WinTun: crash
inbound tun enabled + file-backed WinTun (LoadLibraryEx): stable (10/10 runs)
pure Go test program + memmod: stable
Interpretation:
The issue seems specific to multi-runtime hosted boundary (.NET CLR + Go c-shared + native callback threads), not WinTun function itself.
Using Windows standard loader path (file-backed DLL) avoids the crash in hosted mode.

Proposed direction:

Keep file-backed WinTun as default in C# hosted scenarios
Keep memmod path for experimental/debug only
Consider documenting this constraint for hosted runtimes
Repro hints:

Set LIBBOX_DLL_FORCE_MEMMOD_WINTUN=1 -> crash likely in hosted mode
Set LIBBOX_DLL_USE_FILE_WINTUN=1 -> stable in hosted mode