又一个悬而未决的bug被解决

之所以叫悬而未决，是因为从我第一次见到这个bug，到现在大概已经过了快两年的时间，期间好几次想解决这个问题，但是一直碍于环境和一些技术上的限制，没有解决，直到昨天在一系列的因素作用下，终于解决了这个问题。

还是从头来说说这个bug吧，这个bug在网络上从未见过，一直以来搜索都没有找到有价值的资料，在我心里一直是个幽灵般的存在。

bug的出现是在Windows 7 SP1的系统上安装了一个遗留的VB编写的老系统之后出现的（之所以能确定和这个系统，是和另外一个同事有关，我一直以为只有我能遇到这个幽灵bug，但是他安装了老系统之后也出现了一模一样的问题，从那以后才锁定了bug的元凶，可惜到解决问题也不清楚到底老系统在里面扮演了什么样的角色，导致了这个问题出现）。

最初bug的症状是SQL Server 2008 R2的SSMS（SQL Server Management Studio）出现了无法查询数据的错误（任意选择任意数据库的任意表，在右键菜单中选择“选择前1000行”），当时的感觉就是疥癣之疾，因为不能查询，但是可以编辑（数据表右键菜单中的“编辑前200行”），可以曲线救国达到查询数据的目的，也就没太上心。

直到有一天在查看windows事件日志的时候居然也报这个错误，觉得实在是是可忍孰不可忍，所以开始搜索所有一切和这个问题有关的信息，如前所说，网络上没有太多有价值的信息，当时找到的一篇微软博客上的资料算是最接近的，

Easily Resolving an Event Viewer Error using a Process Memory Dump

http://blogs.msdn.com/b/ntdebugging/archive/2009/02/16/easily-resolving-an-event-viewer-error-using-a-process-memory-dump.aspx

提供的思路是dump出内存转储进行分析，虽然我对分析内存转储并不熟，但是当时抱着学习的想法就照着这个思路去做，结果去dump SSMS的内存转储，结果又提示没有权限，当时的感觉是天塌地陷，没路可走了，于是又开始了好长一段时间不再管它。

后来就是另外一个同事确定了bug的元凶，但是这对解决问题并没太帮助，那次又花了几个小时去尝试解决这个问题，可惜还是无功而返。

说了这么久，再来聊聊这个bug本身，从一直以来的分析和函数堆栈可以得知是在DateTime格式化的时候出的问题，

简单的说就是这样一行代码会抛出FormatException：String str = DateTime.Now.ToString();

但是这个问题并不会在我们自己的项目中出现，当时我一直没注意这一点，直到解决这个问题之后才想到这也是一个点。

最后还是回到如何解决这个问题上来吧，昨天晚上机缘巧合看到了这个：

可在广域网部署运行的QQ高仿版 -- GGTalk总览

http://www.cnblogs.com/justnow/p/3382160.html

然后就下载了源代码，想编译看看，结果如大家所想的那样，我又碰上了这个问题，不过这次是在有源代码的情况下还碰上这个问题，我的牛劲又上来了，还就不相信了，有源代码还揪不出来你个小样

于是我跟踪了代码，最终确定了的确是在上面那行代码上出问题，有人也许会问难道这么久你在自己的项目都没碰到过这个问题么，的确，我也这么写过，但还真没碰到过，为什么？

原来出问题的.NET Framework是2.0版本，我试了4.0版本，即使在有问题的计算机上也不会出现这个异常，猜测是4.0的代码中加入异常处理，如果有异常抛出的话会格式化成默认的格式。

确定了问题之后也解决不了啊，不是在自己的代码出的问题，这下就看出开源的好处了，微软不是公开了.NET Framework的代码么，咱上代码看！

细节就不多说了，可惜的是现在直接看不到2.0的代码，就拿4.6.1的来看了，想着这些基本类库里面的改动应该不会特别大，希望能有帮助

跟踪的过程也不细说了，直到看到下面这个属性终于找到对解决问题有帮助的内容（其实在之前就怀疑和区域的时间设置有关系，不过因为平时做这方面的工作不多，对类库不熟）

public static DateTimeFormatInfo CurrentInfo {
get {
Contract.Ensures(Contract.Result<DateTimeFormatInfo>() != null);
System.Globalization.CultureInfo culture = System.Threading.Thread.CurrentThread.CurrentCulture;
if (!culture.m_isInherited) {
DateTimeFormatInfo info = culture.dateTimeInfo;
if (info != null) {
return info;
}
}
return (DateTimeFormatInfo)culture.GetFormat(typeof(DateTimeFormatInfo));
}
}

接下来就是查看出问题的程序的区域文化信息，终于找到问题的根源，不知道为什么FullDateTimePattern等几个属性的值居然有乱码，但是在系统的区域属性当中查看却是没有乱码的（也许是系统自行处理这些异常？）

知道了问题根源，怎么解决也就不那么困难了，到系统的区域设置当中重置自定义格式，之后世界清静了，呼！