在“将文件复制到放置位置”步骤后诊断 TFS 构建挂起

Posted 2023-03-22

【中文标题】在“将文件复制到放置位置”步骤后诊断 TFS 构建挂起

【英文标题】：Diagnosing TFS Build Hanging after 'Copy Files to Drop Location' step

【发布时间】：2014-02-27 14:52:27

【问题描述】：

我需要一些关于如何诊断悬挂构建的建议。这只是在过去一两周内发生的，我有充分的理由怀疑这是我最近所做的事情，而不仅仅是巧合

设置

TFS 2013 4 台机器设置 - 2 个应用层（正在弃用其中一个）、1 个 sql 服务器、1 个运行 2 个代理的构建服务器。 构建控制器与作业代理一起在第二个应用层上运行 第一个应用层正在为网站提供服务（尽管该机器将很快关闭，并且随着机器变旧，所有内容都将传递到第二个应用层）

症状

所有执行的构建（似乎与哪个构建过程模板无关）永远不会被标记为完成，最后一步似乎总是相同的步骤“将文件复制到放置位置”/“工作区并将文件复制到放置位置” ”/”Copy Binaries to drop，Reset the environment”（在每个构建模板中命名不同） 文件似乎已成功删除到构建放置文件夹中 查看任务管理器，似乎构建服务器上的所有构建过程都已退出（仅 TFSBuildServiceHost 构建在执行时显示其正常步骤/日志记录 主要应用层在事件日志中有相关警告（请参阅下面的警告）

最近的变化

在构建服务器上安装了 Xamarin android/ios 为 Job Agent、Message Queue 和 Web 服务安装了一些自定义构建的插件（多年来一直使用它们，但由于应用层迁移，它们在最近几周被禁用） 安装了 Tiago 的任务板增强器（又用了很长时间，最近才被禁用） 大约一个月前，我们添加了第二个应用层并将 sql 移到另一台机器上

我的尝试

重新启动应用层和构建服务器 卸载 Xamarin（尽管我怀疑某些部件仍在浮动，因为 Bonjour 服务似乎仍在安装） 删除自定义插件 在其中一个版本上直接启用了日志记录诊断 - 似乎没有什么特别感兴趣的问题出现 运行最佳实践分析器（没有什么异常出现） 多个构建过程模板（defaulttemplate、defaulttemplate.11.1、tfvctemplate.12.xaml） 多个构建定义 检查了 AppTiers 和 Build server 的事件日志

Team Foundation 服务主机请求监视器检测到 以下条件：日期（UTC）：2014 年 3 月 2 日凌晨 12:54:06 机器： CODEBASE 应用领域：/LM/W3SVC/1/ROOT/tfs-1-130357641583538280 程序集：Microsoft.TeamFoundation.Framework.Server，版本=12.0.0.0， 文化=中立，PublicKeyToken=b03f5f7f11d50a3a； v4.0.30319 服务 主机：0dc282b5-59a8-4941-b541-a4f7d314cd0f 进程详情：进程 名称：w3wp 进程 ID：2508 线程 ID：2504

详细信息：对服务主机 XXXX 的请求已在执行 37 秒，超过 30 的警告阈值。 请求详细信息：请求上下文详细信息 网址：/tfs/XXXX/XXXX/_api/_build/stop?__v=4 方法：ApiBuild.stop 参数：uri = vstfs:///Build/Build/34064 用户代理：Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (Khtml, like Gecko) Chrome/32.0.1700.102 Safari/537.36 唯一标识：00000000-0000-0000-0000-000000000000

Team Foundation 服务主机请求监视器检测到 以下条件：日期（UTC）：30/01/2014 11:10:01 p.m.机器： CODEBASE 应用领域：/LM/W3SVC/1/ROOT/tfs-1-130355232548668648 程序集：Microsoft.TeamFoundation.Framework.Server，版本=12.0.0.0， 文化=中立，PublicKeyToken=b03f5f7f11d50a3a； v4.0.30319 服务 主机：0dc282b5-59a8-4941-b541-a4f7d314cd0f 进程详情：进程 名称：w3wp 进程 ID：70320 线程 ID：14540

详细信息：对服务主机 XXXX 的请求已在执行 37 秒，超过 30 的警告阈值。 请求详细信息：请求上下文详细信息 网址：/tfs/XXXX/Build/v4.0/BuildService.asmx 方法：停止构建 参数：uris[0] = vstfs:///Build/Build/34051 uris = Count = 1 用户代理：Team Foundation（devenv.exe，12.0.21005.1，Premium，SKU：16） 唯一 ID：4d2d3213-fd41-4c4d-8ab0-b87619c96a42

Team Foundation 服务主机请求监视器检测到 以下条件：日期（UTC）：2014 年 1 月 31 日凌晨 3:14:17 机器： CODEBASE 应用领域：/LM/W3SVC/1/ROOT/tfs-1-130355232548668648 程序集：Microsoft.TeamFoundation.Framework.Server，版本=12.0.0.0， 文化=中立，PublicKeyToken=b03f5f7f11d50a3a； v4.0.30319 服务 主机：进程详细信息：进程名称：w3wp 进程 ID：70320 线程 ID：14540

详细消息：没有对服务主机 XXXX 的活动请求 超过 30 的警告阈值。

