Windows 10 does not look to start service until logon

Hi all,

We published an official release today - this release includes a fix for the problem we discussed in this thread.

Please install the new version and send us your feedback.

Cheers

All comments

Hi,

I would like to inform you what we know so far and where exactly we are on this problem.

First, I would like to dispense some false information that I read here in this thread:

The problem is not about the TeamViewer service startup not working or about incorrect service settings. The service starts fine after the PC is booted. You should not enable the interactive mode for the service as this can prevent the service from running on some PCs.
The Windows 10 Creators update doesn't always break TeamViewer. Actually, we are still not able to find a single device here that had any problems after the Creators update, which makes this problem very hard to analyze or fix.

So what is the problem?

As far as we can tell the TeamViewer service cannot open outgoing TCP connections while there is no user logged in. And if that doesn't work you'll not see the device as “online” and won't be able to connect to it using the TeamViewer ID. Incoming connections on the other hand are completely fine, which is why connections using the IP or hostname work. Existing connections will stay alive if the user logs out, and that's why devices stay online in TeamViewer. However, connecting to it will not work as in this case the TeamViewer service would try to create a new outgoing connection.

This all doesn't seem to be a bug in TeamViewer and therefore we also probably cannot fix it. It's much more likely that this is a bug in Windows and therefore we assume it might be a Microsoft issue.

Which devices are affected?

At first, we only received reports from users with Lenovo or Fujitsu devices. However during the last few days, we also received some reports about devices from HP, Dell and ASUS. This means that in general there doesn't seem to be a common factor on the manufacturer side. We assume that the fact that the issue occurred only on devices from two manufacturers at the beginning might be related to the rollout strategy for the Windows Creators update.

The hardware and software on the devices is also very diverse, so we cannot pinpoint it to anything more specific there either. Right now, our best guess is that it's a setting on those devices or in the network they are connected to that is causing this problem. But we don't have enough data to see what exactly that setting could be.

What might help to fix this problem?

So far, we have received three cases where a user reported that something fixed the problem.

The first one was to remove the USBPcap driver (part of Wireshark).
The second one was that it fixed itself over night after a Windows update.
And the third one was to not use proxy discovery over WPAD (source: https://superuser.com/questions/1198203/make-teamviewer-work-before-user-login#comment1752259_1198203).

We did not find USBPcap on any of the other devices that are affected by this problem. Also, the Windows update that was installed is also installed on all the other device that still have the problem. Most users also didn't use a proxy to connect to the Internet once they were logged in. So, while this might work for some other people, none of this sounds like the real solution.

What did we do so far?

We checked and compared a lot of support collector data from different users. As stated above so far there's no real common theme anywhere.
We inspected our network code to see if anything there might be wrong and could explain the errors we see, but could not find anything.
We tried to raise this issue with Microsoft, yet so far they are not aware of any problems. We will continue to stay in touch with them as we believe this might be where the issue may be raised.
We set up different PCs and notebooks with Windows 10 + Creators update in different network environments, but so far all of them work as expected. We still have a few notebooks left though and will continue to try to reproduce it here.

How can you help?

In order to solve this issue as quickly as possible we kindly request you to support us with your help:

Please post this problem in the Windows 10 feedback app from the PC where it occurs. This helps us to broaden the awareness about this issue on the Microsoft side so that they also start investigating it. It can also give Microsoft some data for the PCs that are affected by it that we don't have yet.
If you can provide some additional information about your network settings and infrastructure that would also help:
- Are the PCs in a domain (I think that was already answered as "doesn't matter")?
- Did you configure the PCs in any special way to be able to join your network or do you have anything in your LAN that blocks unknown devices?
- Please check the firewall (local and hardware firewall, if available) for error messages / ports being blocked / etc. for destination *.teamviewer.com. Is there anything being blocked? And if so, why?
- Are there any port limitations for local ports of outgoing connections (for example: only allow port starting at 32765, or similar)?
- Please check the output of the following two commands and post them here if they don't match the expected values:
  1) netsh int ipv4 show dynamicportrange tcp
  2) netsh int ipv4 show excludedportrange tcp
  The first command should show a starting port of around 49152 and a total count of about 16384.
  The second command should show an empty list.
