Crash after Quit, only on Windows

I develop on Mac and then port to Windows.

Occasionally I run into this: the app crashes after quitting on Windows only, brings up the “This application has stopped working” window after all the windows of my app have disappeared. Works fine on Mac.

When I put a break point somewhere in a Close event, and try to see what triggers the crash, and step through the close process, then Xojo freezes before the process is complete, sometimes crashing itself and bringing up the same “this application has stopped working” window.

What causes this, and how do I fix it?

I use Mac but i have VMWARE with windows 10 for test and XOJO on Windows

Well I write the apps in Xojo on my Mac. Then I copy the project and resources to my Toshiba laptop and work within the Xojo IDE on Windows to tweak my code for that OS.

Can anyone answer my question please?

I have seme problem one and i delete that form and add new one on windows then it works with no problem.

I’m sorry but I don’t understand what you’re trying to say. Delete and add a new one of what?

sorry
the form you have the problem when you quit delete the form and add on windows and try.

do backup off you projects

I figured this out.

It has to do with different timings for object destructors on Windows versus Mac. Just as objects are created in a different order, they are also destroyed in a different order, so sometimes at both startup and shutdown a call to an object works on Mac and doesn’t on Windows (and I assume vice versa would also be true though I’ve never run into that because of the way I work).

In other words, my app was crashing because it was trying to get data from an object that was already destroyed. A couple of lines of workaround code fixed it.

Aaron,

Could you describe your workaround? I’m in the process of understanding /fixing the same issue.

There is no simple remedy, as each app has its own characteristics.

As a general rule, avoid addressing controls in the Close event of windows and app. Prefer CancelClose.

Avoid long processes there as well.

Another frequent cause of crash is a thread still running.

And if the Windows crash dialog shows you’ve encountered a BEX exception, it might be related to an issue that Xojo recently fixed.

What IDE version are you using?

The important part of my point is “as a general rule”. It has nothing to do with the recent Bex issue.

Michel…yes of course. Your advice was very good. I just wanted to tell the OP of another possible source of the problem he described…

Why do you think my comment was directed at your’s?

That is all the interest of quoting…

Without quoting a particular reply, I believe a comment should be taken as addressing the original question… which was my intention. Even though the OP seemed to have fixed his issue by rearranging his code, his symptoms matched exactly the BEX issue which has recently been fixed so I wanted to mention that he should look into that possibility too.

Whatever. Have you BEX and be happy.

Have the same issue. Stepping thru and looking at what exists as app closes, there doesn’t seem to be anything that should be causing this - windows, threads, menubars, etc are all gone. The MDIWindow has handle ‘0’ and I’m not using it. There are 2 floating windows created at ‘open’ and nothing happens in their ‘close’ events except the MainWindow checks to see if it was closed and issues ‘quit’ if app wasn’t already quitting.

I have cleaned up my code quite a bit trying to suss this out, but am at a loss at this point.

Are you using Declares ? Make sure they are using the right Windows APIs to Xojo data type conversion. If you have the wrong type somewhere, you can have random crashes like this.

Thanks for reply Julian - I have one Declare :

Declare Function QueryDosDeviceW Lib “Kernel32” ( name as Ptr, target as Ptr, bufChars as Integer ) as Integer

This is part of some code to more quickly sort thru the COM ports on Win. (App is ported over from RealBasic version - it’s pretty old.) Looks like that QueryDosDeviceW should return DWORD which maps to UInt32 on your ref doc. (?)

I tried changing to UInt32 but no luck. I will look and see if there’s better way to deal with COM ports though - that method has given me some trouble sporadically.

I’d go with:

Declare Function QueryDosDeviceW Lib “Kernel32” ( name as WString, target as Ptr, bufChars as UInt32 ) as Uint32

If you can, temporarily run a bypass on this QueryDosDeviceW call and see if it crashes.

If it doesn’t crash when you bypass this, you know this is the problem.

If that is the case, check how you allocate your lpTargetPath and make sure its the right length, not running over the end and wiping out some memory which could cause the crash.

Wow - I’m going to e-mail you an ale. That did the trick. Thanks!