You are viewing the documentation of TeamCity 2018.x, which is not the most recently released version of TeamCity.
View this page in the latest documentation or refer to the listing to choose the documentation corresponding to your TeamCity version.


Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  1. Run TeamCity agent via console.
  2. Configure the build agent machine not to launch a screensaver locking the desktop.


    Note that there is a Windows limitation to accessing a remote computer via mstsc: the desktop of the remote machine will be locked on RDP disconnect, which will cause issues running tests. The VNC protocol allows you to remote control another machine without locking it.
    To run GUI tests and be able to use RDP, see the workaround below.

  3. Configure the TeamCity agent to start automatically (e.g. configure an automatic user logon on Windows start and then configure the TeamCity agent start (via agent.bat start) on the user logon). 
    For graphical tests the build agent  cannot cannot be started as a service and it is recommended to configure the build agent launch with a 1 minute delay after the user auto-logon, e.g. using the "bin\agent.bat start" command in the task scheduler and configuring the delay there.


For more investigation steps, see the Common Problems page.

Back to top

java.lang.OutOfMemoryError: unable to create new native thread error

If your TeamCity server is running on SUSE® Linux Enterprise (or using systemd Daemon), the java.lang.OutOfMemoryError: unable to create new native thread error may be caused by the cgroup process number controller feature limiting the number of processes and the amount of threads in a cgroup to 512 by default.

Increasing the limit (e.g. to 4096) on the TeamCity server should solve the issue.

See also this external posting.

Back to top

Clearing Browser Caсhes

There is a web UI-related issue which some our users have encountered (and it cannot be reproduced on other computers) which is tied to the cached versions of content. If you have come across such problem, make sure your browser does not use cached versions of content by clearing browser caches.

Back to top

Logging with Log4j in Your Tests


  • Use Log4j 1.2.12
  • For Log4j 1.2.13+, add the "Follow=true" parameter for the console appender used in Log4j configuration:

    Code Block
    <appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
      <param name="Follow" value="true"/>

Back to top

Agent Service Can Exit on User Logout under Windows x64

The used version of Java Service Wrapper does not fully support Windows 64 and this causes agent launcher process to be killed on user logout. The agent itself will be function until the next restart (server upgrade or agent properties change).

Back to top

Failed Build Can be Reported as a Successful One With Maven 2.0.7


Code Block
if "%OS%"=="Windows_NT" @endlocal

Back to top

Conflicting Software

Most common indicators of conflicting software are errors like "Access is denied", "Permission denied" or java.io.FileNotFoundException mentioning the file that is present and is writable by the user the agent/build runs under.
Also, certain software running in background (like antiviruses) can significantly slow down build agent operations like sources checkout, artifact publishing or even build running.


  •   use port 80 on the system so you might not be able to use TeamCity server using default 80 port.
  •   corrupt layout of pages displayed in Internet Explorer. Internet Explorer Skype plugin is to blame. (TW-13052).

Back to top

Subversion issues

svn: E175002: Received fatal alert: bad_record_mac


Anyway, upgrading the JVM used to the latest available version is recommended.

Back to top

NUnit 2.4.6 Performance

Due to an issue in NUnit 2.4.6, its performance may be slower than NUnit 2.4.1. For additional information, please refer to the corresponding issue in our issue tracker: TW-4709

Back to top

StarTeam Performance

Using StarTeam SDK 9.0 instead of StarTeam SDK 9.3 on the TeamCity server can significantly improve VCS performance when there is a slow connection between TeamCity and StarTeam servers.

Back to top

Perforce 2009.2 Performance on Windows


Please make sure you use the latest update for JDK 1.Java 8 installation available for your platform (e.g. Oracle JDK download OpenJDK 8 by AdoptOpenJDK).

Back to top



If other web applications are available via the same hostname, a session cookie conflict can occur. This usually is visible via random user logouts or losing session-level data. (e.g. TW-12654). To resolve this, you can use different host names when accessing the applications.

Back to top

The Server Does Not Start Claiming the Database is in Use


  • MySQL: restart the MySQL server and then start TeamCity again.
  • PostgreSQL, Oracle, MS SQL: kill the connections from the incorrectly shut down TeamCity, and then start TeamCity again.
  • Internal database (HSQL): remove the buildserver.lck file from the TeamCity Data Directory\system directory, and then start TeamCity again.

Back to top

Slow download from TeamCity server


  • is set to too small value
  • is left uncofigured unconfigured and so defaults to 30000000 bytes (<30 Mb)

So any aritfact artifact larger than maxAllowedContentLength is discarded by IIS
Check the settings value and try to rerun your build


Windows Docker containers

  • Currently, they do not support Since Windows 10 version 1803 with KB4340917 it's possible to use port mapping from containers to localhost, so the -p option does not have any effect for localhost.  However, . For previous Windows versions it works for the non-localhost IP address associated with this machine and you can access a running application via the machine's hostname or determine the IP address via the ipconfig command. Note that the netstat -an command may not show that the port is open on any IP address, while in fact it can work. This is also a known problem of Docker on Windows.

  • On Windows 10, the memory allocated per container is 1GB by default. To increase this value, use the following memory options:

    Code Block
    docker run ... -m 2GB -e TEAMCITY_SERVER_MEM_OPTS="-Xmx2g -XX:ReservedCodeCacheSize=350m"


  • When starting a TeamCity server from a Windows Docker image, make sure to grant Authenticated Users Full control over the directories used as volumes. See the related issue.

  • When starting a Windows Docker container with the directory C:/BuildAgent/work mapped as a volume to the container host, Git for Windows fails with a following error: 
    "Invalid path '/ContainerMappedDirectories': No such file or directory". The workaround is not to add "C:/BuildAgent/work" as a volume.

To analyze the script output, please refer to the following documents. If it shows that there are problems with the container network subsystem, try resetting it using the cleanup scripts.

More details on troubleshooting Docker for Windows are available in the Docker and Microsoft documentation.



Information about installed Docker server OS on Windows missing on Agent

On Windows 10, the Docker server depends on Hyper-V service and its start may take a significant amount of time.
To resolve the issue, configure the TCBuildAgent Windows service to depend on the Docker for Windows Service, "com.docker.service" by default.

Linux Docker Containers under Windows

Since TeamCity 2017.2, the Docker Wrapper works on Windows when Windows-based containers are started.

If a Linux container is started on a Windows machine, TeamCity displays the error message "Starting Linux Docker containers under Windows is not supported. To avoid this problem, add the ‘teamcity.agent.jvm.os.name does not contain Windows’ agent requiremementrequirement.

If you need to support a use case when the Docker wrapper runs Linux containers under Windows platform, please vote for /comment on TW-51820.


Problems with local time in Windows containers

When using Windows Docker containers, there is an issue with incorrect time in Windows containers when system time in container goes out of sync with the time on the host machine. It could cause problems in integrations where response time is significant (e.g. OAuth tokens).

To address it, upgrade your host machine to Windows Server 2019 / Windows 10 1809 and use TeamCity docker images compatible with Windows containers 1809.

"Access is denied" or "Access to the path is denied" problem on container start

When docker is starting Windows containers with process isolation, it's using the SERVICE user account which lacks the write access to directory with docker volumes. To resolve it, grant the "Full control" permission to the SERVICE user for the "%PROGRAMDATA%\docker\volumes" directory.