Troubleshooting

This guide describes how to troubleshoot issues while working with DotNetBrowser library.

Application does not terminate

When your application is running, you can notice several browsercore.exe processes in Task Manager. These processes are always the child processes of your application’s process.

DotNetBrowser brings its own Chromium-based engine, and this engine uses these processes to do all the Chromium-related work. The more IEngine and IBrowser instances you create, the more processes will be started. After the IBrowser or IEngine instance is disposed properly, the processes related to that instance will terminate automatically.

If an IBrowser or IEngine were not disposed properly, they will remain in memory and prevent your application from closing. The processes related to these instances will also remain running. These articles explain how to dispose these instances:

If the IEngine is disposed, all the IBrowser instances created by this IEngine will be disposed as well.

Video does not play

Format of the video you are trying to play might not be supported by DotNetBrowser. Check the list of supported video and audio formats.

If one of the supported video formats does not play, submit a ticket on the issue.

Startup failure on Windows

If DotNetBrowser fails to start in your Windows environment, perform the following actions:

  1. Make sure that your environment meets the system requirements for Windows.
  2. Configure your antivirus software to allow DotNetBrowser to run its executable programs.

DotNetBrowser runs Chromium in a separate native process. Sometimes it fails to launch the native process due to the installed antivirus software or due to local security policy. Even though all DotNetBrowser executable files are signed with a valid and trusted signature, some antivirus software may still not allow running programs that are not in their whitelist.

If the actions above do not help, enable logging, reproduce the issue, and submit a ticket with the collected log messages.

Slow startup on Windows

DotNetBrowser startup consists of many actions. If DotNetBrowser runs in the environment for the first time, it extracts Chromium binaries into a predefined directory. If the binaries are compatible with this version of DotNetBrowser, it runs the Chromium Main process and sets up the IPC connection between .NET and the Chromium Main process.

The startup time depends on the environment, the hardware performance, and the installed antivirus software. For example, if you run DotNetBrowser for the first time on Windows 10, 64-bit without antivirus software, i7/16GB RAM/512GB SSD hardware, the startup time is approximately 2-3 seconds. Every next run will take approximately 1 second since Chromium binaries are already extracted, and DotNetBrowser does not extract them again.

If you see that DotNetBrowser startup is really slow in your Windows environment with antivirus software, try disabling the antivirus software. If it does not help, enable logging, reproduce the issue, and submit a ticket with the collected log messages and the details about your hardware.

Unresponsive .NET Application

If your .NET application hangs, and you believe it happens because of DotNetBrowser, enable logging, reproduce the issue, take a process dump when the application hangs, and submit a ticket with the process dump analysis and the log messages.

Creating and analyzing .NET process dump

1. Create .NET process dump

You can create the dump of the .NET process using different tools, including Visual Studio Debugger, ProcDump, DebugDiag, and others.

2. Analyze .NET process dump

You can open and analyze .NET process dumps in Visual Studio. The following articles describe how to do this:

The Threads, Call Stack, and Parallel Stacks views in Visual Studio Debugger can be used to check the state of each thread in the application.

You can also analyze the dump using DebugDiag Analysis. To analyze the dump file:

  1. Click Start > Run, type the path of the DebugDiag Analysis tool, and then click OK.

    By default, the path to the DebugDiag Analysis tool looks like C:\Program Files\DebugDiag\DebugDiag.Analysis.exe.

  2. Click Add Data Files button.
  3. Locate and select the dump file that you want to analyze, and then click Open.
  4. Configure the symbol search path which is the path to .pdb files generated during building your application by clicking the gear button and adding that path to the Symbol search paths to use for Analysis section.
  5. Check CrashHang Analysis, and then click Start Analysis.
  6. Review the report that is displayed in Microsoft Internet Explorer. A copy of this report is also stored in the %UserProfile%/Documents/DebugDiag/Reports folder.

Unexpected Chromium process termination

DotNetBrowser runs Chromium in a separate native process. An error in the Chromium engine can lead to unexpected process termination. The information about the native crash is stored in a crash dump file.

If Chromium process is unexpectedly terminated, and you received the Engine Crashed event, submit a ticket on the issue and share the generated crash dump file using an online file sharing service such as, for example, Dropbox, Google Drive, and others.

Collecting crash dumps

Windows

By default, crash dump file generation is enabled on Windows. In case of an unexpected Chromium process termination, DotNetBrowser generates a crash dump file and stores it in the %localappdata%\DotNetBrowser directory.

To change the default directory, use the EngineOptions.CrashDumpDirectory property. See the code sample below:

EngineOptions.CrashDumpDirectory = "C:\\DotNetBrowser\\crash-dumps";

Unexpected behavior

If DotNetBrowser behaves unexpectedly, try reproducing the same behavior in Google Chrome and see if it persists. Very often the behavior is expected, and this is just how the library works.

If you notice that the same behaviour in Google Chrome, submit a ticket with the details of the issue, the environment in question, and steps to reproduce it.

Go Top