Qbs 1.10启动失败求助：Windows7大型项目编译通过但报错0xc0000135

首先，错误码0xc0000135本质是系统无法找到程序启动必需的动态链接库（DLL）或.NET运行时组件——虽然你用Dependency Walker检测显示依赖都能找到，但这个工具有时候会漏掉延迟加载的DLL、或者对32/64位不匹配的情况识别不准确，结合Qbs 1.9开始的依赖处理变更，我们可以从以下几个方向排查修复：

1. 还原Qbs 1.8的依赖查找行为 #

Qbs 1.9版本对preferExternalLibs属性的默认值做了关键变更：1.8及以前默认是false（优先使用项目本地的依赖库），而1.9+默认改为true（优先查找系统路径中的库）。这可能导致你的项目在新版本中链接了系统里的某个库，但该库的版本、位数和项目要求不匹配，运行时无法加载。

你可以在项目的根Qbs文件中显式设置这个属性，强制和旧版本行为一致：

qbs.preferExternalLibs: false

重新编译后尝试启动，看是否解决问题。

2. 精准排查缺失的DLL #

Dependency Walker的结果不一定完全准确，试试这些更可靠的方法：

• 查看Windows事件查看器：打开「控制面板→管理工具→事件查看器」，在「Windows日志→应用程序」里找到你的程序启动失败的日志条目，里面会明确指出缺失的DLL名称和路径，这是最直接的线索。
• 用dumpbin工具分析依赖：打开VS的开发者命令提示符，运行以下命令：

  dumpbin /dependents 你的程序.exe路径
  

  对比Qbs 1.8和1.10版本生成的exe的依赖列表，看是否有新增或替换的DLL。
• 检查输出目录的DLL完整性：确认Qbs 1.10编译后，所有必需的依赖DLL都被拷贝到了exe所在的输出目录。Qbs 1.9之后的拷贝逻辑可能有变化，你可以在项目中显式添加拷贝规则：

  Group {
      files: ["path/to/your/dlls/*.dll"]
      fileTags: ["dynamicLibrary"]
      qbs.install: true
      qbs.installDir: "."
  }
  

3. 检查Qbs模块和链接器参数的变更 #

Qbs 1.9-1.10还调整了一些模块的默认行为：

• 检查是否使用了cpp模块的delayLoad属性，新版本可能对延迟加载的DLL处理更严格，导致某些库没有被正确加载。
• 确认项目中的Depends声明是否完整，新版本可能要求更明确的依赖声明，否则某些间接依赖不会被自动处理。

4. 排查32/64位兼容性问题 #

如果你的项目是32位的，而Qbs 1.10默认编译成了64位（或者反之），会导致系统找不到对应位数的DLL。检查你的项目配置中的qbs.architecture属性：

qbs.architecture: "x86" // 确保和旧版本一致

如果以上方法都无法解决，建议你对比Qbs 1.8和1.10生成的构建脚本（可以用qbs generate -g visualstudio生成VS项目，对比两个版本的项目文件差异），重点看链接器输入、依赖路径、拷贝事件等部分的变化。

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