i've narrowed it down to discord web client being opened. still, weird.

it could be related to the discord update though, not chrome update, altough i'm not sure. it's one or the other.

i noticed the bug with discord too, it seems to happen every time chrome creates a "video capture service" process (it's closed and recreated over and over)

suspending the process using something like process explorer works to stop it but it might break video chat

correct, that process gets recreated over and over again. i don't feel like messing with it though. any other workarounds?

i've checked discord with camera set to default (ask), allowed and blocked, no difference. with allowed, it displays the name of the device, but test video doesn't work - not sure if it's supposed to work in current web version anyway.

is it a bug in chrome, or a sideeffect of crappy camera-related code in discord?

Able to reproduce the issue on Win-10 using the chrome reported version #64.0.3282.24 and latest stable #63.0.3239.108.
But it is not consistently reproducing after ~10 seconds. So, unable to dig to find the good and bad build range.

Hence, marking it as untriaged for further inputs from dev team and removing Needs-Bisect label as it is inconsistently reproducing from TE-end. Please feel free to add the same if required.

Thanks...!!

I have the same issue whenever Google Hangouts is active, either within Gmail or in its own tab.  Video Capture Service restarts every few seconds, changing the mouse cursor.  Just started in Chrome 64.  Win7 x64.

Also happening in GoToMeeting.

Happening to me as well with Hangouts app and Hangouts extension (Chrome 64.0.3282.119, cohort: 64_119_win). Also when I turn on chat in Gmail. After opening Hangouts app the cursor turns "active" ebout every 5-10 seconds for a split second. It stops happening if I disable Hangouts app from chrome://extensions, not when I close the app (it is then still active in the task manager). When the cursor turns active, "Video Capture Service" is created in task manager, then disappears then gets recreated over and over again.

This is really easy to reproduce on-demand: open a new Chrome window, open the dev console, and type:

navigator.mediaDevices.enumerateDevices()

Your cursor will change from IDC_ARROW to IDC_APPSTARTING. (https://msdn.microsoft.com/en-us/library/windows/desktop/ms648391(v=vs.85).aspx) In the background, a new Chrome process is created.

It seems like Hangouts in Gmail calls this function (or something morally equivalent) often, but the `video_capture` utility process doesn't stick around and new ones have to be created.

The call to `navigator.mediaDevices.enumerateDevices()` winds its way through the message loop
to `MediaDevicesDispatcherHost::EnumerateDevices` (https://cs.chromium.org/chromium/src/content/browser/renderer_host/media/media_devices_dispatcher_host.cc?l=121&rcl=b3553f3159d48c53f29795edad1dade49724098a),
to `ServiceVideoCaptureProvider::LazyConnectToService` (https://cs.chromium.org/chromium/src/content/browser/renderer_host/media/service_video_capture_provider.cc?l=107&rcl=b3553f3159d48c53f29795edad1dade49724098a),
to `ServiceManager::CreateServiceWithFactory` (https://cs.chromium.org/chromium/src/services/service_manager/service_manager.cc?l=1219&rcl=b3553f3159d48c53f29795edad1dade49724098a),
to `StartServiceInUtilityProcess` (https://cs.chromium.org/chromium/src/content/browser/service_manager/service_manager_context.cc?l=112&rcl=b3553f3159d48c53f29795edad1dade49724098a),
to `ChildProcessLauncherHelper::StartLaunchOnClientThread` (https://cs.chromium.org/chromium/src/content/browser/child_process_launcher_helper.cc?l=76&rcl=b3553f3159d48c53f29795edad1dade49724098a),
and finally to `SandboxWin::StartSandboxedProcess` (https://cs.chromium.org/chromium/src/services/service_manager/sandbox/win/sandbox_win.cc?l=704&rcl=b3553f3159d48c53f29795edad1dade49724098a),
which finally calls `base::LaunchProcess` here (https://cs.chromium.org/chromium/src/services/service_manager/sandbox/win/sandbox_win.cc?l=727&rcl=b3553f3159d48c53f29795edad1dade49724098a) and gets us to this call (https://cs.chromium.org/chromium/src/base/process/launch_win.cc?l=300&rcl=b3553f3159d48c53f29795edad1dade49724098a) to CreateProcess.

That call to CreateProcess should probably specify STARTF_FORCEOFFFEEDBACK in its STARTUPINFO (https://msdn.microsoft.com/en-us/library/windows/desktop/ms686331(v=vs.85).aspx). From MSDN:
> If a GUI process is being started and neither STARTF_FORCEONFEEDBACK or STARTF_FORCEOFFFEEDBACK is specified, the process feedback cursor is used. A GUI process is one whose subsystem is specified as "windows."

In sum, there are a few problems here. All should be fixed:
1. Hangouts is enumerating devices once every few seconds.
2. Chrome often spawns an *entirely new process* (not a cheap operation on Windows) for a call to `navigator.mediaDevices.enumerateDevices()`.
3. When Chrome launches new processes, it keeps the Windows default behavior of changing the cursor to "waiting" (IDC_APPSTARTING) until the new process starts its message loop.

The third part of this bug - the busy cursor - is probably a duplicate of bug 798013.

I've had this bug since the last automatic stable update as well and it's really annoying, is there at least a temporary fix for discord other than forcibly suspending the process and if not, any estimate when it might be fixed since mattdr seemed to have more or less solved what causes it in full?

We are experiencing the same problem on a grander scale.  We use Chrome Enterprise and G Apps on a terminal server.  We have 50+ users all logged with google chrome and gmail left open most of the day.  Because of this bug, an instance of chrome.exe will continue to open and close for each session while they are logged into gmail because hangouts automatically opens.  Each time this happens, it takes 1-2% of the server CPU.  Multiple that by 50 and this bug alone hangs our server due to high CPU usage.  We have had to disable hangouts in g admin for our company until this issue is resolved since there is no group policy to disable hangouts.  I'm glad we came across this forum as this has been a major issue the past couple of days. 

Version 65.0.3325.146 seems to have finally fixed this bug for discord.