Azure DevOps集成SonarQube构建报错MSB6006 csc.dll退出码137

csc.dll退出码137是Linux环境下进程被系统OOM Killer强制杀掉的标准信号，你碰到的重复构建循环本质是：加了SonarQubePrepare任务后，Sonar会把Roslyn静态分析器注入到编译流程里，csc编译进程内存占用陡增，超过系统单进程内存阈值被强杀，MSBuild检测到编译进程异常退出就会自动重试，才会反复构建同一个项目。之前给Agent池分配16GB总内存没用，是因为Linux默认对单进程、单用户进程的内存占用有单独限制，不是整机内存不够。

按优先级依次测试，90%的同类问题前两个方案就能解决：

• 关闭Sonar的Razor视图分析：从你贴的日志看，报错刚好卡在Razor编译文件迁移步骤，这是SonarQube v5.5扩展的已知高发问题。直接在SonarQubePrepare@5任务里追加参数/d:sonar.cs.razor.analysisEnabled=false，跳过Razor视图的静态扫描，内存占用直接降一半以上。
• 限制MSBuild并行编译数：在DotNetCoreCLI@2构建任务的arguments里追加/m:1，关闭多进程并行编译，避免多个带Sonar分析器的csc进程同时跑把内存打满，修改后的构建任务配置参考：

- task: DotNetCoreCLI@2
  displayName: 'Build projects'
  inputs:
    projects: '**/*.csproj'
    arguments: '--configuration Release /m:1'

• 调整自托管Agent的系统内存限制：如果是自己搭的Linux Agent，先执行ulimit -a查看单进程虚拟内存上限，把ulimit -v、ulimit -m的阈值调到8GB以上，同时放开swap使用限制，避免csc申请内存时被系统直接拦截。
• 降级SonarQube扩展版本：v5.5版本的MSBuild扫描器存在明确的Razor分析内存泄漏bug，降到v4.23稳定版即可直接规避，不需要改其他流水线配置。
• 过滤不需要扫描的文件：在SonarQubePrepare任务里加排除参数/d:sonar.exclusions=**/Migrations/**,**/obj/**,**/bin/**,**/*.g.cs，跳过自动生成的代码、编译中间文件的扫描，减少分析时的内存开销。

调整配置后先跑一次构建，构建过程中在Agent机器上执行top命令监控csc.dll进程的内存占用，只要峰值稳定在3GB以内就不会触发137错误，循环重试的问题也会同步消失。

内容的提问来源于stack exchange，提问作者Astrophage