Persistent crashes in WIndows 10 with built apps

Targets Windows
1

This is very frustrating for me and my clients.
We are experiencing random crashes with built apps in Windows 10.
Happens in 32 as well as 64 bit apps - currently building with Xojo2019r1.1.
No crash dialog - app just disappears.
Often happens after app or window closes - but randomly.
Any ideas?

Consistently produces these event logs:

Faulting module name: XojoGUIFramework64.dll, version: 19.1.0.44759, time stamp: 0x5cdee53c
Exception code: 0xc000041d
Fault offset: 0x00000000001a0632
Faulting process id: 0x1e3c
Faulting application start time: 0x01d5a08f9dff1374

Faulting module name: XojoGUIFramework32.DLL, version: 19.1.0.44759, time stamp: 0x5cdee262
Exception code: 0xc0000005
Fault offset: 0x0014f1ab
Faulting process id: 0x18cc
Faulting application start time: 0x01d5a0903f949848

2

Do you use HTMLView in your app?

3

I do

4

Webkit (CEF3) or Native? (IE)? If Native, try using CEF.

5

And try 2019r2.1, because I believe they updated the CEF engine.

6

A stack trace shows clearly what method the crash happened in, what method called that method, and so on.

By default, macOS gives you a stack trace on crashes; Windows does not.

It is however relatively easy to get a stack trace on win32 using WinDbg:

  1. Build your realbasic app’s EXE as usual (make sure “App.IncludeFunctionNames” is enabled in the IDE)

  2. Install WinDbg, a free tool from microsoft:
    https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools

  3. Launch WinDbg

  4. Use WinDbg to launch your realbasic app:
    File/Open Executable… then choose your realbasic app’s EXE.

  5. Run your app normally until it crashes
    Note that winDbg may stop at a few places – just hit F5 key (“Debug/Go” menu) to keep going. Watch the log and you’ll see the crash. WinDbg may complain about “missing symbols” which you can ignore typically. (you can download more symbols which lets you debug crashes inside Win32 API itself, but that’s usually not necessary).

  6. For more debugging goodness, insert calls to
    System.DebugLog currentMethodName
    in your realbasic code

These debug statements will be included in the WinDbg log, which can help you figure out what’s going wrong.

7

Thanks. I tried the CEF and it still crashes. Same log.

8

r2.1 ?

9

Thanks Michael, I’ll try WinDbg.

10

WOOOOO! I think I finally found a solution for these random Windows 10 crashes on my MDI app:

At the end of my document window’s close event I put:

‘prevent crash on Windows when closing dim u as integer = ControlCount-1 for x as integer = u downto 0 if control(x)<>nil then control(x).Close next

I’ve been running the app on Windows 10 for hours now - no crashes! Maybe it’s a timing issue where Xojo and the OS are fighting over unwinding controls in the closing window. The solution is to beat them to it.

11

Nice workaround. My guess is that one of your controls is causing trouble. A common mistake is using a circular reference which breaks reference counting, e.g. the control has a pointer to the Window and the Window has a pointer to the Control, so when the window tries to close it can’t.

Another common mistake is accessing properties of a control or window during the window.close operation - you may be accessing a control which is already gone.