过程是这样的：
一个程序（程序A）需要在linux上交叉编译后到放到Windows运行，而且需要一些额外的dll，这个dll是在windows上编译的（程序G），程序A本身也要编译一份linux版本的放在linux上运行。
读到这里，就会明白，这种情况下是很不方便调试的。为了说明白情况，这里用结构图表示下：
问题出现了，E在linux上和F在windows上运行出现了相同的BUG（获取的结果产生了多次），正常人的第一个想法是问题是不是出现在D上，因为这是公共的代码部分，但是D这部分代码已经很成熟，而且应用在了很多其他模块，而这些模块没出现过问题
仔细排除D的问题后，很难想象问题出现在B和C上，还是从B上排查，幸运的是，发现了一个数组越界bug，可惜与开始遇到的问题无关，剩下的基本可以肯定B是没有问题了的，那么C也没有排查的必要了，因为如果出错，B和C应该是同时的
接着排查E（编译的二进制文件+一些脚本）和F（编译的二进制文件+一些脚本）。幸运的是，发现E中的某个脚本运行了多次（因为是守护进程，所以开始没法察觉），导致获取的东西重复了多次。但是在检查F的时候遇到了点尴尬，因为F非常简单，一个交叉编译出来的exe和一个启动脚本，脚本如下：
@echo off
cd /d %~dp0
copy /y qemu-ga.exe %windir%
copy /y *.dll %windir%\system32
xxxx.exe -s install
net start xxxx
也看不出来能因为这个导致结果出现多次（这里的xxxx.exe -s如果不加-s参数，则占用终端按等待方式运行）
于是只能查看C，其中C主要工作还是由G完成，于是看G，发现有些变量是通过全局方式定义并且使用的时候没有初始化，这可以说得通为什么结果是重复的了！！改完之后重新编译出dll，覆盖原来dll，重启服务进程，发现问题依旧！！！
陷入僵局，可能因为-s参数运行时除了问题，于是去xxxx.exe目录，终端运行，居然没问题了！！！！我试着归结为：程序按照服务方式运行就会返回结果两次，直接运行返回结果一次。这非常不能说服我自己，不过按照目前收集到的信息，也只能下这个结论了……
无意中右键服务查看路径，发现服务程序运行原文件！！仔细看下上面安装脚本，注意到了这一句xxxx.exe -s install，运行当前目录的程序！不过也可以理解为运行环境变量路径的程序……问题在于我忽略了优先级……现在之前尝试的一系列现象就很合理了……
- linux出现的bug是由于E的脚本多运行了
- windows出现的bug是由于G中的全局变量
- 阻碍我找问题的是由于windows按照脚本少了一个前缀
- 解决问题的过程中还顺便解决了其它问题
到这里，可能已经模糊了问题的关键，我到底在解决什么问题？思路是什么？这根本没有固定模式……