[Problem/Bug]: empty Crashpad reports directory when crashing

[pushkin-]

What happened?

My understanding is that crash reporting is enabled by default.

If I start my app, open Task Manager and kill the browser process (--embedded-browser-webview) or the renderer process (--type=renderer), the ProcessFailed event is raised, but I don't see any reports getting created.

IsCustomCrashReportingEnabled is set to false (though I don't think that matters for your purposes) and FailureReportFolderPath is set to %localappdata%\\<appName>\\EBWebView\\Crashpad\\reports

However, the reports directory is empty.
The only modified file after the crash is settings.dat.

Seems related to this issue (maybe that's answered and I'm just not understanding the resolution)

--
though I see this in Edge too assuming I'm following the steps correctly. Maybe it's expected that we don't create dumps in these cases?

Importance

Moderate. My app's user experience is affected, but still usable.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

121.0.2277.128

SDK Version

1.0.2277.86

Framework

Winforms

Operating System

Windows 10

OS Version

10.0.19045 Build 19045

Repro steps

see above

Repros in Edge Browser

Yes

Regression

Don't know

Last working version (if regression)

No response

[LiangTheDev]

If you simply kill the process, it is an unexpected process failure, but not a crash. A crash report would not be created for this case. This is by design. If a real crash happened, dump files should be generated.

[pushkin-]

@LiangTheDev thanks - is there a way to mimic a webview2 process crash then? One that would generate a dump file?

[pushkin-]

I'm seeing a browser process crash (#4843) that generates crash dumps on one machine but not on another. Not sure if there's some other OS-level setting, say, that controls this. Not clear why we see this discrepancy.

[LiangTheDev]

If the OS setting doesn't allow collecting of "optional diagnostic data", then Edge code would not collect dump. The setting could be accessed from Settings app, "Privacy & security -> Diagnostics & feedback".
For intentionally crashing WebView, this might be helpful: https://stackoverflow.com/questions/40367087/how-to-crash-chrome-browser.

[pushkin-]

@LiangTheDev thanks, my "send optional diagnostics" was on, but after turning it off and back on, now crash dumps generate.

As for the SO post, opening those types of sites gives me:

[LiangTheDev]

You could have navigate to edge:// urls from DevTools opened for http/https pages. That's the browser security.
You would have to use WebView2 API to navigate the WebView2 to edge:// ulrs. If using the sample app, this means entering the url in its "address bar" and then trigger the navigation.

[dahaged]

I'm also running into this issue (dumps are generating on one machine but not another). I've tried toggling the "optional diagnostic data" and it didn't fix the issue.
@LiangTheDev, do you know of any other settings that would affect this?

WebView2 Runtime Version: 131.0.2903.112
OS: Windows 11 Enterprise 23H2 build 22631.4602

[Manish3177]

@LiangTheDev, following up on this again. We are trying to preemptively ensure that if/when our application hard-crashes, we get a crash dump but with recent WebView2 updates, no matter what environmentOptions.IsCustomCrashReportingEnabled is set to, there is nothing in the environment.FailureReportFolderPath or C:\ProgramData\Microsoft\Windows\WER\ReportArchive location. Here's the code I'm using to intentionally crash the application. It should count as a real crash. Right?

public void Crash(string message)
{
	// Directly throwing an exception doesn't work => The calling code evidently has a try..catch around it
	// that will take the exception and reject the returned promise with an Error corresponding to that exception.
	// Task.Run(() => { throw ... }) doesn't work either as that just results in a failed task whose
	// result no one checks.
	Thread thread = new Thread((object? message) => { throw new Exception((string)message!); });
	thread.Start(message);
}

This is a method on a "hostObject" and I'm invoking it via the console.

[LiangTheDev]

@Manish3177 there seems to be a misunderstanding here. The WebView2's crash dumps (the ones that are supposed to be in environment.FailureReportFolderPath folder) are for crashes happened in WebView2's processes (msedgewebview2.exe).

The crashes that happen in app process is not handled by WebView2 Runtime, but handled by Windows' error handling. I would expect that you can see events related to the crash in app process if you use event viewer to check WER events.

[Manish3177]

Thanks for the clarification, @LiangTheDev. I can confirm that I do get a .dmp file in the environment.FailureReportFolderPath location with webView.CoreWebView2.Navigate("edge://inducebrowsercrashforrealz"); as long as I'm not running from Visual Studio / with debugger attached.