Unable to reproduce this issue on Windows-10 using chrome latest stable #60.0.3112.113. Tested this issue on google drive and able to upload the file using drag and drop action with no crashes.

daniel@ Provided screen cast is not clear to confirm on which site you are seeing this issue, can you please provide any sample test case or test URL to check this issue from Chrome-TE end?

Thanks!

I could not reproduce.

daniel@, please provide a crash ID.

https://www.chromium.org/for-testers/bug-reporting-guidelines/reporting-crash-bug

Thank you for the quick response guys. The on the first video is a page I'm working on so I can not give you access to that unfortunately, but this issue can be reproduced in any input file. I attach two more videos of me, crashing chrome using a generic input on this page https://www.w3schools.com/JSREF/tryit.asp?filename=tryjsref_fileupload_get and also on gmail. I must say that this does not happen 100% of the time. luckily for me on both videos it crashes on the first attempt, but I had to shoot a couple of attempts first because it wasn't crashing. I just follow the same steps until I'm able to crash it.

Thanks in advance

Deleted: capture-4.mp4 337 KB

	capture-4.mp4 337 KB View Download

Deleted: capture-5.mp4 986 KB

	capture-5.mp4 986 KB View Download

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

Also, there is no report from that crash, as you can see in my attached screenshot, the last one I got is from may 12 and I'm not sure it was due to the same behaviour

Deleted: crashes.PNG 22.7 KB

	crashes.PNG 22.7 KB View Download

I reproduced using Chrome 60.0.3112.113 64 bit on Windows 7 Enterprise.
You can request access to the mini-dump here -
https://drive.google.com/file/d/0Bxwga4EKqxwPS1JmZ1MtN3FGZ0E/view?usp=sharing

For me, Chrome just hangs. It does not crash. Perhaps Windows 10 is simply less forgiving.

I guess is good news you could reproduce the error. What are the steps to follow now? And is there anything else I can contribute with in the meantime?

I initially couldn't repro the bug (on Windows 10) until wez@ suggested that I drag a file from the desktop. I also changed to using a zero-length text file but I suspect that the desktop was the vital change. Either way it is easy to reproduce this with Chrome Canary.

I attached a debugger to the browser process and I can see that the CrBrowserMain is waiting here:

>	chrome.dll!base::PlatformThread::Join
 	chrome.dll!base::Thread::~Thread
 	chrome.dll!base::Thread::~Thread
 	chrome.dll!ui::BaseShellDialogImpl::EndRun
 	chrome.dll!`anonymous namespace'::SelectFileDialogImpl::FileNotSelected

The EndRun function is calling "delete run_state.dialog_thread;", and that thread is clearly not exiting.

The thread that the main thread is waiting on is the Chrome_ShellDialogThread (0x47EC) which is stuck in this stack:

 	win32u.dll!_NtUserMsgWaitForMultipleObjectsEx@20()	Unknown
 	user32.dll!RealMsgWaitForMultipleObjectsEx(unsigned long,void * const *,unsigned long,unsigned long,unsigned long)	Unknown
 	user32.dll!_MsgWaitForMultipleObjectsEx@20()	Unknown
 	combase.dll!CCliModalLoop::BlockFn(void * * ahEvent, unsigned long cEvents, unsigned long * lpdwSignaled) Line 2351	C++
 	combase.dll!ModalLoop(CSyncClientCall * pClientCall) Line 171	C++
 	combase.dll!ClassicSTAThreadDispatchCrossApartmentCall(tagRPCOLEMESSAGE * pMessage, OXIDEntry * pOXIDEntry, CSyncClientCall * pClientCall) Line 326	C++
 	[Inline Frame] combase.dll!CSyncClientCall::SwitchAptAndDispatchCall(tagRPCOLEMESSAGE * pMessage) Line 6126	C++
 	combase.dll!CSyncClientCall::SendReceive2(tagRPCOLEMESSAGE * pMessage, unsigned long * pstatus) Line 5816	C++
 	[Inline Frame] combase.dll!SyncClientCallRetryContext::SendReceiveWithRetry(tagRPCOLEMESSAGE *) Line 1740	C++
 	[Inline Frame] combase.dll!CSyncClientCall::SendReceiveInRetryContext(SyncClientCallRetryContext *) Line 633	C++
 	combase.dll!ClassicSTAThreadSendReceive(CSyncClientCall * pClientCall, tagRPCOLEMESSAGE * pMsg, unsigned long * pulStatus) Line 615	C++
 	combase.dll!CSyncClientCall::SendReceive(tagRPCOLEMESSAGE * pMessage, unsigned long * pulStatus) Line 823	C++
 	[Inline Frame] combase.dll!CClientChannel::SendReceive(tagRPCOLEMESSAGE *) Line 702	C++
 	combase.dll!NdrExtpProxySendReceive(void * pThis, _MIDL_STUB_MESSAGE * pStubMsg) Line 1960	C++
 	rpcrt4.dll!NdrClientCall2()	Unknown
 	combase.dll!ObjectStublessClient(void * ParamAddress, long Method) Line 214	C++
 	combase.dll!_ObjectStubless@0() Line 171	Unknown
 	[Inline Frame] combase.dll!RemoteReleaseRifRefHelper(IRemUnknown *) Line 8315	C++
 	[Inline Frame] combase.dll!RemoteReleaseRifRef(CStdMarshal *) Line 8212	C++
 	combase.dll!CStdMarshal::DisconnectCliIPIDs() Line 4932	C++
 	combase.dll!CStdMarshal::Disconnect(unsigned long dwType) Line 4334	C++
 	combase.dll!DisconnectSwitch(void * pv) Line 4045	C++
 	combase.dll!CStdMarshal::DisconnectAndRelease(unsigned long dwType) Line 4093	C++
 	combase.dll!COIDTable::ThreadCleanup() Line 1794	C++
 	[Inline Frame] combase.dll!FinishShutdown::__l2::<lambda_52cd3ea394b0aaaaa4b6e0872859635a>::operator()() Line 2371	C++
 	combase.dll!ObjectMethodExceptionHandlingAction<<lambda_52cd3ea394b0aaaaa4b6e0872859635a> >(FinishShutdown::__l2::<lambda_52cd3ea394b0aaaaa4b6e0872859635a> action, ObjectMethodExceptionHandlingInfo *) Line 131	C++
 	combase.dll!FinishShutdown() Line 2375	C++
 	combase.dll!ApartmentUninitialize(int fHostThread) Line 2688	C++
 	combase.dll!wCoUninitialize(COleTls & Tls, int fHostThread) Line 4107	C++
 	combase.dll!CoUninitialize() Line 4027	C++
>	chrome.dll!base::win::ScopedCOMInitializer::~ScopedCOMInitializer() Line 20	C++
 	chrome.dll!base::Thread::ThreadMain() Line 360	C++
 	chrome.dll!base::`anonymous namespace'::ThreadFunc(void * params) Line 94	C++
 	kernel32.dll!@BaseThreadInitThunk@12()	Unknown
 	ntdll.dll!__RtlUserThreadStart()	Unknown
 	ntdll.dll!__RtlUserThreadStart@8()	Unknown

