Implement "safe mode" for Chrome Remote Desktop |
||
Issue descriptionInspired by some recent DirectX crash reports, we should provide a fallback mode for running the CRD host if it crashes shortly after starting. The most pressing need for this is the desktop process on Windows, which has been observed to crash when calling into the graphics drivers to determine DirectX support. The basic idea is that we would monitor the desktop process and if it terminates unexpectedly within a few seconds of starting up, we would restart it with a --safe-mode flag, which would disable the DirectX capturer. Note that we do something similar on Linux, where the child processes are restarted up to ten times if they quit within a minute, but as there's no obvious candidate to disable, I don't think it's worth extending safe mode beyond Windows right now.
,
Jun 12 2017
drive-by comment, you could spin up a different process to check for DX compat and use that to determine if it is safe to call the APIs (i.e. network process creates a new process and uses it to determine if a set of APIs are safe to call using IPC). The nice thing about a separate process is that it can load DLLs without loading them into the network processes memory.
,
Jun 12 2017
Just to play devil's advocate, is it worth implementing this if we also have an experiment framework? Taking DirectX as an example, if we ran an experiment and found the crash rate to be unacceptably high, we'd roll it back, and as long as we used a per-session experiment with a low participation, it's unlikely that a single user would be affected more than once during the experiment. On the other hand, if the crash rate was okay and we enabled it permanently, would we consider the UX that this safe mode would provide (namely either a long connect time or a reconnect required, depending on which process is crashing) to be acceptable? This seems like quite a lot of work to provide a barely functional UX to a small number of users.
,
Jun 12 2017
IMO, by-passing some new and experimental features if they were in unexpected state should be enough. But a comprehensive UI looks over-kill to me. Ideally this mode should never been used - just as the emergency exit on the jets. Though we are facing a more complex environment than a jet: we are running our logic on uncontrollable platforms. But we can still get the crash report meanwhile unblock users if it's enabled.
,
Jun 13 2017
A prototype has been built at https://codereview.chromium.org/2936603003/. I would like to know your opinion before sending it out.
,
Jun 13 2017
We feel that this is a bit heavyweight for the problem at hand, which could be more elegantly solved by performing the DirectX check in a different process.
,
Jun 13 2017
We may discuss this tomorrow in the 1:1, checking DirectX in a different process may not be able to work and even more complex. |
||
►
Sign in to add a comment |
||
Comment 1 by zijiehe@chromium.org
, Jun 10 2017