App crash on Windows 10


#1

Hello there,

I’m experiencing a very weird behavior that I wasn’t previously. All new builds on Windows 10 64bit crash. Even the most basic OpenFL demo apps crash (like DisplayingABitmap). Neko builds also crash. All other targets seem to be working fine.

I’ve deleted and reinstalled Haxe with OpenFL only to see if it’s library related, crashes still happen right at the start of the apps. The Crash is the usual Windows popup: DisplayingABitmap.exe has stopped working. A problem cased the program to stop working correctly. Windows will close the program and notify you if a solution is available.

I tried 32 and 64 bit Haxe, the result is the same. I suspect it’s a Lime issue, was happy there was a fresh update this morning but every new build is still crashing.

Fortunately I have older builds of a few apps and they run without any issues, but new builds always crash.

I’m going nuts over here. Can anybody help with at least finding Windows logs to see what can cause the issue? Or is there any way to force an older version of the libs/dlls in command line to see if the issue is version related?

Thank you


#2

This is what I could dig up from Windows Event Viewer:

Faulting application name: DisplayingABitmap.exe, version: 0.0.0.0, time stamp: 0x5a87ac1c
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x00000000
Faulting process id: 0x1e08
Faulting application start time: 0x01d3a7a7430676d2
Faulting application path: E:\Shared Projects\OpenFL\DisplayingABitmap\Export\windows\bin\DisplayingABitmap.exe
Faulting module path: unknown
Report Id: 566e7ad3-7497-4660-941c-9ce3b7c4210a
Faulting package full name: 
Faulting package-relative application ID: 

Fault bucket 1570145022518089016, type 5
Event Name: BEX
Response: Not available
Cab Id: 0

Problem signature:
P1: DisplayingABitmap.exe
P2: 0.0.0.0
P3: 5a87ac1c
P4: StackHash_2beb
P5: 0.0.0.0
P6: 00000000
P7: PCH_4A_FROM_ntdll+0x0006ED3C
P8: c0000005
P9: 00000008
P10:

#3

Some updates regarding the issue:

Lime HelloWorld demo project:
lime test neko - works
lime test windows - works

Lime BunnyMark demo project:
lime test neko - crash
lime test windows - crash

OpenFL DisplayingABitmap demo project:
openfl test neko - crash
openfl test windows - crash


#4

Further investigation of the issue:

  • OpenFL 7.0.0 with Lime 6.0.1 does not crash
  • Lime 6.1.0 and 6.2.0 w OpenFL 7.1.* crashes

Maybe it’s a local issue, something with DLLs, I don’t know, but rolling back a few versions definitely made things better.


#5

Can you try building with the -clean tag and see if that fixes it. The DLLs may not be getting updated when you change versions.


#6

Of course I made the builds with deleting everything from the export folders previously. 7.1.* is definitely faulty, tested it on a clean Windows 7 as well


#7

Thanks for the report! I am also testing on two Windows 10 machines, and neither one has this issue, so if you can, your help would be really appreciated to try and figure this out.

You said that Lime BunnyMark is crashing, then I presume that Lime “SimpleImage” on Neko would also be crashing? If that is so, then let’s focus on that. Lime using GL to render an image appears to be an issue. We can ignore OpenFL versions and focus only on Lime.

Does Lime 6.1 crash, or is it only Lime 6.2 that crashes?

We added new system values, System.deviceModel, System.deviceVendor, System.platformLabel and System.platformName, System.platformVersion in that version. It is possible that could have an issue, but the code shouldn’t be running automatically, it should only be upon request. I do not believe that a stock Lime sample would call this.

There are some changes to how we access the OpenGL context, but it appears that OpenGL is working for you, at least as much as clearing the screen (Lime HelloWorld). It might also be worth checking if it indeed is running in OpenGL, or if it is falling back to Cairo. You could add a trace statement in a Lime sample to see which renderer it uses.

Otherwise I don’t see much that could affect Windows, (possibly) trying to roll back this change:

But I don’t believe that should be an issue, either


#8

Thanks for jumping in.

I’m moving on from AIR to OpenFL, working on an app for a client of mine, hopefully I can target 5-6 platforms with one code base (including the browser which is a top priority for them)

I’m sort of an update freak, I run “haxelib update” frequently – I just love whatever new stuff is introduced :slight_smile:

This is why I noticed the app crashes with the newest OpenFL while I did not experience it with the previous builds. To make sure it’s not a coding error, I rolled back OpenFL/Lime to previous versions and made some tests with the sample apps as well, tested it with Neko too to see if it changes anything.

So far OpenFL 7.0.0 is working fine, 7.1.* results in a crash while targeting Windows. iOS, Android, Mac, HTML5 builds are all working perfectly.


Results for the SimpleImage Lime app (the entire Export directory is purged inbetween builds):

Lime 6.2.0:

  • lime test windows - crash (Windows app crash dialog)
  • lime test neko - crash (Windows app crash dialog)

Lime 6.0.1:

  • lime test neko:
Called from Main.hx line 160
Uncaught exception - Invalid field access : set_format
AL lib: (EE) alc_cleanup: 1 device not closed
  • lime test windows: crash (Windows app crash dialog)

Results for the HelloWorld Lime app

Lime 6.2.0

  • Neko: traces “OPENGL” in console for this.renderer.type and works properly (although the app doesn’t do much)
  • Windows: crash without tracing anything

Lime 6.0.1

  • Windows and Neko: traces “CAIRO” in console for this.renderer.type and works properly

Results for the BunnyMark Lime app

Lime 6.2.0

  • Neko: crash
  • Windows: crash

Lime 6.0.1

  • Neko and Windows: throws an in-app dialog about “Unsupported render context” then exits. I suppose it’s normal behavior.

Maybe it’s worth noting that my developer PC does not have a dedicated video card, only the on-board Intel thingy is available. I know nowadays everbody’s rocking an NVIDIA GTXSR16000XTX in their rig, but I really love this machine, it’s perfect for development even without an expensive video card :slight_smile: Also the Windows 7 I tested the app on is a HyperV based virtual PC on the same Windows 10 host, so there’s also no dedicated video card. Maybe this is the source of all my problems. (All other platforms I tested on have their respective dedicated video hardware). Maybe it’s the lack of required OpenGL functions on the on-board video card, maybe it’s something else. Weird thing is that rolling back a few versions make me able to continue working on the app I mentioned.

Thank you


#9

I think we figured it out!

The HelloWorld results were telling – OPENGL on the new version, but CAIRO on the older. We had a version check on the OpenGL context, and would reject the context if it was OpenGL 1 – since it does not support shaders. I think this check broke in the changes in Lime 6.1.

I have a new build that may resolve this, would you mind trying it?

http://builds.openfl.org.s3-us-east-2.amazonaws.com/lime/lime-6.2.0-4-g43a6f05.zip

Download and run haxelib install path/to/downloaded.zip to install it locally


#10

yay!

all the OpenFL sample apps and more importantly my app is working again without crashing (OpenFL 7.1.2, Lime is the new build from your zip)

one of the Lime sample apps is still crashing (SimpleImage) but that could be totally unrelated. rest is perfect!

thanks for looking into it!


#11

Thanks! That’s been fixed too :grinning: