通常我们想获得系统的一些路径时，都会使用一些Shell函数。比如SHGetSpecialFolderPath，SHGetFolderPath，SHGetKnownFolderPath
等，传入我们想要的路径的CSIDL即可。通常情况下都会得到我们想要的结果。但是也存在例外。
目前从事的工业监控软件的研发，一般的监控软件通常都是属于中大型的系统，还包括组态期和运行期，所以复杂度相对来说还是比较高的。上周测试团队报告了一个Bug，在运行期时，监控日志的保存按钮点击没反应。咋一看，就感觉好像是类似FileDialog的窗口打开失败造成的。之后在我自己的机器上试了一下，保存对话框正常弹出。测试团队那边也不是必现，所以给排查问题带来了很大的不方便，只能在测试团队的机子上调试。最后发现代码中，在“FileDialog”打开前，调用了SHGetSpecialFolderPath方法来获取用户下的Documents文件夹路径，而此时，GetLastError返回的是2。
MSDN上关于SHGetSpecialFolderPath的记载不是很多，后来发现此方法最终是使用系统变量来获取路径的。自己又写了一个小Demo跑到测试那边测试，发现Demo的SHGetSpecialFolderPath返回的路径是正确的。调查到这，问题大概就很清晰了，监控中的某一个进程修改了系统变量！但是因为运行期的进程太多，基本没可能排查到具体是哪一个，什么时候修改了日志进程的系统环境变量。
而此刻另外一个同事为了他的一个Excel进程内存暴涨问题的已经头疼了快一周，刚好排查出是因为我们的一个类似TaskCenter的进程（此进程是所有监控运行期所以进程的父进程，是一个Job对象）在启动后，改变了由它启动的子进程的环境变量。导致有一个报表进程打开某一个excel文件失败，最终导致excel进程内存暴涨。那么问题的原因就很清楚了。在我自己的机子上，启动日志进程，使用procexp检查，username和userprofile是正确的。在测试团队的那边的日志进程的username居然是‘计算机名$‘，然后导致userprofile重定位到一个系统目录下，而系统目录并没有名为Documents的文件夹，所以返回的错误码为2。最终的原因是在做安装包时，错误设置了‘TaskCenter’进程的配置。
在产品最后的测试阶段，暴露的一些Bug都通都是很隐蔽，而且关联面都比较广。可能不仅仅是自己的代码有问题，还有可能跟运行的环境的上下文有关联。此时就需要从更大的视角去分析问题，而不是把问题只局限在它所发生的上下文。同时了解其他同事的动向，和他们沟通也对问题的解决起到一定作用。