遇到这种间接引入的系统函数调用确实头疼，尤其是看不到代码里的直接引用。结合你用Visual Studio 2015 + Intel C++编译器的环境，给你几个靠谱的定位步骤：

• 生成并分析MAP文件
  在你的项目属性里，找到「链接器 → 调试」，把「生成映射文件」设置为「是(/MAP)」，同时可以勾选「映射文件包含行号」方便更精准定位。编译链接后，在输出目录会生成一个.map文件。用文本编辑器打开它，直接搜索GetLogicalProcessorInfo，你能看到这个函数被哪个模块（可能是某个库的导出函数，或是编译器生成的代码）引用，从而锁定调用来源的范围。

• 用dumpbin工具排查导入表
  VS自带的dumpbin工具可以直接分析exe/dll/lib的导入符号。打开VS的命令提示符（Developer Command Prompt），运行以下命令：

  dumpbin /imports YourApp.exe > imports.txt
  

  然后在imports.txt里搜索GetLogicalProcessorInfo，能看到是哪个模块（你的exe本身，还是某个依赖的dll）导入了这个函数。如果是某个第三方库的dll，那就是这个库在内部调用了它；如果是exe本身，大概率是编译器或运行时库的代码间接引入的。

  要是怀疑是新增的静态库搞的鬼，还可以对该lib文件运行：

  dumpbin /symbols YourNewLib.lib > symbols.txt
  

  搜索目标函数，看是否有相关的符号引用。

• 排查编译器/链接器的隐性引入
  新增库后，可能间接改变了编译器的优化或运行时库设置。比如Intel C编译器的某些多核优化选项（比如/Qparallel）可能会自动引入和处理器信息相关的系统函数。你可以尝试临时关闭这类优化，重新编译后看是否还会触发这个调用，以此验证是否是编译器优化导致的。另外，检查项目的「配置属性 → 常规 → 平台工具集」和「C/C → 代码生成 → 运行时库」设置，确认没有因为新增库而切换到了仅支持XP SP3的运行时版本。

• 最小化测试排查依赖库
  新建一个空项目，只链接你新增的那个库（以及它的直接依赖库），不添加任何自己的代码，编译成exe后用dumpbin检查是否引入了GetLogicalProcessorInfo。如果是的话，再逐个移除它的依赖库，重复测试，直到找到具体是哪个依赖库导致的问题。

• 调试环境中查看调用栈
  如果你能搭建一个Windows XP SP2的调试环境（比如用虚拟机），运行程序触发报错时，在VS调试器里查看完整的调用栈，就能直接看到是谁调用了GetLogicalProcessorInfo——这是最直接的方法，前提是你能拿到调试环境。

找到调用来源后，你就可以针对性处理了：比如替换兼容XP SP2的库版本，或者自己封装一个动态加载的逻辑（判断系统版本，SP2下用替代方法获取处理器信息）。

内容的提问来源于stack exchange，提问作者Hans van Zutphen