Unable to reproduce this issue on Windows-10 using chrome latest stable M55-55.0.2883.87 by following steps mentioned in the original comment. Observed no crashes on clicking cookies for the site.

eric@ Could you please recheck this issue by installing the same on latest chrome canary version from the below link, If issue still persists please check for any crash Id's from chrome://crashes and reply to this comment if available.

https://www.chromium.org/getting-involved/dev-channel

Thanks! 

Crash still occurs with 58.0.2991.0 canary (64-bit).

At this point, it's definitely something that is machine wide and persistent. The steps to reproduce require some sort of setup before the crash is triggered.

Is there something else that I should do that could help pin point the issue?

Sorry, as well, there were no crash ids to copy, just .dmp files. Do you want me to continue to attach them?

Thank you for providing more feedback. Adding requester "brajkumar@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

Cleaning up "Needs-Review" label as we are not using this label for triage. Ref  bug 684919 

eric.boyer@ Could you please confirm are you still seeing this issue on chrome latest stable #58.0.3029.110?

Yes it still exists.

Confirmed in:
58.0.3029.96 (64-bit)
60.0.3097.0 (Official Build) canary (64-bit)

Thank you for providing more feedback. Adding requester "brajkumar@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

Tested the issue on windows 7 using chrome M58 #58.0.3029.110 and issue is not reproduced.

Attached screencast for reference.

@eric.boyer-- Could you please check in latest stable with fresh chrome profile without extensions and flags enabled and provide us the screencast fo the issue , if you can still reproduce the issue.

Thanks!

Deleted: 678602.mp4 930 KB

	678602.mp4 930 KB View Download

Here's another screen cast of it crashing in Chrome Canary v60 when clicking on the lock icon. There is no profile, no extensions, and no flags enabled.

It no longer crashes on the settings tab as the page has been redesigned and likely doesn't call the offending code anymore.

Deleted: Screen 05-17-2017 09-30-06.avi 1.8 MB

Screen 05-17-2017 09-30-06.avi 1.8 MB Download

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

We are still unable to reproduce the issue on windows 7 using chrome stable M58 #58.0.329.110 and chrome canary M60 #60.0.3013.0 .

@eric.boyer-- Could you please provide us the crash id along with the server id  from chrome://crashes , that would help us in traiging the issue better.

Thanks!

As I've explained in previous messages. Nothing shows up on this page.

Deleted: ChromeCrashes.png 17.6 KB

	ChromeCrashes.png 17.6 KB View Download

Also, 'Automatically send usage statistics and crash reports to Google' is enabled. 

Deleted: Stats.png 77.7 KB

	Stats.png 77.7 KB View Download

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

We are unable to reproduce the issue from TE end. Could some one from Browser dev team please look in to this issue.

Thanks in Advance!

@eric.boyer : Can you please try to clean the chrome using cleanup tool https://www.google.com/chrome/cleanup-tool/
and check the issue on latest chrome new profile if the issue still persists please update the thread.

Thanks,

No programs found.
Can't reset settings as the settings tab crashes.

Deleted: CleanUpTool.png 7.1 KB

	CleanUpTool.png 7.1 KB View Download

Thank you for providing more feedback. Adding requester "kavvaru@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

Attaching Visual Studio to Chrome Canary, and loading symbols from 
https://chromium-browser-symsrv.commondatastorage.googleapis.com

(following: https://www.chromium.org/developers/how-tos/debugging-on-windows#TOC-Debugging-with-WinDBG)

Results in the following stack trace when the error is triggered:
 	kernel32.dll!0000000076c9bb21()	Unknown
>	chrome.dll!__raise_securityfailure(_EXCEPTION_POINTERS * const exception_pointers=0x000007feaf3690e8) Line 142	C
 	chrome.dll!__report_gsfailure(unsigned __int64 stack_cookie=277281488) Line 278	C
 	chrome.dll!init_device(libusb_device * dev=0x000000000e991f90, libusb_device * parent_dev=0x0000000000000000, unsigned char port_number='\x2', char * device_id=0x000000000e991370, unsigned long devinst=4168) Line 1191	C
 	chrome.dll!windows_get_device_list(libusb_context * ctx=0x000000000e3400b0, discovered_devs * * _discdevs=0x0000000010c6f6d0) Line 1633	C
 	chrome.dll!libusb_get_device_list(libusb_context * ctx=0x000000000e3400b0, libusb_device * * * list=0x0000000010c6f6f8) Line 683	C
 	chrome.dll!device::`anonymous namespace'::GetDeviceListOnBlockingThread(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & new_device_path, scoped_refptr<device::UsbContext> usb_context={...}, scoped_refptr<base::SequencedTaskRunner> task_runner={...}, const base::Callback<void __cdecl(libusb_device * *,unsigned __int64),1,1> & callback={...}) Line 122	C++
 	chrome.dll!base::internal::Invoker<base::internal::BindState<void (__cdecl*)(std::basic_string<char,std::char_traits<char>,std::allocator<char> > const & __ptr64,scoped_refptr<device::UsbContext>,scoped_refptr<base::SequencedTaskRunner>,base::Callback<void __cdecl(libusb_device * __ptr64 * __ptr64,unsigned __int64),1,1> const & __ptr64),std::basic_string<char,std::char_traits<char>,std::allocator<char> >,scoped_refptr<device::UsbContext>,scoped_refptr<base::SingleThreadTaskRunner>,base::Callback<void __cdecl(libusb_device * __ptr64 * __ptr64,unsigned __int64),1,1> >,void __cdecl(void)>::Run(base::internal::BindStateBase * base) Line 343	C++
 	chrome.dll!base::debug::TaskAnnotator::RunTask(const char * queue_function=0x000007feaf494340, base::PendingTask * pending_task=0x000000000e2861b0) Line 59	C++
 	chrome.dll!base::internal::TaskTracker::PerformRunTask(std::unique_ptr<base::internal::Task,std::default_delete<base::internal::Task> > task={...}, const base::SequenceToken & sequence_token={...}) Line 327	C++
 	chrome.dll!base::internal::TaskTracker::RunTask(std::unique_ptr<base::internal::Task,std::default_delete<base::internal::Task> > task={...}, const base::SequenceToken & sequence_token={...}) Line 250	C++
 	chrome.dll!base::internal::SchedulerWorker::Thread::ThreadMain() Line 79	C++
 	chrome.dll!base::`anonymous namespace'::ThreadFunc(void * params=0x000000000defd3d0) Line 91	C++
 	kernel32.dll!0000000076c159cd()	Unknown
 	ntdll.dll!0000000076e4a561()	Unknown

I don't know if you are going to believe me or not, but I tracked it down to the mouse I was using. If I swap it for another one, the bug no longer presents. Looks like when chrome is trying to read the devices it can't initialize this one correctly. 

I took a look at the code but wasn't able to track down what is causing the corruption and throwing the security error.

As per C#23, adding component and cc'ing reillyg@ for help in further triaging of this.

Looks like a libusb bug. It isn't clear to me yet what is crashing (line 1191 is the end of the init_device function). I'm working on a project to remove libusb entirely but we can also mitigate this issue by avoiding initializing UsbServiceImpl when populating settings and no USB settings are saved yet.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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

This issue will be resolved when we replace libusb with our own native backend on Windows.