connecting a usb microphone to the pc prevents the extension from crushing but no audio is recorded (not from the entire screen and not from a specific tab such as youtube).

attaching dxdiag just in case.

Deleted: DxDiag.txt 67.6 KB

DxDiag.txt 67.6 KB View Download

this also occurs on canary.

Tested the issue on windows 10 using latest chrome stable M59 #59.0.3071.104 using the below steps:

1. Launched chrome and opened a sample extension and opened console of it.
2. Copied the given code in console and resulted in error.

Attached screencast for reference.

@roeycohen-- Could you please provide us the sample extension and also help us in providing the screencast of the steps to reproduce the issue for better understanding.

Thanks!

Deleted: 733356.mp4 1.2 MB

	733356.mp4 1.2 MB View Download

hi, i'll create one.
you probably need to add desktopCapture to the permissions node in the manifest.json file in order to have the chrome.desktopCapture object available.

Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

attached a sample extension and also a video demonstrating how it crashes.

please make sure, that the navigator.mediaDevices.enumerateDevices doesn't return any input devices (detach all microphones, web camera and etc).

Deleted: test_ext.zip 38.5 KB

test_ext.zip 38.5 KB Download

Deleted: 20 Jun 2017 09-48-39.webm 344 KB

	20 Jun 2017 09-48-39.webm 344 KB View Download

Able to reproduce the issue using latest stable #59.0.3071.104 on Win10.

Below is the manual bisect info

Good build: 59.0.3068.1 (Revision: 463474)
Bad build: 59.0.3069.0 (Revision: 463921)

Manual CHANGELOG:

https://chromium.googlesource.com/chromium/src/+log/59.0.3068.0..59.0.3069.0?pretty=fuller&n=10000

Unable to do tool bisect as getting error while invoking the builds.

Unable to find the suspect from manual change log . Hence untriaged the issue so that it get's addressed.

Note:
1. Issue is specific to Windows and not seen in Mac and Linux
2. Adding RBS as it's broken in M59, undo if not the case.
3. Issue is seen in Windows M61 as well.

Stack trace
==========

Thread 0 (id: 129304) CRASHED [Simulated Exception @ 0x00007ffd2cc1c797 ] MAGIC SIGNATURE THREAD
Stack Quality100%Show frame trust levels
0x00007ffd2cc1c797	(chrome_elf.dll -crashpad_win.cc:168 )	DumpProcessWithoutCrash
0x00007ffd10832418	(chrome.dll -render_process_host_impl.cc:1856 )	content::RenderProcessHostImpl::ShutdownForBadMessage(content::RenderProcessHost::CrashReportMode)
0x00007ffd1083424b	(chrome.dll -render_process_host_impl.cc:2549 )	content::RenderProcessHostImpl::OnBadMessageReceived(IPC::Message const &)
0x00007ffd110a0eaa	(chrome.dll -ipc_channel_proxy.cc:363 )	IPC::ChannelProxy::Context::OnDispatchBadMessage(IPC::Message const &)
0x00007ffd10d37f3f	(chrome.dll -task_annotator.cc:59 )	base::debug::TaskAnnotator::RunTask(char const *,base::PendingTask *)
0x00007ffd10ce7e25	(chrome.dll -message_loop.cc:422 )	base::MessageLoop::RunTask(base::PendingTask *)
0x00007ffd10ce8031	(chrome.dll -message_loop.cc:433 )	base::MessageLoop::DeferOrRunPendingTask(base::PendingTask)
0x00007ffd10ce8917	(chrome.dll -message_loop.cc:540 )	base::MessageLoop::DoWork()
0x00007ffd10d384c0	(chrome.dll -message_pump_win.cc:173 )	base::MessagePumpForUI::DoRunLoop()
0x00007ffd10d38133	(chrome.dll -message_pump_win.cc:56 )	base::MessagePumpWin::Run(base::MessagePump::Delegate *)
0x00007ffd10d0f093	(chrome.dll -run_loop.cc:111 )	base::RunLoop::Run()
0x00007ffd10c1267f	(chrome.dll -chrome_browser_main.cc:1950 )	ChromeBrowserMainParts::MainMessageLoopRun(int *)
0x00007ffd106112f7	(chrome.dll -browser_main_runner.cc:142 )	content::BrowserMainRunnerImpl::Run()
0x00007ffd1060a24c	(chrome.dll -browser_main.cc:46 )	content::BrowserMain(content::MainFunctionParams const &)
0x00007ffd10b669df	(chrome.dll -content_main_runner.cc:704 )	content::ContentMainRunnerImpl::Run()
0x00007ffd10b816fa	(chrome.dll -main.cc:469 )	service_manager::Main(service_manager::MainParams const &)
0x00007ffd10b661bb	(chrome.dll -content_main.cc:19 )	content::ContentMain(content::ContentMainParams const &)
0x00007ffd102bd3a7	(chrome.dll -chrome_main.cc:119 )	ChromeMain
0x00007ff74ece75e3	(chrome.exe -main_dll_loader_win.cc:199 )	MainDllLoader::Launch(HINSTANCE__ *,base::TimeTicks)
0x00007ff74ece2628	(chrome.exe -chrome_exe_main_win.cc:268 )	wWinMain
0x00007ff74edae422	(chrome.exe -exe_common.inl:253 )	__scrt_common_main_seh
0x00007ffd4c1f8101	(KERNEL32.DLL + 0x00018101 )	BaseThreadInitThunk
0x00007ffd4c34c5b3	(ntdll.dll + 0x0005c5b3 )	RtlUserThreadStart

