It would be helpful if you could include a log from the host computer. You can find instructions at https://productforums.google.com/d/msg/chrome/RMpoN0WEpzg/0yvbde0ZIFkJ; specifically the section titled Recording an ETW trace.

Attached is the requested log .etl file. 

Deleted: chromoting.etl 8.0 KB

chromoting.etl 8.0 KB Download

I've actually attached one more, as the previous log I'm pretty sure was ran while using  a older "rolled back" version of CRD that I found. (not sure if it matters). See attached. Thanks. 

Deleted: chromoting.etl 8.0 KB

chromoting.etl 8.0 KB Download

Neither of those logs contain anything, which suggests that the process is either not starting at all, or is exiting before logging anything.

Joe, can you suggest any further debugging steps?

Let's try to capture a trace from the beginning of the process.

Blake, can you do the following on the host machine (with the latest CRD service installed):
1.) Open an admin cmd prompt and type 'net stop chromoting'
2.) Begin the ETW capture steps Jamie pointed you to
3.) In the admin window, type 'net start chromoting'
4.) Stop the ETW capture and attach the output to this bug

For step #3, what was the output?  It should be something like:
The Chrome Remote Desktop Service service is starting.
The Chrome Remote Desktop Service service was started successfully.

If this fails, then run 'eventvwr.msc' and check the System event logs, there should be some notifications of the CRD service failing to start.  Can you grab the error code / text from those notifications and list it here?

Hi Joe,

Okay, I've followed your steps and included the new log. The output for step 3 was "The Chrome Remote Desktop Service service was started successfully." (Note that during these steps, I did not open CRD, I just ran the commands. If you need me to run CRD let me know, I can get another log). Please let me know what to do next, thanks!

Deleted: cmd.PNG 17.6 KB

	cmd.PNG 17.6 KB View Download

Deleted: chromoting.etl 8.0 KB

chromoting.etl 8.0 KB Download

Thanks for capturing the updated log file but it looks like it is still empty.

I'm not sure why no logging information is being included in the file, I'm wondering if there was an installation problem which prevented the logging component from being registered.

If you open the webapp on the host machine, do you see your host online and available (i.e. is this only a problem on the client or is this also an issue locally on the host)?

Also, do you see any processes running after running this command (can you copy the command output)?:
tasklist /V | findstr remoting_host.exe

It appears online on itself (host pc), however I'll note that there have been instances prior where it was not...it would appear offline just as it does on other devices. 

I don't see any other processes running after that command. (See attached screenshots). 

Deleted: host.PNG 9.6 KB

	host.PNG 9.6 KB View Download

Deleted: cmd_process.PNG 5.0 KB

	cmd_process.PNG 5.0 KB View Download

I just uninstalled and reinstalled CRD, and after enabling my PC, it's now showing up offline to itself. (see screenshot). 

Deleted: offline.PNG 9.8 KB

	offline.PNG 9.8 KB View Download

The tasklist output is odd as it only shows the daemon process running (There should be a second process running in a Local Service context as well).  If the second process isn't starting that could explain why nothing is being logged.

Would you mind running the tasklist command again now that you've uninstalled and reinstalled CRD?  I just want to make sure that only the daemon process exists.

Since we aren't getting any host logs, I'm wondering if we can get something from the client logs.  Can you try the following as well?
- Open the CRD web app on the host machine
- Disable the host
- In another Chrome tab, navigate to chrome://extensions
- Ensure that the "Developer Mode" checkbox at the top right of the page is checked.
- Scroll down to the Chrome Remote Desktop extension.
- Click the main.html link 
- Select the Console tab.
- Now enable the host, wait for any logging to complete
- Copy any output in the console tab and attach to the bug

It may also be good to look through the application and system logs in the event viewer to see if there is any info there.  Also, the initial comment in the bug said this was working ~3 weeks ago, is there anything around that time in the event viewer that seems like it might be a problem (updates/failures/etc)?

Still getting the same result for tasklist. 

This is the output log from the Console tab:

