0

Recently, my application has crashed when trying to display a rather lengthy (but otherwise simple) HTML e-mail. The crash was caused by mshtml.dll getting a stack overflow (exception code 0xc00000fd). Of note here is that this didn't throw an exception but it actually just crashed the program as a whole. The error was retrieved from the Windows event log.

In the process of debugging, I created a smaller sample solution to try and narrow down the issue. However, not only does it work fine in the sample solution, it behaves completely different from the main program despite running the same code even for the simplest of HTML strings.

The code is as follows:

var webBrowser1 = new System.Windows.Forms.WebBrowser();
webBrowser1.AllowNavigation = false;
webBrowser1.AllowWebBrowserDrop = false;
webBrowser1.Navigate("about:blank");

var doc = webBrowser1.Document.OpenNew(true);
doc.Write("<HTML><BODY>This is a new HTML document.</BODY></HTML>");
var count = doc.All.Count;
var html = doc.All[0].OuterHtml;

In the sample solution this evaluates to:

count = 4; // [HTML, HEAD, TITLE, BODY]
html = "<HTML><HEAD></HEAD>\r\n<BODY>This is a new HTML document.</BODY></HTML>";

Meanwhile in the main program it comes out to:

count = 3; // [HTML, HEAD, BODY]
html = "<html><head></head><body>This is a new HTML document.</body></html>";

These are small discrepancies but that is largely due to the simple HTML used. The one that causes the crash has rather significant differences.

I am absolutely stumped as to how the result can be so vastly different.

The documentation for HtmlDocument.Write(string) states that:

It is recommended that you write an entire valid HTML document using the Write method, including HTML and BODY tags. However, if you write just HTML elements, the Document Object Model (DOM) will supply these elements for you.

But I have no idea how the DomDocument is provided nor why they would be different in the first place. Both solutions are running in x64 Debug mode and Net-Framework 4.6.2. Both load the module: C:\WINDOWS\assembly\GAC\Microsoft.mshtml\7.0.3300.0__b03f5f7f11d50a3a\Microsoft.mshtml.dll

How is it possible that these produce different results?! Any and all help welcome. Thanks in advance.

Benjamin Rauch
  • 11
  • 2
  • Replace `webBrowser1.Navigate("about:blank");` with `webBrowser1.Navigate("");` and add the HTML5 header to any content you write to the `HtmlDocument` (e.g., `" The body text"`). -- If your apps go fish from the GAC that ancient version of `mshtml` (v.7, while the current is v.11), you have a problem. First thing to try to change is described here: [How can I get the WebBrowser control to show modern contents?](https://stackoverflow.com/a/38514446/7444103). -- After that, you may need to recreate the TypeLibrary from the current `mshtml.dll`... – Jimi Apr 28 '21 at 14:01
  • @Jimi The registry key turned out to make the difference as the main program in question already had one signed up. However, the GAC reference ultimately comes from `C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\PublicAssemblies\Microsoft.mshtml.dll` which is 7.0.3300 – Benjamin Rauch Apr 29 '21 at 06:54
  • The *real* `mshtml.dll` and its `mshtml.tlb` are located in `[drive]:\Windows\System32`. To *regenerate* the Library and use it in your app, see here: [Why doesn't MSHTML for .Net have querySelector and querySelectorAll, or where are they?](https://stackoverflow.com/a/21170836/7444103). It's quite important, since that relic you're referencing now is missing a lot of stuff. – Jimi Apr 29 '21 at 12:17
  • If possible, move to WebView2: [Getting started with WebView2 in Windows Forms](https://learn.microsoft.com/en-us/microsoft-edge/webview2/gettingstarted/winforms) -- [Microsoft Edge WebView2 Run-Time](https://developer.microsoft.com/en-us/microsoft-edge/webview2/) – Jimi Apr 29 '21 at 13:01

1 Answers1

0

The difference in behavior stems from the registry entry as proposed by Jimi and linked here

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION

To reiterate, in the above registry the main program had an entry "ApplicationFileName.exe"=dword:00002af9 while my new test-application didn't.

This, in and for itself, does not explain the crashing of mshtml.dll itself but since the question was about the difference in behavior I'll post this as the answer. The crash is most likely linked to the outdated version used by Visual Studio but I haven't yet had the chance to look into some of the proposed fixes for that.

Benjamin Rauch
  • 11
  • 2