[solved] Failed to get socket connection from UnityShaderCompiler.exe shader compiler on TeamCity

[vovkas]

Hi.
I have night builds on TeamCity. Everything was fine. After adding the next package of assets, the building continue 2 times longer (+ 1.5 hours) and all materials are pink / magenta.
Build logs have increased significantly. Often there is such a line:

Failed to get socket connection from UnityShaderCompiler.exe shader compiler! C: / Program Files / Unity5.5.2 / Editor / Data / Tools64 / UnityShaderCompiler.exe
UnityEditor.BuildPipeline: BuildAssetBundlesInternal (String, BuildAssetBundleOptions, BuildTarget)
UnityEditor.BuildPipeline: BuildAssetBundles (String, BuildAssetBundleOptions, BuildTarget) (at C: \ buildslave \ unity \ build \ artifacts \ generated \ common \ editor \ BuildPipelineBindings.gen.cs: 425)

It looks like Unity.exe can not run UnityShaderCompiler.exe judging by what it shows TCPView (Windows tool).

If you run build-scripts under the same user with pens, not in TeamCity - they work fine (quickly, UnityShaderCompiler.exe starts, no logs in the logs).

I do not have ZoneAlarm installed.
Windows 10 pro
Windows Defender Security Center
RAM 8Gb
Intel i7 4790
Work-folder on ssd

Unity5.5.2
All is started with administrator rights.

How can I fix this? Any ideas?

Sometimes Unity.exe run UnityShaderCompiler.exe, but can not send/get data to UnityShaderCompiler.exe.

UnityShaderCompiler.exe 10048 TCP BUFALO 57289 localhost 56967 ESTABLISHED
Unity.exe 7148 TCP BUFALO 56967 localhost 57289 ESTABLISHED

shadercompiler-UnityShaderCompiler.exe0.log contains

Base path: C:/Program Files/Unity5.5.2/Editor/Data

Cmd: getPlatforms

Unhandled exception: Protocol error - failed to read correct magic number

Quitting shader compiler process

[BurningToad]

I don’t really have anything to help you, other than we also run into this problem occasionally. Seems to come and go. Sometimes it works fine the next build, sometimes we get many builds in a row with this issue…

[vovkas]

I have consistently repeated this problem.

[vovkas]

TeamCity Support: try to run the TeamCity agent in the same console, not as a service
It is solve my problem.

[hogwash]

Yep I’ve seen the same issue with Jenkins. Build agents work ok, but running jobs via the server service causes this issue. Because we want to be able to run jobs on the same machine that the server is installed, we just set the # of executors to 0 and created a build agent running on the same machine.

[amynox]

@vovkas

TeamCity Support: try to run the TeamCity agent in the same console, not as a service
It is solve my problem.

Hi,

I’m facing the same issue.

I installed TeamCity agent on the same machine as a server and start everything on the same user account (my user account on windows) and both are not running on windows service account but i still get the same error.

Failed to get socket connection from UnityShaderCompiler.exe shader compiler!

Can you give more detail how did you fix this issue ?

Thanks

[LukeFireproof]

@amynox @vovkas Can you explain how you fixed this issue as I don’t really understand?

[XDura]

Hi having the same issue in 2018.3.6f1.

This is the response I got from JetBrains.

In terms of switching from service to console, we don’t have a specific guide, as this is mostly a windows specific issue, and not in itself related to TeamCity.

It would seem like shaders compiling requires access to UI features, and services don’t have access to those features in Windows at all. The way to get around this is to set the build agent to start automatically with a user session instead, then start that user session. This can be done remotely or locally, it doesn’t matter, and once this is done, the build agent will be running on a UI-valid session and will be able to access the UI features. How to do this will be different depending on your Windows version. The TeamCity specific steps are here: https://confluence.jetbrains.com/display/TCD18/Setting+up+and+Running+Additional+Build+Agents#SettingupandRunningAdditionalBuildAgents-AutomaticAgentStartunderWindows

Once the agent is running there, it doesn’t matter whether you run it manually, schedule or VCS trigger it. It will run on a user shell and thus will have access to the libraries properly.

Hope this helps.

Have fun!

[XDura]

I think I have it working.

Steps that I had to follow on windows:

Go to the “Teamcity Build Agent” service on windows, change its settings to be manual.
Reboot the pc. Once it starts you will se that the Teamcity server now has 0 agents running, that’s good.

Then go to the teamcity instalation folder and find agent.bat batch file.
Open a cmd instance and cd to that directory (in my case was D:\Teamcity\buildAgent\bin).
run the following command:
agent.bat start

This will startup the agent and after a bit you will se the agent in the teamcity web interface.
Then everything in the build process works well because the agent is not runing as a service.

The idea is that you can trigger that “agent.bat start” on windows startup and then everything should work as the normal teamcity setup.

Cheers,

[zhutianlun810]

@XDura

I think I have it working.

Steps that I had to follow on windows:

Go to the “Teamcity Build Agent” service on windows, change its settings to be manual.
Reboot the pc. Once it starts you will se that the Teamcity server now has 0 agents running, that’s good.

Then go to the teamcity instalation folder and find agent.bat batch file.
Open a cmd instance and cd to that directory (in my case was D:\Teamcity\buildAgent\bin).
run the following command:
agent.bat start

This will startup the agent and after a bit you will se the agent in the teamcity web interface.
Then everything in the build process works well because the agent is not runing as a service.

The idea is that you can trigger that “agent.bat start” on windows startup and then everything should work as the normal teamcity setup.

Cheers,

Hello, I am confused on “change its settings to be manual”. What does it mean?