App mode: home.host-setup.ask-pin
ui_mode.js:122 App mode: home.host-setup.processing
dns_blackhole_checker.js:155 DNS blackhole check succeeded.
fallback_signal_strategy.js:339 FallbackSignalStrategy progress: xmpp succeeded
ui_mode.js:122 App mode: home.host-setup.done
ui_mode.js:122 App mode: home

I noticed this popped up with a red x next to it in the Console, prior to enabling the host(this popped up when clicking the arrows in the event viewer, not sure if this is related or not.): 

console_wrapper.js:115 [2016-09-28T03:40:55.981Z] Failed to read message header, read returned -1 c:\b\build\slave\win\build\src\remoting\host\native_messaging\native_messaging_reader.cc:93 native_message_host_log_message_handler.js:46remoting.ConsoleWrapper.recordAndLog_ @ console_wrapper.js:115remoting.NativeMessageHostDebugMessageHandler.handleMessage @ native_message_host_log_message_handler.js:46remoting.HostDaemonFacade.onIncomingMessage_ @ host_daemon_facade.js:187target.(anonymous function) @ extensions::SafeBuiltins:19EventImpl.dispatchToListener @ extensions::event_bindings:388target.(anonymous function) @ extensions::SafeBuiltins:19publicClassPrototype.(anonymous function) @ extensions::utils:151EventImpl.dispatch_ @ extensions::event_bindings:372EventImpl.dispatch @ extensions::event_bindings:394target.(anonymous function) @ extensions::SafeBuiltins:19publicClassPrototype.(anonymous function) @ extensions::utils:151dispatchOnMessage @ extensions::messaging:334
ui_mode.js:122 App mode: home.host-setup.ask-pin

Not exactly sure where the application/system logs or the event viewer are, but I did navigate to the applications tab and really didn't see any info or anything that looked out of the ordinary. Is it the application.js you're interested in? Let me know if there's anything else I can do.

Thanks. 

Found out what the Event Viewer is and where it's located, sorry. 

Disregard my above statement about clicking the arrows in the event viewer, those arrows were clicked in the main.html dev tool. 

After looking through the Application logs (over 5,000), I couldn't find anything that looked obvious around the time it stopped working. There were sporadic Errors, many of which had WMI as the source, but I couldn't see or tell if anything was necessarily related. They System logs had quite a few errors, particularly around the time this stopped working. I've attached some screens of some of the errors, some being a Google Update, let me know if any look to be relevant. (Sorry for all the posts/info at once). 

I'm still looking into this as it is a pretty odd problem.  I'm also going to remove some of the attachments that aren't needed (to clean up the discussion thread a bit).

I'm not seeing any obvious reason why the Daemon process is running but not the network process.  Can you run the following steps?  This will grab a detailed log file which should help quite a bit:

- Install Process Monitor (procmon.exe) from https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx
     - This is a tool used to monitor access to system resources
- Run 'net stop chromoting' in an admin window
- Run procmon (this will generate a ton of events so we will set a filter)
- In Procmon, press Ctrl+L (The filter dialog should show up)
- Select 'Process Name' in the left most drop-down box
- Select 'Contains' in the next drop-down
- Type 'remoting_' in the adjacent text field
- Click 'Add' then click 'Ok' (the filter will be applied to the existing events)
- Run 'net start chromoting' in an admin window
- Wait until the events written to the log seem to stop/slow substantially
- In Procmon, type CTRL + S, this will bring up the save to file dialog
- Make sure the 'Events displayed using current filter' option is selected
- Note the file path at the bottom of the dialog and click 'OK'
- Attach PML file to the bug (The file should be a few megabytes if the filters are set correctly)

Done. 

Deleted: Logfile.PML 4.1 MB

Logfile.PML 4.1 MB Download

Thanks, this really helped!

Based on the logs, the Daemon process starts up and then tries to start up our 'network' process, this one which handles incoming connections.  The network process starts up, fails to load a dependent DLL and exits.  The Daemon process attempts this a half-dozen times or so before giving up.

