TFS Build Service Dependencies

Anyone who has had to deal with services failing to start (i.e. logon permissions, setting recovery responses [run a program], verifiying dependencies, etc.) knows what a real PITA it can be to track down the culprit of the failure. Having said that I recently had an issue with the "Visual Studio Team Foundation Build Service Host" service. A message box that stated “Cannot start service TFSBuildServiceHost on computer ‘contoso.na.microsoft.net'. (The dependency service or group failed to start) ” was promptly displayed when trying to start the service. As you'll soon see there's a quick fix for this problem but something that you might not directly think of.

Note: The error generated is immensely helpful in this case.

Service in Question

Event Log

Log Name: System
Source: Service Control Manager
Date: 1/01/2011 12:00:00 AM
Event ID: 7001
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: contoso.na.microsoft.net
Description:
The Visual Studio Team Foundation Build Service Host service depends on the Remote Access Connection Manager service which failed to start because of the following error:
The service cannot be started, either because it is disabled or because it has no enabled devices associated with it.
Event Xml:
<Event xmlns="https://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Service Control Manager" Guid="{111222d3-a4d4-5555-6e7e-88889d9999f9}" EventSourceName="Service Control Manager" />
<EventID Qualifiers="49152">7001</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8080000000000000</Keywords>
<TimeCreated SystemTime="2011-01-01T12:00:00.866250000Z" />
<EventRecordID>50047</EventRecordID>
<Correlation />
<Execution ProcessID="123" ThreadID="1234" />
<Channel>System</Channel>
<Computer>contoso.na.microsoft.net</Computer>
<Security />
</System>
<EventData>
<Data Name="param1">Visual Studio Team Foundation Build Service Host</Data>
<Data Name="param2">Remote Access Connection Manager</Data>
<Data Name="param3">1234</Data>
</EventData>
</Event>

Having received that message, I went through the normal process of checking the event log and then checking the service itself. Apparently there are dependencies for the "Visual Studio Team Foundation Build Service Host" service and I found that the "Remote Access Connection Manager" was in a disabled state. I promptly set it to an automatic start and tried once again to start the build service only to find it still fail. Once more I checked the dependencies and the "Remote Access Connection Manager" had a dependency of "Telephony" that was also in a disabled state. By enabling the "Telephony" service, I was able to bring up the "Remote Access Connection Manager" service and subsequently able to start the TFS build service.

Dependency

So the obvious question: "why" is this dependency necessary? Well according to the TFS Build Team, if the "Remote Access Connection Manager Service" is disabled the "Visual Studio Team Foundation Build Service Host" service will not start when the machine restarts hence a dependency on it. Digging a little deeper, if you look at the call stack (via windbg), the tfsbuildservicehost code is calling into the networking api GetAddrInfo which in turn calls into WSAttemptAutodialName, finally calling down into the driver. It’s a dependency that is unavoidable because of the underlying Windows networking infrastructure.

Lessons Learned

Always check the dependencies on a particular service if it fails as well as any event logs that may have been generated as these logs are a wealth of information.

Comments

• Anonymous
  May 12, 2011
  The auditors come in and write us up if we have remote access and telephony enabled because in their mind it potentially allows someone to gain remote access without having to go thru proper authentication, VPN, etc. Can this be fixed?
• Anonymous
  May 12, 2011
  @Dave~ I spoke to a few dev's on the TFS team and unfortunately that dependncy is necessary. However, it may change in TFS vNext.