那些想哭的bug（一）
前提
在这些年公司和个人的项目中，有些bug在没有找到根本原因之前，会觉得真的是不可思议，各种排除各种测试都未解决或干脆就未复现。
但是当某天在查找其它问题/添加新的功能/优化代码/睡觉时，突然发现/想到根本原因之后，简直想哭。。问题可能出现在一个很不起眼/一扫而过/觉得100%不会有问题的地方。
今天就遇到一个这样的bug，无语的让我想专门开个类别存放这类bug。
前提条件是这样的，主程序A在运行过程中，会从服务器上拉取一些推(la)荐(ji)信(guang)息(gao),然后在不同的条件下启动程序B来显示。A和B都经常多年多个版本的迭代，加了不同类型的广告，有2种最常用的是：
- 弹窗推荐：A启动后，拉取推荐信息，下载资源，指定时间点或指定分钟数后，启动B在右下角弹窗推荐我们软件中的游戏。
- 托盘推荐：A启动后，拉取推荐信息，下载资源，指定时间点或指定分钟数后，启动B在在托盘区域弹窗显示个图标，点击后打开我们软件中的游戏。
有一个版本，boss看到别的程序经常在退出后还会再弹出一个窗口来推荐信息（如免费版本的winrar），就拍板添加了个功能： A启动后，拉取推荐信息，下载资源，在 A程序退出后居中显示一张图片（有关闭按钮，倒计时），用户点击图片后打开我们推荐的网址。
我们的各种推荐的到达率都是有数据统计的，点击转换率也是有数据统计的，但这个功能上线后发现居然有 50%左右 的用户请求了广告，但是没有显示出来退出广告。于是乎各种分析A程序的流程（推荐信息是否拉取失败，信息解析是否可能失败，需要显示的图片资源是否可能失败，启动B程序是否可能失败，是否有安全软件拦截）、统计服务器的统计代码、统计分析服务器的代码都没有发现原因；在测试部门测试、复测时也没有发现请求了广告但是退出时不显示的问题。
在其它广告的数据中，也偶有丢失个10%左右的情况，但这种50%级别的丢失，实在是难以想像哪儿出了问题，百思不得其解后，也只能先暂停掉这个类型的推荐信息。然后几个月过去了，这事儿就抛在脑后了。
神之复现
在今天，因为有个产品，我们将A和B复制并改动出了C和D，然后在走测试流程。有一个测试在测试时向我汇报，她机器上的这种类型的推荐信息偶尔不显示。
由于程序员普遍的自负心理，我想我就是A和B简单的复制，稍微改动成的C和D，怎么可能这个功能有问题呢，肯定是测试她自己在测试环境上配置错了，或者某些条件不满足。然后很不耐烦地过去瞅瞅状况，经过她几次反复的演示，我觉得至少在她那儿是有些什么情况，确实是有不显示的问题。
先一一排除掉A的信息拉取（WireShark抓包没有问题）正常，资源下载正常（资源目录里有图片），配置后台中的其它信息也一一验证是合法的，然后用 ProcMon.exe 监控发现不显示广告时，D程序都是创建后很快就退出了。
于是将命令行拷贝到我测试机上，然后用VS Debug运行，发现一切又很正常。
神之谜底
经过几分钟的测试，在Debug和Release、及发行版本的行为对比，发现了一处代码是问题的根源。
1 | 在B的入口处： |
因为之前的广告的行为基本上都是A启动B，B就单独存在，当用户点击推荐信息时，将动作发送给A，让A来执行。如果A不存在了，就使用命令行启动A来处理。
但新加的那个退出推荐的逻辑是，在A的主窗口的OnClose事件里启动B程序来显示广告信息，但执行顺序存在随机性，有可能是B先启动，然后走到FindWindow，也有可能是A程序的窗口先OnDestory掉，B再走到FindWindow。所以，在所有的用户环境那边，就出现了50%左右的丢失率（如果两边的执行代码区别再大一些，可能是别的百分比）。
而解决办法显而易见，退出推荐时根本不需要检测A窗口是否存在，后续的用户行为反应也是不需要再启动A来执行的。在if (!hWnd) 条件中再加上广告类型的判断即可解决。
迷之羞愧
如果倒着看这个博客，一定会嗤之以鼻：如此简单的问题都找不到。 但反想一下，这个bug是一个随机现象，且不能稳定重现，且bug触发的原因隐藏在多年表现正常的的代码中，这都导致了问题没有很快的解决（ 甩锅干脆利落）。
其实嘛，经过多年的项目经验，确实印证了一句话 事出反常必有妖，就是当用户出现了不正常的情况，虽然大部分情况下会不由自主的指责别人使用方法不对，但往确实是自己的程序出现了或多或少的考虑不周或者是隐藏的问题导致的。只不过，有些bug换种使用流程和环境就绕过去了（比如：万能的重启），有些bug总是会在不经意间蹦出来咬你一口。