Xamarin - Setting WebView's crashes app after setting source random times

Cpt Data Crunch 1 Reputation point

I am developing a Xamarin app that has a View with a WebView control added to the XAML. A WebView is being used to load dynamically generated HTML (based on various criteria from a database and C#). A HtmlWebViewSource is used to set the source from C#.

An unusual exception (details below) comes up when the WebView's source is updated multiple times (not always the same number of times). This exception can be thrown, even if the same content is reused in a new HtmlWebViewSource - which I know because I performed such a test to rule out some potential causes such as bad code in the HTML.

I tried debugging this exception with different debugger types. For clarity, debugger types are found by righ clicking on the project, selecting properties, and then navigating to Debugging.

With the debugger set to "Managed", the application somes closes without any notification or message. On other occasions it produces an error prompt which states that "A debugger is attached... but is not configured to debug this unhandled exception." In either case, I have seen in the console panel the following message: "The program ... has exited with code 1073741855".

With the debugger type set to "managed and native", I received this additional info:
{My App Path}\bin\x86\Debug\AppX\wkernelbase.pdb: Cannot find or open the PDB file.
C:\Windows\SysWOW64\wkernelbase.pdb: Cannot find or open the PDB file.
C:\Windows\wkernelbase.pdb: Cannot find or open the PDB file.
C:\Windows\symbols\dll\wkernelbase.pdb: Cannot find or open the PDB file.
C:\Windows\dll\wkernelbase.pdb: Cannot find or open the PDB file.

If set the debugger type set to "Script", the error disappeared. This is not a solution, however, as it would be great to still have a debugger attached to managed code without having to continually adjust the debugger type.

Some ideas that I have tried:
* Use javasacript to reload the current page. This strategy was to prove that it is not a navigation problem. The result was no error.
* Reload the same content with C# using a new instance of HtmlWebViewSource with the same HTML. This strategy was to rule out a problem in the HTML. The exception was usually thrown after a few reloads.
* Load the HTML into a browser. This strategy was to test for problems in the HTML in another environment. There was no problem detected.
* In C#, I created an exception handler attached to these events: AppDomain.CurrentDomain.UnhandledException, AppDomain.CurrentDomain.FirstChanceException, TaskScheduler.UnobservedTaskException. The exception is not caught by any of these events.

A Microsoft open-source app platform for building Android and iOS apps with .NET and C#.
5,301 questions
{count} votes