I had a go at running the a an exported windowed app on a Raspberry Pi on the suggestion that they should run using Wine and exporting a WinArm64 application. Well in short, no, but at length its a little more complicated.
Firstly if you want to install Wine on a Raspberry Pi, you’ll have to build it yourself. Expect this to take an hour or so, instructions here.
And basically the app runs with errors.
To reproduce it
- Compile Wine ARM64 on Raspberry Pi 5:
- Follow the guide above
- Verify GUI functionality (Wine notepad opens successfully)
- Create vvvv Application:
- Build vvvv patch targeting Windows ARM64
- Publish as self-contained:
dotnet publish -c Release -r win-arm64 --self-contained true - Verify deployment includes .NET 8 runtime files
- Run on Wine ARM64:
bash
ulimit -s unlimited
wine SkiaLinuxTest.exe
Crash Pattern:
0024:err:virtual:virtual_setup_exception stack overflow 1264 bytes
addr 0x6fffffd23d58 stack 0x7ffffe103b10
Debug Output Shows:
- Infinite EXCEPTION_ACCESS_VIOLATION at same memory address
- Recursive calls during .NET initialization
- Application reaches DPI initialization before crashing
- Stack overflow occurs consistently at identical address
What Works:
- Wine ARM64 GUI functionality (notepad, winecfg work correctly)
- Application loading and .NET runtime detection
- Initial Windows API calls (process affinity, heap operations)
What Fails:
- .NET 8 runtime initialization enters infinite recursion
- Application never reaches main window creation
Possible Root Cause
The issue appears to be a compatibility problem between Wine’s Windows API emulation and .NET 8’s initialization code on ARM64. The self-contained deployment should theoretically avoid Wine’s .NET Framework limitations, but the .NET 8 runtime itself triggers recursive behavior in Wine’s kernel emulation. This is a theory.
Self-Contained Deployment Expectations
Self-contained deployments bundle the complete .NET runtime, which should:
- Avoid Wine’s incomplete .NET Framework support
- Provide native ARM64 .NET runtime (coreclr.dll, etc.)
- Enable .NET applications to run without Wine’s managed runtime
However, even with self-contained deployment, the .NET 8 runtime’s low-level Windows API usage triggers Wine compatibility issues.
Memory Analysis
The consistent crash address (0x6fffffd23d58) and identical stack overflow size (1264 bytes) indicates:
- Deterministic infinite recursion
- Likely JIT compilation or runtime initialization loop
- Not a random memory corruption issue
I hope this is useful to the devs, cheers!
