最近有客户找到我，说他们生产环境的事件日志中有下面的报错。要我帮忙找找原因。
Event Type: Warning Event Source: ASP.NET 2.0.50727.0 Event Category: Web Event Event ID: 1309 Description: .. Event code: 3005 Event message: An unhandled exception has occurred. Exception information: Exception type: SqlException Exception message: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server) …
这是一个典型的asp.net unhandled exception记录。如果asp.net web应用运行的过程中出现异常，并且这个异常没有被web应用的代码捕捉到，asp.net运行时就会捕捉这个未处理的异常，并在应用程序事件日志中记录类似的记录。记录的ID总是1309。
这次的异常消息非常明确：web应用无法连接到数据库。从经验来看，出现这个错误时，往往连最基本的TCP三次握手都没有成功完成。也就是说TCP连接都还没有建立起来就失败了。
客户说这个问题并不总是发生，而是间歇性的会有几个出现在事件日志里面。
好医生从来不掐指算。没有数据支持的结论都是臆想。用Network Monitor工具收个网络包吧。我们从网络包中可以看到web前端和后端数据库之间的网络交互，有了它，我们就可以分析当时它们之间到底为什么不能建立连接。
一般情况下Network Monitor只能连续运行几分钟，否则记录的网络日志会非常大，拖累系统性能，并且难于分析。为了限制生成的日志文件的大小，我需要用命令行的nmcap.exe 工具，并且用/File参数来限制文件的大小。具体请参考nmcap.exe 。
另外一个使用的工具是DebugDiag。形象的说，它作用是在SqlException发生时，给IIS进程拍个快照（memory dump）。这样当问题发生时，所用内存中的信息都会被保存下来。这样事后我再看当时正在执行的代码，局部变量的值，函数的参数，连接字符串等等都不是问题。有关DebugDiag 的使用详解，请参考How to Use the Debug Diagnostic Tool v1.1 (DebugDiag) to Debug User Mode Processes
就这样客户连续运行了nmcap.exe和DebugDiag几天，问题终于又发生了。
用network monitor看TCP 3次握手，可以通过设置filter为tcp.Flags.Syn来过滤网络包。同时我假设SQL连接用的是默认的1433端口，所以同时使用filter: tcp.Port==1433。结果如下:
|
Time Delta |
Source |
Destination |
Description |
|
0.0000000 |
Web |
SQL |
TCP:Flags=......S., |
|
2.8593750 |
Web |
SQL |
TCP:[SynReTransmit]Flags=......S., |
|
6.0162010 |
Web |
SQL |
TCP:[SynReTransmit]Flags=......S., |
果然握手就出了问题。所要连接的SQL服务器一直没有响应，最后导致连接超时。
通过使用psscor2，可以从dump中解出当时的连接字符串如下：
data source=test1;persist security info=True;initial catalog=…
数据库的名字是test1，一看就是台测试服务器。一定是部署到生产环境后，忘了改连接字符串。但是为什么这个问题只是在处理有些请求时才发生？大多数请求还是好的？为什么出问题后，什么也不用做，后续的请求可能就自动恢复了？
Psscor2有个sam(save all modules)命令可以从dump中，把当时加载的所有.net assembly DLL都保存到别的目录。然后我就可以用像ILSpy 这样的工具来反编译DLL中的代码。
反编译结果如下：
public static string getConnectionString(string name) { string str = "T"; if (!isTesting()) { str = "P"; } return ConfigurationManager.ConnectionStrings[str + name].ConnectionString; }
连接字符串是由getConnectionString ()函数返回的。这个函数根据isTesting ()的结果来返回生产或者测试环境中对应的连接字符串。继续往下看：
public static bool isTesting() { string a = HttpContext.Current.Request.Url.Host.ToLower(); return !(a == “www.contoso-production.com”); }
看起来，逻辑还比较简单：如果请求的主机名不是生产环境的主机名，那就返回true。看起来挺合理，那为什么对于当时这个请求就出错了呢？
可惜当时那个请求的URL如下：
http://www.contoso-production.com.:80/default.aspx
请注意:80前面的那个点。根据RFC http://www.ietf.org/rfc/rfc1034.txt ，这个点是合理的，但是当时的判断逻辑不能很好的处理这种情况。
The most common interpretation uses the root "." as either the single origin or as one of the members of the search list, so a multi-label relative name is often one where the trailing dot has been omitted to save typing.
修改代码后，问题就不再出现了。如果你的应用里面也用到了类似的代码，那么也请注意了。
Juntao
