Known Issues
This page contains a list of workarounds for known issues in TeamCity.
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.
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.
These problems include errors running tests headless, issues with the interaction of the TeamCity agent with the Windows desktop, and so on.
tip
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.
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.
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):
$sessionInfo=((quser $env:USERNAME | select -Skip 1) -split '\s+')
if ($sessionInfo[1] -like "rdp-tcp*") { tscon $sessionInfo[2] /dest:console }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.
note
An unsupervised computer with a running desktop permanently logged into a user session might be considered a network security threat, as access to it can be difficult to trace. Therefore, it is recommended to run automated GUI and browser tests on a virtual machine isolated from sensitive corporate network resources, e.g. on a machine not included in a Windows domain.
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.
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.
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 (for example, to 4096) on the TeamCity server should solve the issue.
See also this external posting.
There is a web UI-related issue which some 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.
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=trueparameter for the console appender used in Log4j configuration:<appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender"> <param name="Follow" value="true"/> </appender>
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).
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:
:error
set ERROR_CODE=1with the following one:
:error
if "%\OS%"=="Windows_NT" @endlocal
set ERROR_CODE=1Most 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 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.
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 corrupt layout of pages displayed in Internet Explorer. (TW-13052).
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.
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.
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).
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:
[11:15:05]Publishing artifacts
[11:15:05][Publishing artifacts] Collecting files to publish: [toZip/** => artifact.zip]
[11:15:06][Publishing artifacts] Creating archive artifact.zip (9s)
[11:15:06][Creating archive artifact.zip] Creating C:\BuildAgent\temp\buildTmp\ZipPreprocessor2847146024236637664\artifact.zip
[11:15:15][Creating archive artifact.zip] Archive was created, file size 32142324 bytes
[11:15:15][Publishing artifacts] Sending toZip/**
[11:15:25][Publishing artifacts] Sending toZip/**
[11:15:39][Publishing artifacts] Sending toZip/**
[11:15:48][Publishing artifacts] Sending toZip/**
[11:16:01][Publishing artifacts] Sending toZip/**
[11:16:16][Publishing artifacts] Sending toZip/**meanwhile, teamcity-agent.log is filled with 404 responses from IIS:
[2012-08-01 12:04:55,514] WARN - jetbrains.buildServer.AGENT - <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
<title>404 - File or directory not found.</title>
<style type="text/css">
<!--
body{margin:0;font-size:.7em;font-family:Verdana, Arial, Helvetica, sans-serif;background:#EEEEEE;}
fieldset{padding:0 15px 10px 15px;}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
When loading a TeamCity page, you might notice some content missing. Most commonly, build configurations that have finished builds do not display their build histories and appear empty. At the same time, a web browser logs multiple 404 (Not Found) errors.
If this happens for a TeamCity instance running on an IIS server, check the values of the IIS maxQueryStringLength and/or maxQueryString values. These settings limit the maximum length of query strings. If these limits are too low, some of REST requests TeamCity sends to the <server-url>/app/rest/... endpoints may fail.
To resolve this issue, increase these limits in the web.config file of your IIS server. The exact value should depend on your current configuration and the length of your project/configuration IDs. As a general recommendation, set this limit to 4000 characters and gradually raise it if the issue persists.
See also: Request Limits | httpRuntime Element
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 work around 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.
Automatic TeamCity updates may fail to write new version numbers to the related Windows registry key. This causes the standard Windows Add or Remove Programs application to show the version of the initial TeamCity installation that never changes after updates.
To manually update the registry key and set a correct version, follow the instructions on the TeamCity Administration | Updates page to run a PowerShell script shipped with your TeamCity installation:
runas /user: Administrator "powershell -File C:\TeamCity\bin\update-registry-version.ps1"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 collection of coverage statistics for the dotnet msbuild /t:vstest command — use dotnet test instead.
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 work around 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.
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 work around this problem, you can upgrade Visual Studio 2017 to the latest build or, alternatively, install any later version of .NET Framework.
Due to the breaking change introduced by Microsoft in the core System.CommandLine library, .rsp files with commas and (or) semicolons in property values are parsed incorrectly. To ensure this issue does not occur, enclose values of system properties in quotes. If this solution is not applicable to your project, add the teamcity.internal.dotnet.msbuild.parameters.escape configuration parameter and set its value to "true". With this setting enabled, TeamCity automatically wraps values of user-defined properties in quotes.
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.
Problem: NuGet can sometimes skip the recent versions of packages when pulling these packages from the feed.
Cause: NuGet caches the server responses, thus pulling does not detect the most recent changes in the feed.
Solution: To send a new request directly to the server instead of the cache, use the --no-cache parameter in your request.
Earlier versions of the PowerShell runner don't support passing multiline arguments. Since version 2020.1.4, you can enable this support by setting the teamcity.powershell.arguments.multiline=true configuration parameter.
Error while loading VCS changes on the TeamCity server startup might be associated with the enabled cursor-based streaming in MySQL. To prevent this error, try setting the connectionProperties.useCursorFetch property to false in database.properties and restart the server.
See this issue for more details.
In some cases, TeamCity could start builds on old open merge requests in JetBrains Space and pull requests in Bitbucket Cloud. This is reproduced with the following sequence of steps:
Create a new VCS root that connects to a repository with open merge requests. Leave the default branch specification.
Create a build configuration with this VCS root and a VCS trigger.
Remove the branch specification from the VCS root.
Add the Pull Requests build feature to the build configuration.
Disable the Pull Requests feature and then enable it again.
See the related issue for more details.
The Pull Requests build feature could post a wrong build step number to the merge request timeline in JetBrains Space. See the related issue.
Due to more strict repository ownership checks introduced in Git 2.35.2, updating the TeamCity server's Git to this or a newer version may result in malfunctions (for instance, the "fatal: could not read from remote repository" message). Try the following workarounds as temporary solutions:
If your TeamCity server runs on Linux, ensure the volume with the <TeamCity data dir>/system/caches/git directory is mounted under the same user that TeamCity utilizes to access this directory.
If you experience related issues on a TeamCity Server installed or updated via a Windows Docker image, disable the native Git to force the TeamCity server to use JGit instead.
These issues concern the use of native Git for checking out sources to the TeamCity server, effective since version 2022.04.
Switching the server to native Git results in builds failing to authorize in repositories via SSH DSA keys. See the related issue TW-74580.
Native Git via OpenSSH may fail on Windows if the server/agent installation path contains spaces. See the related issue.
TeamCity uses an ssh proxy when connecting via native Git. See the related issue
The regular ZIP format supports archives up to 232 bytes (4 GB) in size. Since builds can produce artifacts that exceed this value, TeamCity compresses artifacts with the ZIP64 format that supports archives as large as 264 bytes (16 exabytes).
If tools that you utilize to unzip TeamCity build artifacts do not support ZIP64 (for example, you may observe header error warnings), add the following configuration parameters to a project (either a <Root project> or a specific project that produces unsupported archives):
teamcity.internal.artifacts.useZip64=Never
teamcity.internal.artifacts.useByteChannelForZip=false