I have a client that reports the following. He has 4 programs of mine, all built with Xojo within the last month, very similar in nature. This is on Win11. One of them opens up. The rest crash, crash log below. The crash is quick and never even gets to my log file opening etc. The same programs, with the same installers, all open on his Win10 machine. What I find interesting is that the crash lists the offending module as XojoGUIFramework64.dll, not the actual app name.
Exception 0XC0000005 is a an access violation error. DId you had a look at Windows logs, you may get more inforrmation ?
Do you have an unhandle exception method ? With that you would get information from inside Xojo and could write that information to the log in the IDE.
Identifying the line in the code that crashes your app would provide clues to work on.
I believe you are using a 2021 version. I recommend a 2023.4+
Lots of XojoGUIFramework64.dll crashes were reported when using lower than 2023.4 versions affecting just some specific newer machines.
This just means it crashed anywhere in the Xojo framework code.
You can try to add some logging to figure out which line causes it.
And you can check with the current version to verify it’s not fixed already there.
I remember lots of search and few adjustments during 2022 and 2023 looking for this crash no one could explain, the last fix I remember was made on 2023.4, where William found a loss of sync between destructors and the run loop in the 2023.3.
Probably just another timer based mess. In some machines it worked, in some it crashed, in many complaints, users said the crashing ones were faster new ones. Related? Maybe. But I don’t remember more XojoGUIFramework64.dll crashes after 2023.4 and reports were closed.
I figured, but then I have to pay for it and I’m not a big fan of paying for bug fixes, and with all the boatload of adjustments and even new bugs that comes with updating. We all know the story… sigh
It’s strange though, because I have many Win11 clients, and we have our own Win11 system, and it doesn’t crash there. It’s just this one guy. As for Christians suggestion of debugging, I don’t know what that means because I can’t debug on this machine (it’s a client far far far away) and I don’t know how to debug the framewrok DLL (can you even?). As I said, on my apps I’m setting up the written log file at the earlist moment possible and it’s not even getting to that.
William was pursuing the problems and making changes.
Same thing. Most systems work, few machines trigger the bug and crash.
Is it 100% safe now? Don’t know, but I don’t heard complaints like those for the last 3 months. But it is the most stable one on the issue. You won’t fix the problem not applying the current changes.
If your code doesn’t execute in the app.open event, this is most likely out of your hands. If it’s only happening for this one client, then chances are it’s something specific to their setup, localization, AV software, etc etc
Not having a stack trace makes it much harder to track down. My first suggestion would be to attempt to replicate the customers setup. Sometimes this is enough. Failing that, you may have to bite the bullet and try a new version of Xojo, in fact you may have to do that anyway…
If you do not have a < 1 yo fast machine, ask your local Windows computer reseller if you can run your software on one of his recent/faster machine and use an external HD/SSD to do that.
Are we sure the Exe file has not been renamed ? Doing so on Linux and Windows with Xojo App would cause such framework crash before you get Open event…
Not simple as that. Maybe a combination of factors. Even a graphics card in a specific machine can be involved. A super-fast machine with i7 can work ok, and a lower clocked i9 could crash, etc. The hardware and software involved in those cases should be analyzed trying to figure out the common causes.
Thanks for all your replies. I prefer to not pursue things that I’m not really qualified to figure out. The conclusion of that the older Xojo’s may not generate workable EXE’s that work on Win11 is enough for me.
I may not be understanding what you are saying, yet.
There’s no guaranties that libraries from other versions can work without flaws, some are compatible, some will crash right away, some will do random things, some will do things like an exception c0000005. No PRO would make such stupid move. Without Xojo consent saying x lib from version y can be safely replaced by a copy of the z version. No one doing such thing could even ask for help. So, no, that should not be the case.
Not sure, compile one copy, test, if ok, send to that client with problem. Check if his problem goes away. As I said, the last case I heard seems solved at 2023.4