The exit code for the network process is 0xc0000135 which is STATUS_DLL_NOT_FOUND.  Looking at the log, here is the line that shows the DLL load failure:
remoting_host.exe	CreateFile	C:\Program Files (x86)\Google\Chrome Remote Desktop\52.0.2743.48\remoting_core.dll	ACCESS DENIED

This explains why you weren't getting any logging data, the process never finished loading so none of the code ever executed.



Before this statement I see a flurry of anti-virus file/registry key accesses.  In the thread you linked to in the first comment, you had said that you already contacted the AV manufacturer and ran through troubleshooting steps, during that time did you add the CRD processes and DLLs to an exclusion list?

Our service installs into a directory based on the version which can cause problems with exclusion whitelists, can you try adding an exclusion for remoting_host.exe and remoting_core.dll (located in "C:\Program Files (x86)\Google\Chrome Remote Desktop\52.0.2743.48\") and see if that works?  You may have already tried this but I wanted to double check first.



One other thing that stands out are these file accesses looking for Alternate Data Streams on the host binary:
remoting_host.exe	CreateFile	C:\Program Files (x86)\Google\Chrome Remote Desktop\52.0.2743.48\remoting_host.exe:BDU	NAME NOT FOUND

remoting_host.exe	C:\Program Files (x86)\Google\Chrome Remote Desktop\52.0.2743.48\remoting_host.exe:Zone.Identifier	NAME NOT FOUND

Based on the read failures above, I'm wondering if there is a security setting/policy on your machine which is blocking access to remoting_core.dll from the low-integrity network process.  The reads by themselves are fine (the second is to see if this binary was downloaded from the internet, I'm not compeltely sure about the first) but I don't see these on my machine.

Also, the Daemon process (running as SYSTEM) is able to load remoting_core.dll just fine, but the network process (running as Local Service with low-integrity) fails.  Based on this I'm thinking a policy might be preventing access to the DLL from the low-integrity process.

Glad this log was helpful! 

I did try adding Google, and CRD to the exclusion list. I didn't choose the .dll in particular, but it's parenting folders I did. As mentioned I also tried disabling the AV, and uninstalling the AV as well. That led me to believe my AV was not the culprit. However, based on your findings, I won't rule out the possibility that BitDefender has introduced additional issues on top of the assumed Policy issue. 

Please let me know what you think I should do next, again thanks for you assistance and persistence.

The key is identifying what is preventing our network process from accessing the DLL.

We can check the permissions of the file, just run these commands from an admin window (attach output to bug):
icacls "C:\Program Files (x86)\Google\Chrome Remote Desktop\*" /T

This tool will list the permissions for the CRD folder and files.  You should see something like this in the output for the folder and each file:
BUILTIN\Users:(I)(RX)

I would double check the AV exclusion list and settings next.  I see the AV DLLs are loaded in our process (based on the stack traces in the log file) so perhaps their code always injects itself regardless of the exclusion setting.  Is there an 'active' scanning component that can be disabled (easily) to prevent that?

Just saw the comment about uninstalling the A/V software in comment #20.  It may not be related, but perhaps it was failing previously for a different reason.  Might just be wroth a quick check.

Thanks, it looks like permissions are the problem.  Based on the screenshot, your account and SYSTEM have full access to the files but no other account does.

Typically local groups (i.e. Administrators. Users, etc) would also have right to access the files but that appears to be missing.

What is happening above is that we have a service which runs as the Local Service account, it is granted permissions via the 'Users' access group, since that group has no access to Program Files, our service cannot read a required DLL from the program files directory and fails to launch.

Did you change the permissions on the root Program Files folder?  The ACLs in the screenshot are all inherited so I'm assuming they are set further up in the folder hierarchy.

You can confirm the permissions are missing by opening a CMD window, changing to the root of C: and typing: icacls "Program Files (x86)"

Look for user account permissions like:
BUILTIN\Users:(RX)
BUILTIN\Users:(OI)(CI)(IO)(GR,GE)

