32-bit crashes

[sjoerd222888]

The GLControl seems not to work with 32-bit. When I run the OpenTK.WinForm.TestForm as 32-bit process the applications just exists immediately. In the Windows EventViewer I then see the following:

Faulting application name: OpenTK.WinForms.TestForm.exe, version: 1.0.0.0, time stamp: 0x60ef18c5
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc000041d
Fault offset: 0x00000001
Faulting process id: 0x2f64
Faulting application start time: 0x01d7905685e556d3
Faulting application path: C:\github\GLControl\OpenTK.WinForms.TestForm\bin\Debug\netcoreapp3.1\OpenTK.WinForms.TestForm.exe
Faulting module path: unknown
Report Id: cc3bdcfd-299b-4cea-89c7-ffa8a22a2e3d
Faulting package full name: 
Faulting package-relative application ID: 

[seanofw]

There are lots of questions here.

• Did you compile it yourself or use a precompiled Nuget package?
• Is it compiled for 32 bit?
• Are you using a 32-bit build of OpenTK 4 with it?
• Are you using a 32-bit build of GLFW with the 32-bit build of OpenTK 4?
• What was the exception raised?
• What was the exception's stack trace?

[sjoerd222888]

What I did was checkout out this repository. Then I edited the csproj file of OpenTk.WinForm.TestFrom such that it looks like this:

<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">

  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <UseWindowsForms>true</UseWindowsForms>
    <Nullable>enable</Nullable>
    <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
    <LangVersion>8.0</LangVersion>
  </PropertyGroup>

  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <PlatformTarget>x86</PlatformTarget>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="OpenTK" Version="4.4.0" />
  </ItemGroup>

  <ItemGroup>
    <ProjectReference Include="..\OpenTK.WinForms\OpenTK.WinForms.csproj" />
  </ItemGroup>

</Project>

To answer your questions:

• Did you compile it yourself or use a precompiled Nuget package? The project references the nuget packages from nuget.org
• Is it compiled for 32 bit? If IT refers to OpenTK.WinForms.TestForm.exe then yes. If you refer to OpenTK I would not know actually but I would have expected yes because if you build a nuget package you can add dependencies for x64 and x86 and I expected that the maintainer of the package takes care of such dependencies
• Are you using a 32-bit build of OpenTK 4 with it? As said I use the one from the repo. The way you ask the question probably means this nuget package only works with x64 and the maintainer did no handle the unpacking of the dependencies for both processor architectures in his nuspec file.
• Are you using a 32-bit build of GLFW with the 32-bit build of OpenTK 4? I use what comes with the nuget package.
• What was the exception raised? No exception was raised the application stops immediately. You only see something in the Windows EventViewer and this I have already posted above
• What was the exception's stack trace? There is no exception and hence there is no stacktrace. The application just stopped working.

[sjoerd222888]

I had a look at the nuget packages. Packages are created with Paket, that's nice :-). OpenTK.Core 4.6.4 seems to be a netstand2.1 library, not architecture specific, so should work on x64 and x86. Also OpenTk.Graphics seems not architecture dependent.

OpenTK.Redist.glfw seems to provide runtime specific files and includes files for both x64 and x86.

I cannot find where there should be an issue with 32-bit. Can you maybe elaborate where you would see the potential issue?

[sjoerd222888]

@seanofw can I provide additional information? Is there something I can do to help resolving this issue?

[seanofw]

I spent an entire evening debugging this tonight, and (A) I can reproduce it, but (B) I can't yet fully explain it.

The crash occurs deep inside the stack, beneath GLFW inside the Windows OpenGL code itself, which isn't very promising as answers go. We attempt to attach the native GL window as a child of the GLControl, and then the Windows User32 code itself crashes. It appears that when running 32-bit code on 64-bit Windows, the Win32 code itself goes through very different code paths than it would either as 32-bit code on 32-bit Windows, or as 64-bit code on 64-bit Windows: I can't tell if the bug is in GLFW or in the Windows OpenGL library or in the Windows User subsystem itself, but it's well outside the GLControl.

I suspect I can probably explain this better by building a debug version of GLFW itself, with symbols, and then catching every message in its WndProc to figure out which one is triggering the issue.

Either way around, this is an ugly problem, and it may actually be a bug in Windows itself: Right now, my only current recommendation is to stick with 64-bit builds if at all possible.

I'm posting a screenshot of the stack trace below so that next time when I get some time to attack this issue, I'll be able to remember where I left off.

[sjoerd222888]

Thanks a lot for looking into this. That looks a bit unexpected and also challenging to track down.

[PJB3005]

I was trying to debug this in windbg and compiled CMake from source to try to get debugging symbols. Curiously, compiling CMake stopped it from throwing an AV (though it still doesn't work correctly, the GL window isn't parented correctly).

[PJB3005]

After much more debugging and swapping out dlls, I now suddenly have it working completely on both x86 and x64 and I have no idea why, it just started working suddenly when I reverted back to the nuget dlls.

There is something very cursed going on here.

[PJB3005]

Ok, found it. OpenTK 4.6.4 and lower had broken GLFW calling conventions on 32 bit. This wasn't even GLControl specific. Upgrading to OpenTK 4.6.5 (or greater) fixes it completely as far as I can tell.

[sjoerd222888]

@PJB3005 Thanks a lot for investigating this.