New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 613001 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Jun 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug



Sign in to add a comment

Unable to connect to ToT Windows host with Curtain Mode

Project Member Reported by ajnolley@chromium.org, May 18 2016

Issue description

Version: found with 52.0.2739.0, but any host within last couple weeks
OS: Windows

What steps will reproduce the problem?
(1)Attempt to connect to a ToT Windows Host
(2)It briefly connects to a white screen for a few seconds, then disconnects

Sawbuck log includes this line:

ERROR	11080	11580	16:09:37-951	c:\b\build\slave\win64\build\src\remoting\host\desktop_session_win.cc	266	Failed to create RdpSession object, 0x80004002.
 

Comment 1 by joedow@chromium.org, May 19 2016

Labels: OS-Windows
Owner: zijiehe@chromium.org
Status: Assigned (was: Untriaged)
The bug impacts 64 bit host only.
This bug is because we have registered our 64 bit dll into 32 bit registry branch (HKLM\Software\Classes\Wow6432Node). After executing regsvr32 remoting_core.dll, the issue has been fixed on my machine.

So there are two issues,
1. Why do we install our 64 bit binary in "Program Files (x86)" (32 bit binary location on 64 bit windows os)? If this is not intended -- Personally I do not think so :) --, it is because of missing a 'Platform' parameter in our WXS file. And this issue may impact registry changes later in WXS file.
2. Why do we manually generate registry keys / values in WXS file? Indeed we have DllRegistryServer and DllUnregistryServer exported from remoting_core.dll, so ideally executing regsvr32 can help us to register the dll for us, since we have only one com implementation RdpDesktopSession, which shares guid with IRdpDesktopSession.

Comment 4 Deleted

Comment 5 Deleted

I have tried to build with both GN and GYP in x64 mode (GN by default uses x64, and for GYP, I have set "{'GYP_DEFINES': 'target_arch=x64',}" chromium.gyp_env), both generated correctly file. So I assume there may be something wrong with target_arch parameter.
This is not a chromium bug.
Status: WontFix (was: Assigned)
Resolved as WontFix.

Sign in to add a comment