- Run autoruns (https://technet.microsoft.com/de-de/sysinternals/bb963902.aspx) and check the Winsock Providers and Network Providers tab. Is there anything in there?

Thank you very much for your collaboration and understanding!

Hi all,

We published an official release today - this release includes a fix for the problem we discussed in this thread.

Please install the new version and send us your feedback.

Cheers

Hi all,

Thank you for your contribution here.

Yes, it is true that we found a solution for the problem - we gave a CustomBuild to a few customers to test it and it seems like we finally found a fix for the problem.

However, we cannot publish this version at the moment since it is a CustomBuild and not an official TeamViewer release. I will inform you, when we published an official version.

A big THANK YOU to everyone here who helped us with giving system information or testing different things Maurice asked for.

And of course a big THANK YOU to @Maurice our developer who fixed this.

Cheers

Vibes

I have tried this on a second computer, however this time I installed Microsoft KB4013214 prior to the upgrade. Teamviewer works on this device without problem.

For me the solution is not to upgrade to Windows 10 V 1703 without first running KB4013214

chrullrich

Well, I think I know what happens, but I have no idea why.

This is an excerpt from a WFP event capture on 1703:

<netEvent>
    <header>
        <timeStamp>2017-05-09T22:12:26.351Z</timeStamp>
        <flags numItems="9">
            <item>FWPM_NET_EVENT_FLAG_IP_PROTOCOL_SET</item>
            <item>FWPM_NET_EVENT_FLAG_LOCAL_ADDR_SET</item>
            <item>FWPM_NET_EVENT_FLAG_REMOTE_ADDR_SET</item>
            <item>FWPM_NET_EVENT_FLAG_LOCAL_PORT_SET</item>
            <item>FWPM_NET_EVENT_FLAG_REMOTE_PORT_SET</item>
            <item>FWPM_NET_EVENT_FLAG_APP_ID_SET</item>
            <item>FWPM_NET_EVENT_FLAG_USER_ID_SET</item>
            <item>FWPM_NET_EVENT_FLAG_IP_VERSION_SET</item>
            <item>FWPM_NET_EVENT_FLAG_PACKAGE_ID_SET</item>
        </flags>
        <ipVersion>FWP_IP_VERSION_V4</ipVersion>
        <ipProtocol>6</ipProtocol>
        <localAddrV4>192.168.92.134</localAddrV4>
        <remoteAddrV4>192.168.92.6</remoteAddrV4>
        <localPort>49950</localPort>
        <remotePort>3128</remotePort>
        <scopeId>0</scopeId>
        <appId>
            <data>5c006400650076006900630065005c0068006100720064006400690073006b0076006f006c0075006d00650034005c00700072006f006700720061006d002000660069006c00650073002000280078003800360029005c007400650061006d007600690065007700650072005c007400650061006d007600690065007700650072005f0073006500720076006900630065002e006500780065000000</data>
            <asString>\.d.e.v.i.c.e.\.h.a.r.d.d.i.s.k.v.o.l.u.m.e.4.\.p.r.o.g.r.a.m. .f.i.l.e.s. .(.x.8.6.).\.t.e.a.m.v.i.e.w.e.r.\.t.e.a.m.v.i.e.w.e.r._.s.e.r.v.i.c.e...e.x.e...</asString>
        </appId>
        <userId>S-1-5-96-0-2</userId>
        <addressFamily>FWP_AF_INET</addressFamily>
        <packageSid>S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523</packageSid>
        <enterpriseId/>
        <policyFlags>0</policyFlags>
        <effectiveName/>
    </header>
    <type>FWPM_NET_EVENT_TYPE_CLASSIFY_DROP</type>
    <classifyDrop>
        <filterId>66432</filterId>
        <layerId>48</layerId>
        <reauthReason>0</reauthReason>
        <originalProfile>3</originalProfile>
        <currentProfile>3</currentProfile>
        <msFwpDirection>MS_FWP_DIRECTION_OUT</msFwpDirection>
        <isLoopback>false</isLoopback>
        <vSwitchId/>
        <vSwitchSourcePort>0</vSwitchSourcePort>
        <vSwitchDestinationPort>0</vSwitchDestinationPort>
    </classifyDrop>
</netEvent>

This is the TeamViewer service attempting an outbound connection to an HTTP proxy. The attempt fails, as can be seen from the FWPM_NET_EVENT_TYPE_CLASSIFY_DROP.

The event references the filter rule with ID 66432. This is it:

<item>
    <filterKey>{9a00657e-fe37-47c1-818c-f643513fc2fe}</filterKey>
    <displayData>
        <name>Block Outbound Default Rule</name>
        <description>Block Outbound Default Rule</description>
    </displayData>
    <flags/>
    <providerKey>{4b153735-1049-4480-aab4-d1b9bdc03710}</providerKey>
    <providerData>
        <data>6000000000000000</data>
        <asString>`.......</asString>
    </providerData>
    <layerKey>FWPM_LAYER_ALE_AUTH_CONNECT_V4</layerKey>
    <subLayerKey>{b3cdd441-af90-41ba-a745-7c6008ff2300}</subLayerKey>
    <weight>
        <type>FWP_EMPTY</type>
    </weight>
    <filterCondition numItems="1">
        <item>
            <fieldKey>FWPM_CONDITION_ALE_PACKAGE_ID</fieldKey>
            <matchType>FWP_MATCH_NOT_EQUAL</matchType>
            <conditionValue>
                <type>FWP_SID</type>
                <sid>S-1-0-0</sid>
            </conditionValue>
        </item>
    </filterCondition>
    <action>
        <type>FWP_ACTION_BLOCK</type>
        <filterType/>
    </action>
    <rawContext>0</rawContext>
    <reserved/>
    <filterId>66432</filterId>
    <effectiveWeight>
        <type>FWP_UINT64</type>
        <uint64>549755813888</uint64>
    </effectiveWeight>
</item>

This rule applies whenever its single condition matches. The condition is that the "package ID" of the packet's (actually, the connection's) originator is not S-1-0-0 (no identity), or in other words, it matches everything that has a package ID.

In the event trace, we see that the TeamViewer service process has a package ID, wherever it may have acquired it, hence it matches this rule and its traffic is blocked.

I have no idea where the rule comes from (except that it is a Windows Firewall rule per its provider ID) or what it may be intended to do. My current guess is that "modern" apps are not supposed to communicate when no user is logged on.

I cannot prove that this is any different on 1607, because apparently WFP captures do not include permitted packets. According to Process Explorer, the service process has no application package SID in either version.

As far as I know the MSI file will be available with the next official release, or shortly after that.

As for what the problem was, or what we fixed. The TeamViewer service tries to connect when it first starts using TCP. on port 5938. For some reason this first connection fails on some systems. This could have a couple of reasons (Firewall, network not yet ready, etc.). In theory this should not matter.After the first failed connection attempt the service tries to connect using HTTPS, and that's where the problem was. For HTTPS it's possible that there is a proxy in use and proxy settings are normally user settings. So the service checks if there is a user logged in and tries to impersonate that user. And for that check we had a bug because we didn't filter out app container users, which were introduced in Windows 8 to limit access to unneeded resources (e.g. the network). Until the Windows 10 Creators update this didn't cause any problems, but after it the TeamViewer service found such a user and impersonated it, which meant the serivce was using a user that has no access to the network device. So we fixed our check for logged in users and filtered out app container users.

It looks like the Windows 10 update changed some WiFi settings which caused it to not connect until a user is logged in.

If you are using a user + password to connect to your WiFi network, this is how to change it:

Open the "Network and Sharing Center"
Click on the label for the wireless network connection (somewhere on the right)
Click on "Wireless Properties"
Open the "Security" tab
Click on "Advanced settings"
On the first tab ("802.1X settings") in the dropdown at the top, switch to "user authentication"
Click on the "save credentials" button
Enter your username + password (for domain users, don't add the "domain\" part, just the username is enough)
Click on Ok and close all dialogues. This should disconnect shortly from the WiFi network and reconnect again.

If the WiFi connection doesn't work after changing the settings, you might have to go to the Wi-Fi settings in Windows 10 -> "Manage known networks" and remove the entry there. I wasn't able to find another way to get to the wireless properties dialog if it was not connected.

jkelly

Hi,

I'm fully willing to accept that something has changed in recent versions of Windows that provokes this problem. However, in case it can help, I thought I'd post my latest expereince.

I installed Teamviewer 12 on a Windows 2012 Essentials R2 server and had the same problem--impossible to connect if a user is not logged in. But installing the Teamviewer 8 client resolved the issue for me. So sufficiently older versions of Teamviewer don't elicit the problem. (Teamviewer 8 on Windows 10 has worked repeatedly for me as well.)

-Kelly

I wasn't able to reproduce this problem for LAN connections yet. All I can tell from other users is that the TeamViewer service cannot connect while there is no user logged in. As for why that's the case, I don't know. Will investigate further...

DomLan

Hi to all,

An information: your systems are equipped with the patch KB4016240 (build 15063.250) post Creators Update?

From change-log: Fixed a bug that prevented Lock Screen from being disabled through Group Policy in Professional Edition. Fixed a problem with the Windows Forms configuration options that cause a startup anti-virus software block.

Thanks in advance.

Regards

chrullrich

chrullrich wrote:
In the event trace, we see that the TeamViewer service process has a package ID, wherever it may have acquired it, hence it matches this rule and its traffic is blocked.

From the WFP trace:

<packageSid>S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523</packageSid>

From the list of app containers:

Container:
SID: S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523
Name: microsoft.windows.fontdrvhost
Display name: Usermode Font Driver Host

That is clearly the same SID. So how does the TeamViewer service get stuck with the "font driver host"'s package identity?

jsa

We have updated 2 Dell PC's last sunday. They both have teamviewer 13.

Teamviewer doses not work on one of them - but the other has no problems.

We can start the teamviewer but we are not able to use it as remote.

Is there any solution to this?

wrswaim

Ok I'll clarify just one more time as I did post my explanation earlier. It did resolve that one problem at that one time in my case alone. I passed it along so as to resolve it for some, not all. Also there was another "solution" posted earlier before mine so you may be confusing mine with that one.
I have listed several times since that the newest revision of their update has nullified what worked before - basically back to where we all started.
We're all on the same team here and a community that helps some with what we do discover though it may not help all.
I understand the frustration with it and wanting to vent to someone and feel it with you until they finally fix this for everyone. Until then let's leave the larger answer to the TV programmers and please direct all other comments to them.
I genuinely hope it gets resolved for you and wish you a great day and great week in everything.

Thanks for the explanation.

In our case, it was the firewall, blocking the way out of our network. Any unnesseccary ports are blocked (including 5938), and HTTP(S) is only allowed for authenticated users. Before the Creator's update, the Teamviewer service was still able to pass through for whatever reason, but after the update, the impersonation must have triggered the blocking mechanism, leaving the service unable to notify the TV server.

The moment I opened up port 5983 for outgoing traffic, a test computer from inside our LAN appeared in my contact list as online.

As I highly doubt that TV 10 will get patched (that's what we use), I have to evaluate to either keep that port open or simply allow all HTTPS traffic to TV servers (which should work as well, according to the explanation above)...

nicktuf

The Service is running fine, the problem, as described by Julia, is a compatibility issue with Teamviewer and the Windows Firewall. Teamviewer have a solution for it, but I'm not happy using a custom build as it could contain other bugs and I assume has not gone through the full QA process.

wrswaim

Could we please remove this as being marked "solved." Numerous people are still having the same issue without any change. Please provide a fix as soon as possible.

Thanks so much.

Meanwhile i will go ahead and begin a new thread.

wrswaim

Hi Tim,

Thank you for the exhortation, and if misleading I apologize. Not sure if you were directing at me o the "solved" marking on the other reply. Nevertheless, let me clarify and leave it alone after this. (any caps in letters are not yelling just for extra emphasis)

MY solution ONLY - not THE solution - was that even after the new update TV 12 - and a reboot - still didn't work properly. None of the "solutions" or the recent "fix/path" worked still on any of my pc's, the problem persisted.

Down to trying anything I wandered into there and noticed the power settings were not as before and returned the hdd to "never" shut off. I also know this is obvious (I've used & fixed pc's since 1987) but happened onto this when no changes to these settings had been made before - and on one pc "never" was already set, so I reset it. Also having the "never" setting on before did not change that TV 12 would not work regardless. But now it does.

So this was entirely relevant as it related to TV not coming on after reboot - this fixed it for me (though any change to the hdd power/sleep options before changed nothing, now it does).

Now 12+ hours later I can still access them and so I offer this as just another "give this a try when nothing else technical works" kind of "solution" that may work for even just one other person who may be unaware.

We are a community and help each other where we can knowing that other fixes exist for particular pc's and others won't - in the hopes that TV will fix it all as they have done in the past. No wanderings, just one helping another find solutions.

I do sincerely hope a fix works for you, and fast. Thanks again for being of help and hope you have a great weekend.

zoo55

Nope, 12.0.78716 doesn't work on 10.0.15063. OK on 10.0.14393. <sigh>

Jnew1

What about v11 paid customers. We all know it is happening on this version as well. Are we going to have to pay more and update to version 12? Sure looks that way doesn't it.

Hi again,

We've discussed this topic again internally and have come to the conclusion that we want to share with everyone the Custom Build that contains the fix.

Here you can find the links (version 12) for the Host module and the full version:

Host module
Full version

We do NOT guarantee that this version is without any bugs – as I said in my previous post, this is not an official release. There could potentially still be other bugs included – it’s up to you if you want to install this version or not.

Cheers

mandfmike

How do you roll it back?

mandfmike

This didn't work for me.

Vibes

Hi Karsten

As I am also trying to discover the exact problem remotely I am having a little difficulty with access.

My situation is a follows:- Home location, small network with domain controller. Computer on the domain is still not working, laptop stand alone working.

I am trying to narrow this down a bit more, so your input will be of great help.

1/ is your remote pc on a network

2/ if you try to do updates do you get an error

I am just rebuilding a PC that is causing me problems, I will keep it out of the domain and see if I can get it working. Sorry I can't help more

karsten

this is my configuration:

laptop with a blank HD, Installation win10 1703 with media creation tool
domain join, network access both LAN or Wifi
teamviewer host 12 with recommended configuration
no errrors at updates
no reconnect after logout/reboot

second try, same laptop:

blank HD, Installation win10 1607 with media creation tool
Teamviewer 12 Host with recommended configuration
upgrade 1703 with "Windows 10-Upgrade-Assistent
network access both LAN or Wifi, no domain join
no errrors at updates
same problem as above

mandfmike

@Maurice wrote:
It looks like the Windows 10 update changed some WiFi settings which caused it to not connect until a user is logged in.
If you are using a user + password to connect to your WiFi network, this is how to change it:
Open the "Network and Sharing Center"
Click on the label for the wireless network connection (somewhere on the right)
Click on "Wireless Properties"
Open the "Security" tab
Click on "Advanced settings"
On the first tab ("802.1X settings") in the dropdown at the top, switch to "user authentication"
Click on the "save credentials" button
Enter your username + password (for domain users, don't add the "domain\" part, just the username is enough)
Click on Ok and close all dialogues. This should disconnect shortly from the WiFi network and reconnect again.
If the WiFi connection doesn't work after changing the settings, you might have to go to the Wi-Fi settings in Windows 10 -> "Manage known networks" and remove the entry there. I wasn't able to find another way to get to the wireless properties dialog if it was not connected.

What about LAN connections? I have 5 computers on my domain that won't connect to teamviewer until a user logs in, because I installed Win10 SP 1703. I can RDP the machines, then I'm able to use teamviewer to get in, but I don't want RDP turned on because of the security risk. Thats why I pay for teamviewer. Speaking of teamviewer, they should be trying to resolve this issue. Nothing I have read here worked for me.

I have the same problem, currently using TeamViewer 10. Any connection via contact list or a teamViewer ID is not possible unless someone is logged in.

I noticed though that I am still able to connect if the computer is within our LAN, it does work when I try to connect to a IP address or DNS name. So doesn't seem to be a problem of the service itself running on the computer, more likely a communication issue between the client service and the TeamViewer server. Maybe this info is of help for someone who uses TV also for internal support as well...

Oleksandr

Last version TV, Windows 10 Pro 1703 - same problem. Not connected without logon

Yes, we've tested patch KB4016240 and the result is that it behaves even weirder.

If my target computer is within our LAN, it does not make a difference. It's the same as before that patch, connection via IP/DNS is possible, via address book or Teamviewer-ID it is not. The computer icon in the address book only turns blue once someone logs in locally. Funny thing is, after logging out locally, the icon now stays blue, suggesting the remote computer is still reachable, yet I cannot connect anymore.

OTOH, if my target computer is outside our LAN, it seems to be back to normal. The computer icon in the address book turns blue once the TV service starts and connection is possible.

I would still prefer though to be able to connect to internal mobile devices with the help of the TV-ID, since we use several sub-domains and always stating the full DNS name is a bit annoying...

@Bauer: Is the target computer the same computer? And if it's outside your LAN, is it connected through WiFi or LAN? If that really makes a difference I'd like to know what exactly the difference is in network infrastructure that would cause such a problem.