I'm not convinced this is a duplicate so I'm reopening and assigning and I can share a crash dump off-line.

From a robliao@ about this from a few months ago:

Yep, this is definitely  crbug.com/645913  and a classic reason why it's very bad to join on terminating COM threads.

The issue is that the shell dialog thread needs to talk to an STA (and I strongly suspect this is the UI thread). The UI thread, in the meantime, is waiting for the shell dialog thread to terminate.

The fix here is to have the shell dialog stuff move to the Task Scheduler, making the thread join go away.

Details:

0:046> kn200 [Requesting to shutdown the apartment and probably needs to tell a proxy on the UI thread we're going away.]
 # ChildEBP RetAddr  
00 1a9eee34 757ed3ee win32u!NtUserMsgWaitForMultipleObjectsEx+0xc
01 1a9eeea4 757aaf1d user32!RealMsgWaitForMultipleObjectsEx+0x7e
02 1a9eeecc 75be3fe6 user32!MsgWaitForMultipleObjectsEx+0x3d
03 1a9eef04 75be3e4c combase!CCliModalLoop::BlockFn+0xfd [onecore\com\combase\dcomrem\callctrl.cxx @ 2351] 
04 1a9eef48 75be3c38 combase!ModalLoop+0xb3 [onecore\com\combase\dcomrem\chancont.cxx @ 171] 
05 1a9eef64 75c0ac93 combase!ClassicSTAThreadDispatchCrossApartmentCall+0x48 [onecore\com\combase\dcomrem\chancont.cxx @ 326] 

0:000> kn10 [Hey, when is that shell dialog going away? Surely it doesn't need to talk to me, does it?]
 # ChildEBP RetAddr  
00 04bbf184 74d62329 ntdll!NtWaitForSingleObject+0xc
01 04bbf1f8 74d62282 KERNELBASE!WaitForSingleObjectEx+0x99
02 04bbf20c 6886ded7 KERNELBASE!WaitForSingleObject+0x12
03 04bbf234 6886e2fc chrome!base::PlatformThread::Join+0x67 [C:\b\c\b\win_clang\src\base\threading\platform_thread_win.cc @ 249] 
04 04bbf24c 6886e53b chrome!base::Thread::~Thread+0x2c [C:\b\c\b\win_clang\src\base\threading\thread.cc @ 64] 
05 04bbf258 6926134f chrome!base::Thread::~Thread+0xb [C:\b\c\b\win_clang\src\base\threading\thread.cc @ 63] 
06 04bbf274 68ea81bb chrome!ui::BaseShellDialogImpl::EndRun+0x51 [C:\b\c\b\win_clang\src\ui\shell_dialogs\base_shell_dialog_win.cc @ 53] 
07 04bbf290 68ea8372 chrome!`anonymous namespace'::SelectFileDialogImpl::FileNotSelected+0x29 [C:\b\c\b\win_clang\src\ui\shell_dialogs\select_file_dialog_win.cc @ 513] 

[stability sheriff] Per comment #11 marking as a dup.