案例：
某游戏出现调用寻路函数失败异常崩溃。
基本情况分析：
在刚登陆游戏的时候直接调用寻路函数崩溃。
手动寻路以后再调用寻路不崩溃。(排除了函数编写错误的可能)
猜测可能检测方法：
有某一个标志位(全局类型)在游戏刚登陆的时候没有被赋值。
如果手动寻路以后，该标志位被赋值，再调用该函数可以正常使用。
如果未手动寻路过，该标志位未被赋值，直接调用该函数，产生逻辑错误，产生崩溃。
也就是说我们调用的函数处于标志位被赋值的内层，跳过这个赋值过程，而在更内层函数又对该标志位进行了访问验证。
解决方法：
1.通过来回返回到选角色界面 和进入游戏界面
搜索这个标志位。
返回角色界面会初始化搜索变动的数值，进入游戏以后不会被赋值，再手动寻路以后再搜索变动的数值，来回多次筛选。
最终失败，那失败的原因是什么呢？其实很简单，如果他是一个全局变量，那么他一定是可以扫描到的，但是如果他是一个指针地址，那么我们初始化以后他就变化了，这种方法就不行了，最开始我们猜测他是一个全局类型的标志位，但是目前确定并非全局变量。
2.暴力修改寄存器的方法
在CALL上的寄存器 即使无用，也是会有这些标志位线索的
而不是像书本上说的 只有ECX EBX可能传递参数
我们可以每个寄存器清零 当然不能修改ESP，看哪个寄存器可能和标志位有关系
最后在修改到ESI的时候崩溃了
然后我们追ESI来源，发现ESI是小地图控件对象，而在这控件对象下面有一个标志位，如果打开地图寻路，那么这个标志位为1，否则是0，我们没有手动寻路过的话，就是这个标志位的问题导致崩溃，逻辑很简单，你没打开地图是怎么寻路的呢？
3.返回最外层调用分析全部参数和属性
可以最全面的分析每一个值，而不遗漏
为什么不在最内层调用？因为寻路是多次频繁发包，不像其他函数1-2次发包即可，一段寻路可能上百次发包，那样我们需要自己写寻路算法，发送走路封包了，工作量一下扩大很多，当然如果以上两种办法解决不掉的情况，自己用A*写寻路，貌似也成为了一种方法。
联想：
如果某些游戏存在这样的检测点，而不产生异常，选择让外挂用户悄然不知的措施，再其使用该功能以后的一段随机时间里进行封号处理，是不是对外挂检测和防御起到更大作用。
甚至说让反检测方很难发觉呢？
否则直接崩溃，让人直接抓到突破口，视乎失去了意义。
当然，也许设计者并不是为了 检测考虑，只是单纯的逻辑冲突导致崩溃。
但是这是值得我们借鉴的好方法。
