API Review: ProcessId for ProcessFailedEventArgs #5401
Conversation
Add ProcessId property to CoreWebView2ProcessFailedEventArgs4 This API extends ProcessFailedEventArgs to include the process ID of the failed process, enabling applications to: - Correlate process failures with running process data from the ProcessInfo API - Collect process-specific diagnostic information for logging and telemetry - Analyze crash dumps for specific processes - Better track and respond to failures in multi-renderer scenarios The process ID is only available if the process has started and ended unexpectedly. For other failure types, the process ID value will be 0.
There was a problem hiding this comment.
Pull Request Overview
This PR adds a ProcessId property to CoreWebView2ProcessFailedEventArgs to expose the process ID of failed WebView2 processes. This enhancement enables applications to correlate process failures with runtime process information, collect process-specific diagnostics, and better handle failures in multi-renderer scenarios.
Key Changes:
- Added
ICoreWebView2ProcessFailedEventArgs4interface withProcessIdproperty - The process ID returns 0 for failure types where the process never started successfully
- Provides correlation capability with existing ProcessInfo API
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
There was a problem hiding this comment.
Pull Request Overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 6 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| /// analyze crash dumps for that process. The process ID should be | ||
| /// available in all failure kinds e.g. when GPU process hangs, | ||
| /// browser process exits, utility process exits or renderer process hangs. | ||
| /// If the main frame renderer process is gone externally, the process ID | ||
| /// will be set to 0. |
There was a problem hiding this comment.
Inconsistent documentation: The PR description states "The process ID is only available if the process has started and ended unexpectedly. For other failure types, the process ID value will be 0." However, the API documentation in lines 168-172 states "The process ID should be available in all failure kinds e.g. when GPU process hangs, browser process exits, utility process exits or renderer process hangs." These statements contradict each other regarding when the process ID is available.
There was a problem hiding this comment.
It also says that "it's available in all failure kinds" and then finishes by saying "in the case of main frame renderer failure, there is no process ID."
There was a problem hiding this comment.
If the main frame renderer process is forcibly terminated by the end user or some other process then the failing process ID is set to 0.
With an update to the wordings in the explanation, I hope this confusion will get cleared.
Co-authored-by: Copilot <[email protected]>
|
@microsoft-github-policy-service agree company="Microsoft" |
| //! [ProcessFailed] | ||
| // Register a handler for the ProcessFailed event. | ||
| // This handler checks the failure kind and tries to: | ||
| // * Recreate the webview for browser failure and render unresponsive. |
There was a problem hiding this comment.
| // * Recreate the webview for browser failure and render unresponsive. | |
| // * Recreate the webview for browser failure or an unresponsive renderer. |
There was a problem hiding this comment.
Accepted. @prija-microsoft please fix.
| /// analyze crash dumps for that process. The process ID should be | ||
| /// available in all failure kinds e.g. when GPU process hangs, | ||
| /// browser process exits, utility process exits or renderer process hangs. | ||
| /// If the main frame renderer process is gone externally, the process ID |
There was a problem hiding this comment.
What does "is gone externally" mean?
There was a problem hiding this comment.
This should read "if the main frame renderer process was forcibly terminated extraneously, the process ID will be set to 0".
Terminated extraneously could mean killed using taskkill or taskmanager etc.
@prija-microsoft please update.
| /// analyze crash dumps for that process. The process ID should be | ||
| /// available in all failure kinds e.g. when GPU process hangs, | ||
| /// browser process exits, utility process exits or renderer process hangs. | ||
| /// If the main frame renderer process is gone externally, the process ID | ||
| /// will be set to 0. |
There was a problem hiding this comment.
It also says that "it's available in all failure kinds" and then finishes by saying "in the case of main frame renderer failure, there is no process ID."
| // * Recreate the webview for browser failure and render unresponsive. | ||
| // * Reload the webview for render failure. | ||
| // * Reload the webview for frame-only render failure impacting app | ||
| // content. |
There was a problem hiding this comment.
The sample doesn't do any of these things it promises to do. Okay, it logs the failure, but it doesn't do any of the recreate/reload operations. Should it be
if (reason == COREWEBVIEW2_PROCESS_FAILED_REASON_TERMINATED ||
reason == COREWEBVIEW2_PROCESS_FAILED_REASON_CRASHED) {
ScheduleRecreateWebView2(); // any crash or termination
} else if (reason == COREWEBVIEW2_PROCESS_FAILED_REASON_UNRESPONSIVE &&
kind == COREWEBVIEW_PROCESS_KIND_RENDER) {
ScheduleRecreateWebView2(); // unresponsive renderer
} else if (kind == COREWEBVIEW_PROCESS_KIND_RENDER) {
ScheduleReloadWebView2(); // all other render failures
} else if (kind == cOREWEBVIEW_PROCESS_FRAME_RENDER) {
ScheduleReloadWebView2(); // frame render failure
}I'm sure I got that wrong, How can I detect whether a frame-only render failure impacts app content? Do I look at the URL of the renderer? How do I get that?
}
There was a problem hiding this comment.
Webview2 render process is automatically respawned in the event of failure. The primary intent here is to inform the host app of the render process id.
Correlation of failing render process, frame id and url is supported. However it requires more orchestration. The webview2 provides FrameCreated and Navigation* events for correlating frame id with url.
There was a problem hiding this comment.
If the Webview2 render process automatically respawns on failure, is it still true that the app needs to reload the webview?
My bigger point is that the sample says "Here is what the sample does" and then it doesn't do any of them.
Add ProcessId property to CoreWebView2ProcessFailedEventArgs4
This API extends ProcessFailedEventArgs to include the process ID of the failed process, enabling applications to:
The process ID is only available if the process has started and ended unexpectedly. For other failure types, the process ID value will be 0.