一个快速的谷歌建议增加 tfs 注册表中的超时 (http://xavierdilipkumar.com/post/2013/07/04/TFS-event-7005-and-7006-warning.aspx) 我已经尝试过了，它似乎没有改变任何东西。

【问题讨论】：

重新阅读这些警告后，似乎它们与我停止从 Web 前端构建有关，不一定与问题直接相关。

有点相关，但试一试：geekswithblogs.net/kjones/Default.aspx

原来我们的解决方法是向主机文件添加一个条目，将 SharePoint URL 指向 127.0.0.1（环回地址）。我们已经为我们启动的其他三个 SharePoint Web 应用程序配置了这个。我们忽略了对最近才投入生产的新 Web 应用程序执行此操作。

@Isaiah4110 不，我很确定这完全不相关。

我知道它们完全不相关，但我所说的是修复的性质。无论如何，在您添加第二个应用程序层之前，构建控制器在哪里运行？运行构建控制器的用户是否发生了变化？它是在构建控制器移动到 2 应用层后开始发生的吗

【参考方案1】：

你能在 tfs bs 日志中查看吗

Event Viewer -> Applications and Services Logs -> Microsoft -> Team Foundation Server -> Build-Services -> Operational

这些超时通常与权限有关。您应该查找 TF215106 访问被拒绝事件。尽管文件似乎在那里，但它们都是当前日期还是有一些具有不同（较旧）日期？当文件丢失发生时，它们是否会发生任何警报/步骤？

除此之外，它可能会超时，因为其中一个依赖项正在被另一个服务使用。

【讨论】：

这些日志中有一个有趣的错误。构建机器与消息队列 tfsmq://buildservicehost-1/ 的连接丢失。原因：TF400324：Team Foundation 服务无法从服务器 xxxx 获得技术信息（针对管理员）：底层连接已关闭：接收时出现意外错误。

你试过清除 tfs 中每一层的缓存吗？我认为它是 \%programfiles%\\Application Tier\Web Services\*_data 文件。不过备份它们。

【参考方案2】：

您可以启动Sysinternals Process Monitor 来查看进程实际退出的时间以及它们在做什么（进程监视器监控“实时文件系统、注册表和进程/线程活动”）。

【参考方案3】：

最好的做法是致电 Microsoft 支持并提出服务请求。确保它获得优先级 A - 您的 TFS 生产环境无法正常工作 - 并准备好为他们提供支持和访问权限。

日志中的唯一提示是对 ApiBuild.stop 的调用。它表明构建工作流程已完成，因此托管它的代码正在回调 AT 以标记构建完成。由于您之前的调用没有警告，这可能是数据库级别的一些问题。您可以尝试激活 SQL 跟踪，但这不是一项简单的任务，因为您应该能够将跟踪与工作跟踪进行比较。

祝你好运

【讨论】：

我在发布此消息的同时记录了一张合作伙伴支持票，不幸的是，微软在这种情况下并没有提供太多帮助（我之前得到了他们的大力支持，尽管速度有点慢）。

【参考方案4】：

我不愿意将此标记为答案，因为我不完全确定它为什么起作用。

怀疑构建机器有问题我在全新安装时创建了一个新的构建代理 - 挂起问题仍然存在。

然后我向该机器添加了一个构建控制器，并注意到使用该控制器的新构建将完成。这表明 BA 和 BC 之间或者 BA 和主 AT 之间存在通信问题。

鉴于我们的主 AT 存在其他问题，我们决定将其从图片中删除，我们将 DNS 切换为指向第二个 AT，并禁用旧主 AT 上的所有服务。立即开始完成构建（包括那些被卡住了几天的构建）。

我仍然不知道哪个组件损坏或为什么损坏，特别是因为它在一个月前在此配置中运行良好。我只能假设有另一个我不知道的变化，或者主 AT 的损坏导致了更大的问题。

【参考方案5】：

我们在这里遇到了同样的问题，即使在成功通过所有工作流程阶段后，构建仍然保持打开状态。

我登录到构建机器并注意到构建控制器出于某种原因“正在运行 6 个构建”，即使在 Visual Studio 的队列中根本没有显示任何构建。

重新启动控制器后，下一次构建第一次工作。

只是想让这个作为可能的答案。我还不确定为什么控制器会有这些卡住的构建。

【参考方案6】：

当某个活动尝试在构建日志中记录大量消息（即 CodePlex TFS 构建扩展项目中的 FxCopCmd 活动）时，我遇到了这个问题。

构建代理将成功完成构建，但控制器必须将大量消息咀嚼到构建日志中，并且它默默地崩溃/挂起。

我可以通过导航到 C:\Users\[TfsServiceAccount]\AppData\Local\Temp\BuildAgent\[AgentNumber]\Logs\[BuildNumber]\ActivityLog.xml 来追踪问题。

最后一条构建消息被截断，通过查看内容，我认出了 FxCop 输出。在我的例子中，我只是将构建过程模板中 FxCop 活动的 LogToConsole 参数设置为 False，构建成功完成。

【参考方案7】：

如果构建代理无法连接到端口 9191 上的构建控制器服务器，似乎也会发生这种情况。

可使用 telnet 客户端轻松测试。

似乎我的服务器认为它位于未知网络上，并将防火墙踢到了超速状态。 （我第二次遇到这个问题，不确定这是否是我第一次遇到的原因，但似乎合理）。