If the permissions for users/administrators were removed, it would be good to restore them back.  You would want to apply them to the root of the program files directory so they are inherited downward through the child directories and files.  You can use icacls again for that or the Windows UI (right-click the directory > properties > security).

Also, you can copy/paste text from the command window by either using quick edit mode or marking the windows and selecting the text.

One other note, you can verify this is the problem by adding the User group permissions to the CRD files first.

Add the user and group permissions for the BUILTIN\User account group to "C:\Program Files (x86)\Google\Chrome Remote Desktop\", then verify you see that the user access group shows up on the CRD files when running the icacls command I provided previously.  If that looks good, then try to connect again via Chromoting.

I don't recall changing any permission in the root program files folder.

Output: 
Program Files (x86) CREATOR OWNER:(OI)(CI)(IO)(F)
                    NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)
                    NT AUTHORITY\SYSTEM:(M)
                    BUILTIN\Administrators:(OI)(CI)(NP)(F)
                    MASTERMACHINE\Blake Sanchez:(OI)(CI)(F)
                    BUILTIN\Users:(OI)(CI)(NP)(F)
                    NT SERVICE\TrustedInstaller:(CI)(M,WDAC,DC)

How exactly do I go about adding the permissions? I see the security tab, but once clicking advanced, there are quite a few options available to change. 

Navigate to "C:\Program Files (x86)\Google\Chrome Remote Desktop\52.0.2743.48" in an admin command window.

Then run: icacls * /grant BUILTIN\Users:(RX)

This command will give members of the users group (such as Local Service) the ability to read and execute the files in the CRD directory and should correct the ACCESS_DENIED error I see in the logs you provided.

Once you've done this, then try setting up a connection again and see if it works.

I ran the command, and then tried setting up the connection again, unfortunately no success. 

Here's what I had in the elevated cmd prompt just so you can verify it looks good: 

C:\Windows\system32>cd C:\Program Files (x86)\Google\Chrome Remote Desktop\52.0.
2743.48

C:\Program Files (x86)\Google\Chrome Remote Desktop\52.0.2743.48>icacls * /grant
 BUILTIN\Users:(RX)
processed file: com.google.chrome.remote_assistance.json
processed file: com.google.chrome.remote_desktop.json
processed file: CREDITS.txt
processed file: icudtl.dat
processed file: remote_assistance_host.exe
processed file: remote_security_key.exe
processed file: remoting_core.dll
processed file: remoting_desktop.exe
processed file: remoting_host.exe
processed file: remoting_native_messaging_host.exe
processed file: remoting_start_host.exe
processed file: sas.dll
Successfully processed 12 files; Failed processing 0 files

You may need to apply the permission to the folder as well since the root folder prevents propagation of the permission to its children.  I'm not sure if you need to add it to just the "52.0.2743.48" or the Google and Chrome Remote Desktop folders as well.

The goal is to ensure the effective permissions for the BUILTIN\Local Service group for remoting_core.dll allows it to read and execute.   This MSDN article has steps to view the effective permissions, just use 'Local Service' as the group name and verify it has read/execute permissions on the dll:
https://technet.microsoft.com/en-us/library/cc771586(v=ws.11).aspx

Okay. I ran the command and applied it to both folders. Still no avail. I checked the folders, and the .dll permissions and they appear to just have read permissions? (See screenshot)

Deleted: permissions.PNG 6.1 KB

	permissions.PNG 6.1 KB View Download

Joe, 

I have good news! I ran CRD as an admin, and it worked! I have access and the host is correctly showing up online! Don't know why this is or if it's related but nevertheless I'm satisfied!

Glad to hear it is working now!  Which part of CRD did you run as admin?  I'm curious what you did differently to get it working.

I just opened it by clicking start, searching for chrome remote desktop, and when the app appeared in the list, I right clicked and selected 'Run as Administrator'. Thank you for all the help. 

Great, resolving the bug since it is working now.