Wine and Win-Arm64 and Raspberry Pi

vvvv gamma bug
1

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

  1. Compile Wine ARM64 on Raspberry Pi 5:
  • Follow the guide above
  • Verify GUI functionality (Wine notepad opens successfully)
  1. 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
  1. 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!

2

Maybe check out hangover.

3

Wine, hangover… What’s going on 😂

2 Likes