New WebView2ControlMBS crash & workaround

Hi all,

If in the last two weeks your projects using WebView2ControlMBS have started mysteriously crashing on load, this thread is for you. I’ve spent dozens of hours on this issue so I’m going to detail my findings here. @Christian_Schmitz is aware of the issue and has said he’d look into it.

On Feb 1 I started getting messages from clients that my deployed app suddenly stopped launching. I haven’t pushed any updates in 2024 so this was very strange.

I also could not get the project to run even in the Xojo IDE, the main window would flash on the screen and then the project would just quit without any errors or exceptions. What’s more, old versions would no longer run either.

After taking the whole app apart by the process of elimination, I traced it back to WebView2ControlMBS.

On Feb 1, Microsoft pushed Edge v121.0.2277.98. Once the user’s Edge updates to this version and they restart their computer, the bug appears. But it’s under very specific conditions:

  • Edge v121.0.2277.98 or higher
  • You have a WebView2ControlMBS control and either a Xojo DesktopHTMLViewer (API 2) or Xojo HTMLViewer (API 1.0) with WebKit rendering on the same window
  • The Xojo HTMLViewer control is loaded by the framework before the WebView2ControlMBS control

If all these things are true, the WebView2ControlMBS’s internal CreateCoreWebView2Controller function call fails and the host application quits.

The workaround is to manually edit your Xojo project so that all instances of WebView2ControlMBS controls appear prior to any instances of DesktopHTMLViewer controls. If you’re like me and only have Xojo platform licenses, this will require the use of Arbed to convert your project to XML.

Edit the XML in a text editor and find your window. Find the <Control></Control> entry for all the WebView2ControlMBS objects (in the project source they are called DesktopWebView2ControlMBS objects) and moving them to the top of controls section for that window.

Arbed seems to be missing some of the new elements of the xojo binary format so it may be necessary to open your old project alongside your modified xml and copy/paste from the xml project to your original project. Of course if you have a Pro license you’ll be able to do all this without Arbed at all.

And of course, you can also work around this problem by not having HTMLViewers and WebView2ControlMBS controls in the same window (having unique windows for each OS that only use one or the other). If you are using an old API 1.0 HTMLViewer control and can get by using Native (Internet Explorer) rendering then switching to that will work as well.

Anyhow, this resolved the crashes for me. If anyone else has this problem, I hope this post saves you the 30+ hours I’ve spent troubleshooting it this week.

Hopefully @Christian_Schmitz can find a more elegant solution in the code for the control and push it out as an MBS update, but this is a Microsoft bug and it may not be something he can do anything about. Waiting around for Microsoft to fix anything is a fool’s errand, of course, so this approach may be necessary for a while for those of us who mix WebView2ControlMBS with DesktopHTMLViewer controls in the same window.

2 Likes

That is exactly what I’m doing, so that is why I don’t see this issue. Indeed, on Windows I only fall back on the HTMLViewer if WebView2 isn’t available; I’m guessing this is what you’re doing. This should only happen on older systems, where IE rendering is still a thing (it even works on my Intel Windows 11 VM–I’m not sure whether that might only be because it is upgraded and not a clean install. ARM is a different story.)

BTW, I use the legacy HTMLViewer in my Windows projects precisely because for the IE rendering. My main use for it is for my help window. Were I to use the DesktopHTMLViewer, my app winds up using practically the size of Firefox–again, for no other reason than the help book. :stuck_out_tongue:

My customer had exactly the same experience. All of a sudden the same version of the desktop application that worked the day before crashed at startup. Finally I discovered that the problem was with WebView2ControlMBS (web browser) and DesktopHTMLViewer (agenda) on the main screen. The web browser was extra on the main screen so I decided to remove the web browser until this problem is solved.

So until we can find the reason and possible fix it, please either

  • make sure WebView2ControlMBS initializes first in a window before HTMLViewer. e.g. control order makes the MBS control first.
  • put WebView2ControlMBS and HTMLViewer on different windows.
1 Like

I got the new WebView2 version in v121, but it doesn’t crash here, independent of whether I have HTMLViewer first or WebView2ControlMBS first.

We’ll keep an eye on it…