I'll take a look at this, since it seems related to the new constraints algorithm.

cc owners of desktopCapture API

I don't think this is directly caused by the new constraints algorithm in M59 (which is for video only). However, enabling it might have triggered a latent bug.

Also, according to pbommana@, it also crashes when the old constraints algorithm is enabled via command line with --enable-features=MediaStreamOldVideoConstraints


Crash ID for reference: 7183d41e40000000

It looks like a bad IPC message is sent on Windows 10 when these particular options are chosen and there are no audio devices.

niklase@: Can someone on your team take a look?

I run the bisect script and got a narrow range: https://chromium.googlesource.com/chromium/src/+log/851599815cb52219eab8cf90a7a0571a683a6686..ee6794b5b8e7c06965106741ada8d94beedf98cc

I assume olka@'s CL is the cause.

(Now from the correct account)
Thanks for bisecting! Looking into it now.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d9a4e3e3f860fb848ce36deea29f0d685c6d81c6

commit d9a4e3e3f860fb848ce36deea29f0d685c6d81c6
Author: olka <olka@chromium.org>
Date: Thu Jun 22 12:42:36 2017

Making AudioInputDeviceManager to return UnavailableDeviceParameters when there are no physical input devices.

BUG= 733356 

Review-Url: https://codereview.chromium.org/2948233002
Cr-Commit-Position: refs/heads/master@{#481510}

[modify] https://crrev.com/d9a4e3e3f860fb848ce36deea29f0d685c6d81c6/content/browser/renderer_host/media/audio_input_device_manager.cc

#28 should hopefully fix it.
I don't have a Windows system to tests it - could somebody try it and let me know if it works?

Thanks for the fix. I'll patch your CL on my machine to see whether it resolves the issue or not.

Yes, I've verified that the fix works.

Now without audio device, the getUserMedia will call the error callback.

But why does that happen in this case? Recording system audio should still be possible.

Re #32: It is not possible for my case, because I disable the whole audio device (the parent device of all microphones and speakers).

Re #32: Further the behavior is consistent with the stable version. Possibly we should make the audio checkbox gone in this case, which worth another bug.

Update:

I found we can actually do system audio capture when all microphones are off. (But the root audio device should be on)

And [1] is a bug, as it just checks the non-existence of microphone, and returns an invalid AudioParameters. But for "loopback" audio capture, the existence of microphone does not matter at all.

I'll check tomorrow whether a speaker is necessary for audio capture to work properly.

[1] https://cs.chromium.org/chromium/src/media/audio/audio_system_impl.cc?l=166

Update: 

I do found that 
1. Without microphone, the system audio capture is valid;
2. Without speaker, the system audio capture is broken;

So my suggestion for [1], it should check the existence of output device when the device_id is "loopback" or "loopbackWithMute". 

[1] https://cs.chromium.org/chromium/src/media/audio/audio_system_impl.cc?l=166

qiangchen@
Could you clarify what does "Without speaker, the system audio capture is broken" actually mean? Does the extension crash? Or getUserMedia() calls an error callback? If latter, then what is an error code?

Could you file a separate bug for it, describing the expected behavior and if it worked before? And could you attach media logs there?

"So my suggestion for [1], it should check the existence of output device when the device_id is "loopback" or "loopbackWithMute"". 
- What is the point of checking the existence of output devices in the function which returns input device parameters?

Please note that that (1) audio input device check [1] you refer to is not related to output devices; (2) #28 makes sure that UnavailableDeviceParameters are returned in case there are no valid input devices found in the system, see [2]; (3) invalid input device parameters are used as an indicator of "no input devices" by other clients of audio system.

[1] https://cs.chromium.org/chromium/src/media/audio/audio_system_impl.cc?l=166
[2] https://cs.chromium.org/chromium/src/content/browser/renderer_host/media/audio_input_device_manager.cc?l=171

Marking as fixed per #31 

[Auto-generated comment by a script] We noticed that this issue is targeted for M-59; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-59 label, otherwise remove Merge-TBD label. Thanks.

I guess it should be merged to M60, but do we need to merge it to M59 as well?

This bug requires manual review: M60 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Re #37:
The error callback will be called.

One weird thing is that even if at [2], it sets the UnavailableDeviceParams, the audio capture can be carried out. For example, you disable all the microphones, with [1] you can tell that at [2] it will set UnavailableDeviceParams.

Another case is that at [2], it sets a valid params, but the audio capture will still error out (not crash, but the err callback is triggered). For example, you disable all the speakers. At [1], it will not return an empty AudioParameters(), so at [2], it will take the input parameters as valid.

For [1], when the device id is "loopback" or "loopbackWithMute", there is no need to check the existence of audio input device (namely microphones), but instead the existence of a speaker is necessary.

Because when we do system audio capture (capture the audio stream which is being played out by the speaker), our AudioInputStream actually corresponds to an output device (namely speaker).

[1] https://cs.chromium.org/chromium/src/media/audio/audio_system_impl.cc?l=166
[2] https://cs.chromium.org/chromium/src/content/browser/renderer_host/media/audio_input_device_manager.cc?l=171

Re #43: Could you file a bug and we'll continue discussion there? (see #37)

What I do not quite understand is why loopback asks for input HW parameters if it does not care about them?

Tested this issue on Windows 7 using chrome dev#61.0.3141.0 as per comment#14 ( zip file & video).

No crash observed when we add & run 'Desktop capture crash test' extension on chrome browser.

Please find the attached screencast for reference.As it is working as intended,adding TE Verified labels.

Thank you..!!

Deleted: 733356.mp4 866 KB

	733356.mp4 866 KB View Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9a6670cc4f73e0d88bfc09ef615d25b4db54f0b9

commit 9a6670cc4f73e0d88bfc09ef615d25b4db54f0b9
Author: Henrik Grunell <grunell@chromium.org>
Date: Fri Jun 30 10:31:39 2017

Making AudioInputDeviceManager to return UnavailableDeviceParameters when there are no physical input devices.

BUG= 733356 

Review-Url: https://codereview.chromium.org/2948233002
Cr-Original-Commit-Position: refs/heads/master@{#481510}
Review-Url: https://codereview.chromium.org/2968673002 .
Cr-Commit-Position: refs/branch-heads/3112@{#500}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}

[modify] https://crrev.com/9a6670cc4f73e0d88bfc09ef615d25b4db54f0b9/content/browser/renderer_host/media/audio_input_device_manager.cc

Tested the issue on Windows-7 using chrome latest Beta M60-60.0.3112.66 by following steps mentioned in the original comment. Observed that no crash is happening and working as expected. Hence adding TE-Verified label.

Please find the screen cast for reference.

Thank you!

Deleted: 733356.mp4 1.5 MB

	733356.mp4 1.5 MB View Download

Issue 738032 has been merged into this issue.