Known Issues
This page contains a list of workarounds for known issues in TeamCity.
To see issues specific to particular versions of TeamCity, go to the respective section.
Incompatibility with JDK 8 update 242+
TeamCity versions up to 2019.2.1 running under JDK 8u242+ can report java.lang.NoClassDefFoundError: Could not initialize class XXX errors, for example, on Git operations or Windows domain authentication operations.
Until TeamCity 2019.2.2 is released, it is recommended to use Java 8u232 version for TeamCity server.
Agent running as Windows Service Limitations
When a TeamCity build agent is installed as a Windows service, there may appear various "Permission denied" or "Access denied" errors during the build process, see details below.
Security-related issues
The user account used by the service is required to have sufficient permissions to perform the build and manage the service. If you run the TeamCity agent service under the SYSTEM account, do the following:
Change SYSTEM for a usual user account with necessary permissions granted.
Restart the service.
Windows service limitations
As a Windows service, the TeamCity agent and the build processes are not able to access network shares and mapped drives.
To overcome these restrictions, run TeamCity agent via console.
Issues with automated GUI and browser testing
These problems include errors running tests headless, issues with the interaction of the TeamCity agent with the Windows desktop, and so on.
To resolve / avoid these:
Run TeamCity agent via console.
Configure the build agent machine not to launch a screensaver locking the desktop.
Configure the TeamCity agent to start automatically (for example, 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 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.
Running automated GUI tests and using RDP
RDP uses its own video driver overriding the one from the machine's video card for the session. Redirecting the session to console will unload the Windows graphical drivers. This can be done by adding the following step to your build configuration prior to your tests (the example below is for PowerShell, but other languages (DOS, Python) can be used too):
where quser [current username] lists all the connections to that machine for the user, either console or graphical.
The one listed as rdp-tcp#* is the remote desktop connection which can be redirected to the console using tscon [connection id] /dest:console.
Issues with .NET Selenium
When a TeamCity agent is started as a Windows service and automated tests for .NET applications use Selenium WebDriver, the tests may fail due to browser drivers limitations. As a solution, consider starting the agent manually.
Early start of the service before other resources are initialized
To handle this, consider using the Automatic (Delayed Start) option of the service settings or configure service dependencies.
For more investigation steps, see the Common Problems page.
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.
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.
Logging with Log4j in Your Tests
If you use Log4j logging in your tests, in some cases you may miss the Log4j output from your logs. In such cases do the following:
Use Log4j 1.2.12
For Log4j 1.2.13+, add the
"Follow=true"parameter for the console appender used in Log4j configuration:<appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender"> <param name="Follow" value="true"/> </appender>
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).
Failed Build Can be Reported as a Successful One With Maven 2.0.7
This is a known bug in this version of Maven. Consider using any later version.
In case it's not possible, you can patch mvn.bat yourself by replacing the fragment at line 148 of mvn.bat:
with the following one:
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 the background (like antivirus) can significantly slow down such build agent operations as sources checkout, artifact publishing or even build running.
Certain antivirus software like Kaspersky Internet Security can result in Java process crashes or other misbehavior like inability to access files. For example, see this issue.
ESET antivirus can also slow down Ant/IntelliJ IDEA project builds a great deal (slowing down TCP connections to localhost on an agent).
If you run antivirus on the TeamCity server or agent machines and get disk access errors or experience degraded performance, you may consider temporarily disabling the antivirus software before investigating the issue and reporting it to JetBrains. Note that disabling the antivirus can make your setup more vulnerable to potential external attacks – ensure you take proper security measures before doing this.
It is recommended to exclude entire TeamCity server home and TeamCity Data Directory from the background checks and perform periodical checks there in the well-known maintenance window so that those do not affect server performance much. On TeamCity agent, it is recommended to exclude TeamCity agent home from the background checks.
There might be problems with the Windows Indexing Service, so disable various indexing services. See the related issue for more details. Windows System Restore Feature might also need disabling.
Do not install software with background indexing like WinCVS, TortoiseCVS, TortoiseSVN, and other Tortoise* products. This applies to server and also to agents if you use agent-side checkout.
Skype software is known to:
use port 80 on the system so you might not be able to utilize a TeamCity server on the default port 80.
corrupt layout of pages displayed in Internet Explorer. Internet Explorer Skype plugin is to blame. (TW-13052 ).
Subversion issues
svn: E175002: Received fatal alert: bad_record_mac
Add a system property -Dsvnkit.http.sslProtocols=SSLv3,TLS on the build server (see Configuring TeamCity Server Startup Properties ).
If you use checkout on agent, add this property on build agent as well.
Subversion-related JVM Crashes
If JVM crashes while executing SVN-related code (e.g. under org.tmatesoft.svn package), you can try to disable it using one of the options:
Passing
-Dsvnkit.useJNA=falseJVM option to the crashing process (server or agent)Making NTLM support less prioritative by passing the
-Dsvnkit.http.methods=Basic,Digest,NTLMJVM option.
Anyway, upgrading the JVM used to the latest available version is recommended.
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, refer to the corresponding issue in our issue tracker: TW-4709
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.
Perforce 2009.2 Performance on Windows
If you run Perforce 2009.2 on Windows you may experience significant slow down. This is an issue with P4 server running on Windows. Refer to corresponding section in Perforce documentation.
Wrong times for build scheduled triggering (Timezone issues)
Make sure you use the latest update for Java 8 installation available for your platform (e.g. OpenJDK 8 by Amazon Corretto ).
Upgrading IntelliJ IDEA May Affect Active Pre-Tested Commits
Before you upgrade to IntelliJ IDEA X (or other IntelliJ X platform products), make sure you do not have active pre-tested commits, otherwise they will not be able to be committed after upgrade. This is only relevant if you use directory-based IDEA project (project files are stored under .idea directory).
Other Java Applications Running on the Same Server
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.
The Server Does Not Start Claiming the Database is in Use
Only a single TeamCity server can work with one database, which is checked on the TeamCity server start.
" The Database is in Use" error on the start-up is reported in either of the following cases:
An attempt to start more than one TeamCity server connected to the same database
A second TeamCity instance detected
The internal HSQL database is being used by another application
The error is most probably caused by the fact that there is another running TeamCity installation which is connected to the same database. Сheck that the database properties are correct and there is no other TeamCity server using the same database.
In TeamCity 8.0 and earlier, if all the settings are correct, the error can occur when the TeamCity server or the database server has been shut down incorrectly. The resolution depends on the database type:
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.lckfile from the < TeamCity Home >\system directory, and then start TeamCity again.
Slow download from TeamCity server
If you experience slow speed when downloading artifacts from TeamCity, try checking the speed on the server machine, downloading from localhost. If the speed is OK for the localhost, the issue can be in the network configuration or OS/hardware settings when combined with TeamCity (Tomcat) settings.
Make sure < TeamCity Home >\conf\server.xml file corresponds to the file included in TeamCity distribution (can be checked in .tar.gz distribution). If you have the following "Connector" node (ports numbers can be different):
change it to:
and restart TeamCity server.
If this does not help with the download speed, to investigate the case, you might need to find an administrator with appropriate network-related issues investigation skills to look into the case.
Failure to publish artifacts to server behind IIS reverse proxy
This problem is only relevant to configurations that involve an IIS reverse proxy between the build server and agents. Sometimes a build agent can be found in infinite loop trying to publish build artifacts to the server. The build log looks like this:
meanwhile, teamcity-agent.log is filled with 404 responses from IIS:
The most common cause for this is maxAllowedContentLength setting (in IIS) is either
set to too small value, or
left unconfigured and so defaults to 30000000 bytes (<30 Mb)
So any artifact larger than maxAllowedContentLength is discarded by IISCheck the settings value and try to rerun your build
Prerelease packages are not visible in the TeamCity NuGet feed
Problem: Prerelease packages are not visible in the TeamCity NuGet feed.
Cause: NuGet clients prior to version 3 fail to list prerelease packages if the package version violates the required format.
Solution: Delete build artifacts whose versions violate the required format.
Packages indexing is slow in TeamCity NuGet feed
Problem: After TeamCity server host machine move or upgrade to the TeamCity 2017.1 build metadata can be reset.
Cause: The TeamCity NuGet feed relies on build metadata, and packages re-indexing can take a lot of time depending on the number of packages and the idle time of the TeamCity server.
Solution: To speed up build metadata re-indexing, specify the following internal properties:
To check the metadata indexing progress, look for lines similar to the ones below in the teamcity-server.log file:
After reindexing is complete, remove these internal properties.
SSL problems when connecting to HTTPS from TeamCity (handshake alert: unrecognized_name)
This problem may happen when changing JVM from 1.6 to 1.7 and connecting some incorrectly configured HTTPS servers. The problem and workaround for it are described in this issue.
SSL problems connecting MS SQL Server and TeamCity
Since MS SQL Server always establishes an SSL connection between the JDBC client (the TeamCity application) and the server, connection problems may occur (SQL exception: Connection reset ).
Affected MS SQL versions
Any version prior to the ones listed below:
SQL Server 2012 Production version and later
SQL Server 2008 Service Pack 3 Cumulative Update 4
SQL Server 2008R2 Service Pack 1 Cumulative Update 6
SQL Server 2008R2 Service Pack 2
Cause: The problem is caused by the Java 1.6 update addressing this security vulnerability.
Solution: Microsoft SQL Server upgrade is recommended.
Workarounds: If Microsoft SQL Server upgrade is not possible for some reason, TeamCity can be set up to use older Microsoft SQL Server versions with the database connection still SSL- or TLS-encrypted.
Continue using a block cipher such as
AES_128_CBCor3DES_EDE_CBC, but disable CBC protection via-Djsse.enableCBCProtection=falseJava command-line option (that can be added toTEAMCITY_SERVER_OPTSenvironment variable, as described here.
Thejsse.enableCBCProtectionJava system property is also available in all OpenJDK 8 versions and IBM J9 8.0.0 SR1 and later.
Secure connection between TeamCity and Microsoft SQL Server would be stable but still vulnerable to CVE-2011-3389 also known as BEAST.Fall back to a stream cipher (which is not susceptible to BEAST) such as
RC4_128. This will render the connection vulnerable to CVE-2015-2808.Consider running with the temporarily disabled antivirus software, but ensure it doesn't compromise the security of your setup. For example, see this issue.
Distorted Configuration Window During Agent Reinstallation
When installing a TeamCity agent via a Windows agent installer on top of the already installed agent with a different version of Java, the "Configure Build Agent Properties" installation window might appear distorted.
This issue has been fixed in TeamCity 2019.1.5.
To workaround this issue without upgrading to 2019.1.5, uninstall the previously installed agent version before installing a new agent into the same directory.
To uninstall the agent, invoke Uninstall.exe in the Agent Home Directory, clear all the "Remove..." checkboxes to keep the agent logs and configuration, and click Uninstall. After the successful uninstallation, you can proceed with installing the new agent version via the agent installer.
Windows Docker Containers
Problems common to TeamCity Docker container images.
Since Windows 10 version 1803 with KB4340917 it's possible to use port mapping from containers to localhost. 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
ipconfigcommand. Note that thenetstat -ancommand 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:
docker run ... -m 2GB -e TEAMCITY_SERVER_MEM_OPTS="-Xmx2g -XX:ReservedCodeCacheSize=350m"On Windows 10 containers work via Hyper-V and may experience problems with network and other subsystems. To diagnose these problems, execute the following PowerShell script:
Invoke-WebRequest https://aka.ms/Debug-ContainerHost.ps1 -UseBasicParsing | Invoke-ExpressionWhen starting a TeamCity server from a Windows Docker image, make sure to grant "Authenticated Users" the Full Control over the directories used as volumes. See the related issue.
When starting a Windows Docker container with the directory
C:/BuildAgent/workmapped 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 addC:/BuildAgent/workas a volume.
To analyze the script output, refer to the following documents. If it shows that there are problems with the container network subsystem, try resetting it using the clean-up 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 requirement.
If you need to support a use case when the Docker wrapper runs Linux containers under Windows platform, vote for the related comment in TW-51820.
Problems with a local time in Windows containers
When using Windows Docker containers, there is an issue with incorrect time in Windows containers when the system time in a container goes out of sync with the time on the host machine. It could cause problems in integrations where response time is significant (for example, 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 uses a Windows user account which lacks the write access to the directory with Docker volumes. In this case, build agents may fail to start due to the "Access to the path is denied" or "Access is denied" error.
To resolve this issue, grant the "Full control" permission to the "Authenticated Users" group for the %PROGRAMDATA%\docker\volumes directory.
dotCover known issues
dotCover does not support Windows Nano Server
If you try to run dotCover on an agent with the Nano Server OS, the build will fail with an exit error "Process exited with code -1073741515 ". Instead of Nano Server, consider using Server Core which is an alternative minimal installation option of Windows Server.
dotCover does not support сoverage statistics for msbuild
dotCover does not support collection of coverage statistics for the dotnet msbuild /t:vstest command – use dotnet test instead.
Code coverage configuration using Test Settings is deprecated
Code coverage configuration using Test Settings is deprecated in dotCover. Read more in Microsoft documentation.
If you use .testsettings files, TeamCity will display a warning message in the log. To prevent this issue, we suggest that you use .runsettings files instead. If, for some reason, you have to continue using .testsettings, install dotCover version 2019.1.x or earlier on TeamCity agents, as described here.
Xcode 10 is unable to clean artifacts in custom output directory
If you use a custom output directory for Xcode, note that on upgrading to Xcode 10, TeamCity builds with the Xcode Project build runner might fail with the error: "Could not delete <directory> because it was not created by the build system and it is not a subfolder of derived data."
This is caused by the following Xcode 10 known issue:
When performing xcodebuild clean on a project that uses a customized build location outside the derived data directory, and that has older build products produced prior to Xcode 10, Xcode might report an error indicating that it won't delete directories not created by the new build system. (40427159)
See Xcode documentation for details.
To resolve this issue, we suggest that you use Xcode 11 instead. To workaround this issue in Xcode 10, you can either clean the output directory manually or try using the previous build system by passing -UseNewBuildSystem=NO to command line parameters.
Cross-server Projects pop-up menu may not work in latest browsers
Due to the recent updates in the SameSite cookie support, the Projects pop-up menu may not display cross-server projects in some latest web browsers (see more details for Chrome Platform).
If you cannot access the cross-server Projects menu, you can try to temporarily workaround this issue by changing your browser settings:
In Google Chrome, open the
chrome://flagspage and disable the "SameSite by default cookies" option.In Mozilla Firefox, open the
about:configpage and disable thenetwork.cookie.sameSite.laxByDefaultoption.In Safari, go to Preferences | Privacy and disable the "Prevent cross-site tracking" option.
This problem will be resolved in the TeamCity 2020.1.5 update. See the related issue for more details.
.NET runner known issues
.NET runner is not compatible with obsolete external .NET CLI Support plugin
The reworked .NET build runner is not compatible with the obsolete external plugin .NET CLI Support (used in versions 2017.1 and earlier). If the obsolete plugin is installed on your server, you will get the Error creating bean with name "jetbrains.buildServer.dotnet.DotnetRunnerRunType" after updating to TeamCity 2020.1. To solve this issue, please uninstall the obsolete plugin from your server.
Note that all the existing .NET CLI Support build steps are automatically switched to the new .NET runner on updating to TeamCity 2019.2.3 or later. For more information, refer to our upgrade notes.
Cannot create an instance of the logger when using early Visual Studio 2017 build
In rare cases, if an early build of Visual Studio 2017 is installed on your build agent, you might get the "Cannot create an instance of the logger" error when running the .NET build step. This might be caused by the logger's incompatibility with the framework version being used.
To workaround this problem, you can upgrade Visual Studio 2017 to the latest build or, alternatively, install any later version of .NET Framework.
Issues per TeamCity versions
2020.1.3 Known Issues
Hanging Re-run Build dialog for chained builds with no snapshot dependencies
If you try to re-run a build that has an artifact dependency but not snapshot dependency on another build, the Re-run build dialog will not load.
This issue will be fixed in TeamCity 2020.1.4. To workaround it in version 2020.1.3, follow this instruction.
2020.1.1 Known Issues
Missing Expand button for project list
In the TeamCity classic UI, the Projects link in the header is missing the expand button.
To workaround this issue, please follow the instruction described here.
2020.1 Known Issues
Jira Cloud Integration build feature requires specific VCS URL
The Jira Cloud API, used by the new Jira Cloud integration build feature, requires sending a server URL in a specific format. Because of that, the build feature does not support VCSs like Perforce, TFS, and SVN out of the box.
To address this issue, we have updated the responsible plugin, and you can find it attached to the related issue in our tracker. Please download the fixed plugin and install it as described here.
The bundled Jira Cloud plugin will be automatically updated with this fix in our next release.
The feature might also fail to resolve some Git paths that do not correspond to the format expected by the Jira Cloud API. In this case, you can either change the URL manually (for example, from git@<vcs_address>:<workspace_ID>/<repo_name>.git to ssh://git@<vcs_address>/<workspace_ID>/<repo_name>.git) or download the fixed plugin as described above.
Jira Cloud Integration feature does not support legacy Jira Cloud domain
Currently, the new Jira Cloud integration build feature supports only atlassian.net domains. We have added the support of the legacy jira.com domain in the fixed version of the responsible plugin. If your Jira Cloud server resides on the jira.com domain, you can download the plugin, attached to the related issue, and install it as described here.
The bundled Jira Cloud plugin will be automatically updated with this fix in our next release.
Bad Redirect URI error when authenticating in Slack
To be able to sign in to Slack from TeamCity, you need to specify all the possible URIs of the TeamCity server as Redirect URLs in the Slack app's settings.
If you use nginx to set up TeamCity behind a proxy server, you might still get the bad_redirect_uri error when trying to establish a connection with Slack. This error is caused by the mismatch between the nginx and Tomcat configuration.
To workaround this issue, download the fixed plugin, attached to the related issue, and install it as described here. Alternatively, you can try updating the Tomcat settings.
The bundled Slack plugin will be automatically updated with this fix in our next release.
Problems with built-in authentication in upgraded 2020.1 EAP1 installations
If you had installed the 2020.1 EAP1 build in terms of our Early Access Program, you might experience problems with signing in to TeamCity via the built-in authentication. This issue might occur after upgrading from any 2020.1 EAP version (EAP1 or any later version to which it was upgraded) to the release 2020.1 build.
To workaround this problem, please send the following query to the TeamCity database:
2019.2.3 Known Issues
Handshake failure on establishing SSL connection
Some users might get the "Received fatal alert: handshake_failure" error when the TeamCity server attempts to establish an SSL connection. The problem is caused by the broken sunec.dll in JRE bundled with TeamCity 2019.2.3.
To check if this problem has affected your installation, open the <TeamCity_installation_directory>/jre/bin/sunec.dll file. If there is a JSON code in this file, your server is affected. To work around the problem, please follow the steps described in the related issue.
NuGet feed credentials for external repositories do not work with .NET runner
The .NET build runner currently does not support using NuGet feed credentials for authentication in external repositories.
To work around this issue in TeamCity 2019.2.3, download the patched .NET Packages Support plugin and install it as any other additional plugin. The bundled .NET Packages Support plugin will be automatically updated with the fix in our next release.
AWS region us-east-1 cannot be set in S3 artifact storage settings
If the us-east-1 region is selected in S3 artifact storage settings, it will be automatically reset to another available region on saving the settings. This is caused by the incorrect bucket location returned for us-east-1 from AWS.
To work around this issue in TeamCity 2019.2.3, download the patched TeamCity S3 Storage plugin and install it as any other additional plugin. The bundled S3 Storage plugin will be automatically updated with the fix in our next release.
2019.2 Known Issues
Potential issues with restoring NuGet packages in .NET projects
TeamCity might fail to restore NuGet packages if a build comprises at least one .NET CLI (dotnet) step and an MSBuild or Visual Studio (sln) build step (or both).
This issue is caused by the difference in paths to cache directories between these build runners.
The MSBuild and Visual Studio (sln) runners use the default path to the NuGet global cache while the .NET CLI (dotnet) runner redefines this path (for example, when run inside a Docker container).
The recommended workaround is to use the NuGet Installer build runner instead of the .NET CLI (dotnet) runner for restoring packages.
2019.1.4 Known Issues
Unavailable Default Credential Provider Chain option for Amazon ECR
This issue has been fixed in TeamCity 2019.1.5.
Due to recent changes in our Docker Support plugin, the "Default credential provider chain" option becomes unavailable in the Amazon ECR connection settings.
If this option was previously enabled in some ECR connection and you make any changes to this connection, the state of this option will be automatically set to false. When any build will try to use this connection, it will fail to start with the "Access key cannot be null" error.
To workaround this problem without upgrading to 2019.1.5, download the fixed Docker Support plugin from the related issue and upload it on the Server Administration | Plugins List page.
Missing packages in NuGet feed
This issue has been fixed in TeamCity 2019.1.5.
In certain cases, when a build is supposed to create and publish several NuGet packages to a NuGet feed, and the package indexing is enabled, some packages might not be published to the feed. This problem is caused by recent changes in NuGet Packages Indexer.
To workaround this problem without upgrading to 2019.1.5, download the fixed NuGet Support plugin from the related issue and upload it on the Server Administration | Plugins List page.