Shortly after upgrading to Fusion 12, I moved some Windows builds to my Windows VM for signing and packaging. I was disconcerted to find that they (and, from what I could see, “only” my Xojo-built Windows apps) would crash the VM when launched.
My short term workaround was to get the old Windows VM image from backup, and this time decline the offer to “upgrade” the machine.
VMWare’s forum already had a thread along these lines, from a user running a trading app called Tradestation 10. VMWare could not test this because you can’t even get the app without an account. When I mentioned Xojo, the issue was reproduced and they provided this official workaround:
(snip)
Power off the VM and add
guestinfo.svga.wddm.enableGDIHW=FALSE
to your .vmx file, then power it back on.
This will disable GDI HW acceleration only and have no larger affect.
(/snip)
This fixed the “upgraded” machine. Hope this little heads-up saves someone a headache.
I was on 2020r1 at the time. I don’t know whether that mattered. The VMWare rep said they reproduced it on “Xojo”, by which I presume they meant the IDE. If they just downloaded it then and there it would have been that.
Future Jerry: On reflection, existing apps of mine (not just the new ones), that were already on the VM, would also blue-screen. The IDEs in which they were built would have gone back at least a couple of releases.
In App.Open set the following environment variable: System.EnvironmentVariable("XOJO_D2D_SOFTWARE_RENDERING") = "True"
This worked. Thank you!
As you might guess, I had to test this with a built app, because the debugger stub would bring the system down. For that reason I have disabled the acceleration for now, until/unless I decide to tinker in the Windows environment (as you also describe in the other thread.)
I am also attaching an image of the BSOD. Its message is identical to that of the OP in the VMWare forum, who was writing about Tradestation 10.
There are some situations/environments where Xojo’s Direct2D Implementation (using Hardware Rendering by default) doesn’t work well… So I’m glad to hear that this (still undocumented?) environment variable actually works and helps!
@William_Yu - what do you think about the “blue screen - printscreen”? Can you make anything out of “PFN SHARE COUNT” and relate that to what the Xojo Framework might do to trigger that (which it doesn’t by using SoftwareRendering)?
Well, in my case this only happened with the upgrade to Fusion 12, and only then by accepting the “upgrade the machine?” dialog. So yes, it’s a good question.
Well, yes - that’s interesting and one certainly is curious to know… but I really hope that’s not the Xojo engineer’s first thought In their situation, I’d be a bit scared why the “Xojo GUI framework” is causing a BSOD! There is something wrong.
One can argue this being an issue with VMWare Fusion… however, there are other reports on “real machines” which show very similar issues with Xojo’s Direct2D implementation (especially with dual graphic cards). e.g. <https://xojo.com/issue/54979>
That we now can easily reproduce a BSOD with VMWare Fusion is a chance for Xojo to reproduce it.
Something is not quite right with the default “Hardware Rendering”. That’s easily proven by disabling it. e.g. such as @Jerry_Fritschle explained above → disable it for the entire VM. Or by just setting an environment variable to let XojoGUIFramework use just Software Rendering.
If this reproducible situation can be fixed, there is a chance it improves the reliability of Xojo built apps on “real hardware”, too!
Meanwhile… we’ll continue to use the environment variable within our built apps to enable Software Rendering. We’ve had several customers with issues otherwise. For not graphics intensive software this is currently best… to have a Xojo built app be reliable on most customer’s systems.
But I’m looking forward to a more stable Direct2D Hardware Rendering implementation in Xojo!
In their situation, I’d be a bit scared why the “Xojo GUI framework” is causing a BSOD! There is something wrong.