Works without a test case if u open any file in Chrome when it is run as an administrator 

This does not represent a security issue (DoS at worst) and thus changing to a regular bug for triage in reliability impact.

Able to reproduce this issue on windows 7 using chrome stable version 54.0.2840.99 
Issue is broken in M55. 

Bisect Info:
===========
Good build : 43.0.2324.0,  Revision Range 319433
Bad build  : 43.0.2325.0,  Revision Range 319543

Unable to run the bisect script, 
Through omahaproxy we are giving CL between Good and Bad builds
=================================
https://chromium.googlesource.com/chromium/src/+log/43.0.2324.0..43.0.2325.0?pretty=fuller&n=10000


unable to find the suspecting CL, can anyone from dev team will look into this issue and assign it to right owner.

Sorry for typo mistake, the issue is broken in M43

Issue is seen on latest canary 57.0.2937.0.

Unable to perform this on Mac and Linux as we do not have the option to run the console/command prompt as Administrator.

Possible suspects from the above CL:
Review URL: https://codereview.chromium.org/969813005
Review URL: https://codereview.chromium.org/982993002
robliao@/jennyz@ : Could you please take a look into this if its related to your change, else could you please help assigning to an appropriate owner for this.

tl;dr - Non-elevated Chrome automatically things a valid hwnd that failed a SendMessageTimeout with access denied is hung. Should we support this?

Adding siggi for awareness (although it's not really his fault) and jschuh for a policy consult.

jschuh: Do we support launching elevated Chrome?

Analysis begins here:
The file is a red herring. Running Chrome Elevated and then attempting to launch Chrome normally will trigger the issue. The stack for the dialog is as follows:

07 00000021`51efdcc0 00007ff8`1d9edc91 chrome_7ff81bb70000!ui::MessageBoxW+0xc1
08 00000021`51efdd70 00007ff8`1d9eded3 chrome_7ff81bb70000!chrome::`anonymous namespace'::ShowMessageBoxImpl+0x199
09 00000021`51efdff0 00007ff8`1e3a3abf chrome_7ff81bb70000!chrome::ShowQuestionMessageBox+0x73
0a 00000021`51efe0c0 00007ff8`1e3a3e13 chrome_7ff81bb70000!`anonymous namespace'::DisplayShouldKillMessageBox+0x47
0b (Inline Function) --------`-------- chrome_7ff81bb70000!base::Callback<bool __cdecl(void),1>::Run+0xa
0c 00000021`51efe140 00007ff8`1ca933d2 chrome_7ff81bb70000!ProcessSingleton::NotifyOtherProcess+0xab
0d (Inline Function) --------`-------- chrome_7ff81bb70000!ProcessSingleton::NotifyOtherProcessOrCreate+0x1e
0e (Inline Function) --------`-------- chrome_7ff81bb70000!ChromeProcessSingleton::NotifyOtherProcessOrCreate+0x25
0f 00000021`51efe180 00007ff8`1ca92363 chrome_7ff81bb70000!ChromeBrowserMainParts::PreMainMessageLoopRunImpl+0x6f2
10 00000021`51efee50 00007ff8`1bddf53f chrome_7ff81bb70000!ChromeBrowserMainParts::PreMainMessageLoopRun+0x10b
11 00000021`51efeed0 00007ff8`1bddebce chrome_7ff81bb70000!content::BrowserMainLoop::PreMainMessageLoopRun+0x97
12 (Inline Function) --------`-------- chrome_7ff81bb70000!base::Callback<int __cdecl(void),1>::Run+0xa
13 (Inline Function) --------`-------- chrome_7ff81bb70000!content::StartupTaskRunner::RunAllTasksNow+0x18
14 00000021`51efef40 00007ff8`1bde3652 chrome_7ff81bb70000!content::BrowserMainLoop::CreateStartupTasks+0x29e
15 00000021`51eff030 00007ff8`1bddc410 chrome_7ff81bb70000!content::BrowserMainRunnerImpl::Initialize+0x4de
16 00000021`51eff230 00007ff8`1ca40053 chrome_7ff81bb70000!content::BrowserMain+0xe0
17 (Inline Function) --------`-------- chrome_7ff81bb70000!content::RunNamedProcessTypeMain+0x160
18 00000021`51eff280 00007ff8`1bc53897 chrome_7ff81bb70000!content::ContentMainRunnerImpl::Run+0x1ff
19 (Inline Function) --------`-------- chrome_7ff81bb70000!content::ContentMain+0x81
1a 00000021`51eff430 00007ff6`48e172ff chrome_7ff81bb70000!ChromeMain+0x233

When attempting to send WM_COPYDATA to the remote_window, SendMessageTimeout fails and the last error is...

0:000> !gle
LastErrorValue: (Win32) 0x5 (5) - Access is denied.

This is unsurprising as the remote hwnd is likely an elevated HWND.
The next check is to verify that the hwnd is still an HWND and Windows will happily respond that it is indeed (since Elevated Chrome is still running).

The conclusion we automatically draw at this point is that it must be hung, even though that's not really the case.

Looking at the change log, there is a change that deals with hung windows:
https://codereview.chromium.org/982323002

This change is also interesting
https://codereview.chromium.org/981223004

I cannot see a good reason to support running Chrome elevated Chrome, and I can think of many very bad things that can happen if you run any browser elevated.

I would agree with that sentiment. Since we do not support running Chrome elevated, this seems like a good WontFix. Feel free to reopen if this assessment misses an important case for Chrome.