Strange Windows 10 Crash

I’m working with a customer on an application that runs great for me on Mac and Windows 11.
I don’t have a Windows 10 system to replicate this on but they can consistently repeat this within their corporate- configured machines.

After about 7 minutes, the app shows a visual glitch across the main window and crashes.

Some of the potentially relevant details are in the crash report:

  • Fault Bucket XXXXXX Type 4

  • VCRUNTIME140.dll

Nothing else seems traceable at all.

I’m guessing it’s a memory issue which is why it takes time to build up before a crash.

Any ideas?.. other than “use a Mac!”

Thanks in advance.

Do they have any Windows 11 or Windows 10 machines that work without issue within their environment?

Corporately they don’t use Windows 11 yet.
I can ask them to test on additional machines but I think it’s going to be identical as they have a very consistent setup.

Update. I just replicated it on Windows 11 within Parallels.
The app hung with the same visual glitch. I was running a remote debug session and it dropped into the IDE but not at any line in particular.

I have zero idea how to trace this.

What is your app doing when it crashes?

Nothing.

We only develop on Windows and we have never seen anything like this. Since it is happening consistently, there must be something in your app causing it. What about timers? Plugin controls? Are you using a Canvas? Something has to be running, I would think, to cause this crash.

Yes to plugins. Yes to canvases. But they aren’t running on a timer.
I have many solutions running on Windows and I’ve never seen it either.

That is sometimes a RuntimeException within the framework itself. Notably you can see this happen in Web. Other types of framework errors (non-catchable non-exceptions) usually pop up with that smaller MsgBox looking window.

I also find it interesting that the Visual Studio C++ runtimes lib is something you pinpointed in the crash report.

It could be relevant, what version of Xojo are you using and what architecture are you building for?

A little more. Repeating it again I got this crash report from within Xojo.
Looks like it is within a desktop control, canvas, or maybe graphics context. I dont understand the details.

@Tim_Parnell , platform info is in the notes below.

OS: macOS 13.4.0 (22F66)

IDE Version : 2023 Release 1.1

Remote platform : Windows Other
Remote IP : 10.211.55.4

Location: DrawableD2D.cpp(859)

Condition: mDCLockCount > 0

Message:

Platform:

Yeah, the “Location / Condition” MsgBox is the one I was thinking of for Framework-level errors.

Unfortunately, I don’t have any good advice for debugging these. The last one I had some time ago, I believe I line-by-line debugged until I found the offending function. I don’t think I ever resolved it, only worked around it.

my favorite part is that it only happens after 7-10 minutes… so iterations take forever to do.

do you move other windows over your app and it get repaint events?

have you looked if this Visual C++ Redistributable have the latest bug fix?

you could set a flag inside of the app via menu and ignore paint or other events to see what happens then.

Are you using the “Include Runtime DLLs” option when building the app?

@MarkusR good discussion.
I haven’t looked at the latest Visual C++ Redistributable I should.
I’m trying a bunch of things now and considered making the canvases all visible=false to see if that changes anything.

I have tried both leaving the app running with zero else going on in the system, including no mousing around. It keeps happening. Interestingly the application memory usage never gets too high.

i would also test what happens if you start the same app one minute later.
means two of the same app running then.
and maybe a third fresh app project if it does behave same.

logging all possible events/methods would help to get the last state of your app.

or maybe run the app as 32 bit because i remember xojo in 64 bit could behave different where the app just stop without error.

I’m having some luck making groups of controls invisible. Once I figure out the culprit I can address it directly.

1 Like