Api process failed crash correlation#5586
Conversation
Adds CrashReport.md spec for the new ICoreWebView2StagingCrashReport API that correlates WebView2 process failures with Watson crash reports. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
- Fix title from interface name to human-friendly 'Crash Report' - Fix COM IDL code block language tag (cpp -> no tag) - Fix WinRT/NET section headings to 'WinRT and .NET' - Add __fastfail note: fields from WER event log, BucketId empty - Add OOM exception code 0xe0000008 to ExceptionCode doc - Soften CrashReportId dump filename claim - Clean up BucketId doc (remove WER internal field names) - Fix IsCustomCrashReportingEnabled: remove 'network hit' impl detail Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
| [uuid(7c3a1b40-9f1e-4a5d-8b2e-2e0e7c1f3a55), object, pointer_default(unique)] | ||
| interface ICoreWebView2CrashReport : IUnknown { | ||
| /// A stable identifier for this crash report. Use this to locate the | ||
| /// corresponding dump file in `FailureReportFolderPath`. |
There was a problem hiding this comment.
Is this only to find the dump file? If so, should we instead provide the path to the dump file?
There was a problem hiding this comment.
@david-risney,
No, it also covers crashes that are not handled by the Crashpad handler, such as heap corruption (exception code: 0xC0000409). In these cases, no dump is generated or stored under UDF\Crashpad\Reports. Instead, we obtain the report ID by scanning the WER 1000 event.
The report ID is mainly useful for correlating a later event that arrives asynchronously via WER event 1001, which contains the bucket ID.
We are also looking to add support for this second event in the current WIP Diagnostic Monitor API.
There was a problem hiding this comment.
I have to update the spec file accordingly.
| /// STATUS_ACCESS_VIOLATION, 0xC0000409 for STATUS_STACK_BUFFER_OVERRUN | ||
| /// (fast-fail), or 0xe0000008 for an out-of-memory termination. | ||
| // MSOWNERS: core (wvcore@microsoft.com) | ||
| [propget] HRESULT ExceptionCode([out, retval] UINT32* value); |
There was a problem hiding this comment.
Is all of this data from the dump file? Should we just provide the dump file and its up to the host app to do what it likes with it?
There was a problem hiding this comment.
No, all of the data is obtained from the watson_metadata file in UDF\Crashpad, which is maintained by the Crashpad handler, as well as from the WER 1000 event (in the case of __fastfail).
However, all the fields exposed via this API, except the bucket ID, are also available in the dump.
But __fastfail crashes do not generate a dump, and thus host apps will not be able to obtain this data.
| /// Basename of the module containing the faulting instruction, | ||
| /// e.g. "v8.dll". Never a full path. | ||
| // MSOWNERS: core (wvcore@microsoft.com) | ||
| [propget] HRESULT FaultingModuleName([out, retval] LPWSTR* value); |
There was a problem hiding this comment.
Is this different from CoreWebView2ProcessFailedEventArgs.FailureSourceModulePath (other than the new one is just the filename)? If not, we perhaps don't need this?
There was a problem hiding this comment.
CoreWebView2ProcessFailedEventArgs.FailureSourceModulePath is populated only in cases of code integrity failures. That is a different category compared to our crashes.
|
|
||
| /// Version of the faulting module, e.g. "128.0.2739.42". | ||
| // MSOWNERS: core (wvcore@microsoft.com) | ||
| [propget] HRESULT FaultingModuleVersion([out, retval] LPWSTR* value); |
There was a problem hiding this comment.
If this is the file version of the CoreWebView2ProcessFailedEventArgs.FailureSourceModulePath, then maybe we can use the same name format: FailureSourceModuleVersion
2 participants
No description provided.