但是有时候新建一个windows管理员账号的时候，这个账号却无法连接上TFS，总是提示没有权限，过几天又突然可以访问，就没搭理这个问题。后来一次出问题的时候，我无意中检查了一下"Builtin\Administrators"组的成员，发现新建的用户竟然没有在里面！看来，这个组虽然是映射到windows的administrators组，但是并不是实时刷新的。

找到问题所在，那解决思路就是让TFS强制刷新这个分组即可。google了一下，似乎没有这样的命令行。想到IIS中有一个TFS应用程序，客户端就是通过HTTP来访问TFS的，重启这个应用程序应该可以达到效果。找到TFS对应的应用程序池，回收之，再看回"Builtin\administrators"组，新建的用户果然有了，也可以正常访问TFS了。

希望此文对你有帮助~

== Kevin Yang ==

你可能对下面的文章感兴趣

• TFS无法创建新的Team Project
• Win7/Vista高级用户必备的右键菜单Take back my Ownership!
• 升级TFS 2010之后修复原有工作区
• 权限不足导致的Analysis性能计数器在Vista/win2008下失效的问题
• 让Team Foundation Server Client（TFS）能比较和合并Word文档

服务器的系统环境是Team foundation server 2008+windows server 2008+Sql Server 2005+VS sp1。创建到最后一步的时候提示错误，说是创建Reporting Site的时候出的问题，让我检查权限是否配置正确云云。我确认了一下我登录TFS使用的是administrator账户，而且此账号在Sharepoint上的权限已经是content manager了，应该不是这个问题。打开TFS的异常日志，看到如下的错误信息：

Event Description: TF30207: Initialization for plugin "Microsoft.ProjectCreationWizard.Reporting" failed
Exception Type: Microsoft.TeamFoundation.Client.PcwException
Exception Message: TF30224: Failed to retrieve projects from the report server. Please check that the SQL Server Reporting Services Web and Windows services are running and you have sufficient privileges for creating a project.
Exception Details: The Project Creation Wizard encountered a problem while
creating reports on the SQL Server Reporting Services on GS-CONFIGSERVER.
The reason for the failure cannot be determined at this time.
Because the operation failed, the wizard was not able to finish
creating the SQL Server Reporting Services site.
Stack Trace:
   在 Microsoft.VisualStudio.TeamFoundation.RosettaReportUploader.CheckForProjectFolder(PrivateData data, String projectName, ProjectCreationContext context)
   在 Microsoft.VisualStudio.TeamFoundation.RosettaReportUploader.Initialize(ProjectCreationContext context)
   在 Microsoft.VisualStudio.TeamFoundation.EngineStarter.InitializePlugins(MsfTemplate template, PcwPluginCollection pluginCollection)
--   Inner Exception   --
Exception Type: System.Web.Services.Protocols.SoapException
Exception Message: 服务器未能识别 HTTP 头 SOAPAction 的值: http://schemas.microsoft.com/sqlserver/2005/06/30/reporting/reportingservices/ListChildren。
SoapException Details: <detail />
Stack Trace:
   在 System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
   在 System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
   在 Microsoft.TeamFoundation.Proxy.Reporting.ReportingService.ListChildren(String Item, Boolean Recursive)
   在 Microsoft.VisualStudio.TeamFoundation.RosettaReportUploader.CheckForProjectFolder(PrivateData data, String projectName, ProjectCreationContext context)
-- end Inner Exception --
--- end Exception entry ---

Google了很久终于找到有用的信息。大意就是说，TFS内部维护着一堆web service的Url，用于访问Reporting Service、Sharepoint等服务。但是TFS 2008内部维护的Url使用的web service接口却是已经废弃了的Sql Server 2000的Reporting Service的接口。

修改步骤：

1. 命令行切换到"TFS安装目录/Tools"下

2. 运行命令：tfsreg /export tfsreg.xml 服务器机器名（先导出当前配置）

3. 用记事本打开tfsreg.xml文件，找到reportservice.asmx，将其改成reportservice2005.asmx

4. 运行命令：tfsreg /overwrite tfsreg.xml 服务器机器名（更新配置）

如果还是不行可能是缓存缘故，可以重启机器试试。

Mark一下。

== Kevin Yang ==

你可能对下面的文章感兴趣

• 升级TFS 2010之后修复原有工作区
• 解决新创建的windows用户无法访问TFS的问题
• 让Team Foundation Server Client（TFS）能比较和合并Word文档

看遍所有菜单项没有找到可以改动的地方，Google也没找到解决方法，就一直保持这样了。

后来有一次打开文件夹选项的时候，看到有个“重置文件夹”的按钮，突然联想到这个问题，点了一下，再到无线网络中心一看，居然恢复正常了。

——Kevin Yang

你可能对下面的文章感兴趣

• Win7/Vista高级用户必备的右键菜单Take back my Ownership!
• Win7访问远程桌面最大化同时让任务栏可见
• 解决Win7下IE8开发人员工具打不开的问题

在经过一番简单排查之后找到了问题所在，Cookie设置失败。

但至于为什么会失败，这个问题查了半天，最后在StackOverflow上面有人提到了，IE从5.0开始就无法为短域名下设置Cookie。

那么多短才会出现问题呢？经过试验，发现包含点号在内一共5个字符以内包括5个字符都无法通过Javascript设置Cookie，不过这里有个前提，就是只有当你设置Cookie时显式指定了domain参数才会失败。也就是说如果你这么写：

document.cookie="key=value;domain=ab.cn";

Cookie设置会失败，如果去掉domain参数，直接这样写：

document.cookie="key=value";

则不会出现这样的问题，即便当前域依然是ab.cn。

这篇文章http://support.microsoft.com/kb/310676/en-us/提到了类似的问题，不过貌似和这个情况不大一样。大家也可以参考一下。

因为Cookie设置失败，导致我们的流量监测系统认为每个访问都是一次新的访问，自然跳出率就极高了，而GA貌似Cookie设置失败就不发数据了。

Firefox和Chrome没有这样的问题。

Mark一下，希望对遇到类似问题的人有帮助。

——Kevin Yang

你可能对下面的文章感兴趣

• IE中使用window.open打开新窗口时无法获取Referrer对象
• Javascript操纵Cookie
• 当Google Analytics、Firefox和IIS走到了一起…
• 当前日期110年
• 最精简的判别IE的Javascript代码
• 流氓的联通，鄙视之
• 解决Win7下IE8开发人员工具打不开的问题
• 解析IE中的Javascript Error对象

使用Firefox点击AdWords广告跳转到客户网站上之后，再次刷新页面或者浏览其他页面均提示“Bad Request”的HTTP错误（错误码400）。

而IE、Chrome下则没有这个问题。

Cookie惹的祸

由于HTTP本身是无状态的，用来实现状态维持的技术一般都是Cookie。而之前我也遇到过几次因为Cookie导致的访问异常。一次是同事用Firefox死活访问不了新东方网站（参见我之前的文章：Firefox无法访问特定网站），一次是我自己死活登录不了Gmail帐号。这两个问题最终都是以清空Cookie解决的。所以这次有经验了，用web developer bar查看当前客户网站下都有哪些Cookie，一瞄，发现一个带乱码的Cookie。

不用想，也知道这是因为中文没有编码就直接塞到Cookie里头导致的乱码。看看Cookie的来头，__utmz，是Google Analytics（GA）植入的。删除此Cookie之后，访问正常。

Google Analytics的Cookie编码问题

同事测试的那个广告的Url添加了Google Analytics支持的跟踪参数，并且客户网站上也部署了GA的代码。

GA在执行时会检测当前Url中是否包含广告跟踪参数（至少必须包含utm_source），一旦发现，则认为是付费流量，这个时候它就会提取广告信息中的来源（utm_source），广告系列（utm_campaign）和广告媒介（utm_medium），对其进行解码（先尝试用decodeURIComponent函数，失败的话再用unescape函数），最后持久化存储到__utmz这个Cookie中。但是就在写入Cookie这一步，GA漏掉了编码操作。也就是说，如果我们的广告系列或者广告媒介的原始信息包含中文，那么GA就会直接往Cookie中塞入中文信息。

举个例子，我要为我的博客投一个宣传广告：

• 广告系列：Kevin博客宣传
• 广告来源：google
• 广告媒介：PPC
• 带跟踪参数的着陆页面Url：http://www.imkevinyang.com/?utm_source=google&utm_medium=ppc&utm_campaign=Kevin%E5%8D%9A%E5%AE%A2%E5%AE%A3%E4%BC%A0

那么GA在写Cookie的时候，会执行类似下面的代码（当然这里简化了__utmz的值）：

var data = "Kevin博客宣传";
// GA错误的Cookie操作
document.cookie = "_utmz=" + data;
// 正确的Cookie存储操作
document.cookie = "_utmz=" + encodeURI(data);

使用Javascript对Cookie进行存取，标准的操作应该是在存入的时候编一次码，取出的时候解一次码。这样保证存放在Cookie中的都是ASCII字符。早期JS使用escape/unescape进行编解码，现在通常使用encodeURI或者encodeURIComponent函数，这两个函数用的都是UTF-8编码。

中文Cookie潜在的问题

那么当我们直接将中文直接存到Cookie又会发生了什么事呢？IE和Firefox的行为有什么不一样的地方呢？我们在IE8和Firefox3.6下做几个实验。

IE8对中文Cookie的处理

实验步骤：

• 打开IE8，清空所有Cookie和缓存，建立干净的测试环境。
• 访问http://www.imkevinyang.com/
• 地址栏执行javascript:alert(document.cookie="mycookie=缂栫爜编码;expires=Mon, 25 May 2020 10:31:49 GMT")，写入一个持久化cookie。

这样就在我的博客上设置了一个2020年5月25号过期的cookie了。之所以要设置持久化cookie而不是会话Cookie，是因为IE会将持久化Cookie写入到硬盘上了，这样方便我们了解这个过程，而会话cookie我目前还不清楚他存储的位置。

细心的你会注意到，上面这个cookie的值很奇怪，有几个乱码。其实那段乱码是我把“编码”这两个汉字的UTF-8编码（6个字节）使用GB2312解码（每两个字节对应一个字符）后得到的字符。至于为什么要这样测试，一会我们就会知道了。

IE地址栏用的是ANSI编码，也就是说当你在地址栏输入中文的时候，IE会将中文字符以系统默认字符集进行编码。当你使用中文系统时，地址栏的“编码”字符，实际上最后会被编码为B1 E0 C2 EB四个字节，而在英文系统下，系统使用的是西方字符集作为默认字符集，没有中文字符，因此“编码”这两个字符会被替换成?，也就是3F。

IE在创建cookie文件，会自动选择最合适的编码。当我们写入“缂栫爜编码”（GB2312编码后得到二进制流E7 BC 96 E7 A0 81 B1 E0 C2 EB），由于最后四个字节无法用UTF-8解码，因此IE会将文件存储为GB2312。（如果你只测试“缂栫爜”的话，IE会将文件存储为UTF-8）。

好了，现在让我们来看看文件里头都是什么内容。

打开everything工具，搜索“www.imkevinyang txt”这样就会列出文件名包含www.imkevinyang和txt的所有文件。

打开这个文件，里头存放的就是IE持久化的cookie信息。

这个时候，我们再在地址栏通过javascript:alert(document.cookie)我们会发现，IE显示的Cookie值和我们一开始设置的是一样的。

看完了本地的Cookie信息，我们接下来看看IE发送给服务器的Cookie又是什么。

我们用Fiddler来监视整个HTTP通讯过程（这里不用HTTP Watch是因为HTTP Watch会将HTTP消息解码后显示出来，没办法看到原始二进制数据，不方便分析）。

我们再向我的博客首页发起一次访问，在Fiddler中我们会看到：

（文本形式）

（二进制原始数据）

我们很惊奇的看到，IE发送的并不是我们设置的那些字符“缂栫爜编码”（二进制是E7 BC 96 E7 A0 81 B1 E0 C2 EB），而是“编码����”（现在知道我为什么要用“缂栫爜编码”做测试了把）。对应的二进制是E7 BC 96 E7 A0 81 EF BF BD EF BF BD EF BF BD EF BF BD。注意到，IE将原始信息的后面4个字节替换成了EF BF BD.

这是因为IE发送HTTP消息的时候会检测字节流是否是能够以UTF-8解码，如果不行，那么会将相应的异常字节替换成EF BF BD（也就是对应�字符）。这有点类似于我们之前提到的，英文系统对于缺失的字符会使用?号替代。

Firefox对于中文Cookie的处理

Firefox不像IE那样把Cookie直接存储为文件的形式，所以我们研究起来没那么方便。

不过我们还是按照上面同样的步骤来做实验，不过这次为了简单起见我们修改一下测试的Cookie值。

• 打开Firefox，清空所有Cookie和缓存，建立干净的测试环境。
• 访问http://www.imkevinyang.com/
• 地址栏执行javascript:alert(document.cookie="mycookie=1编码1")

第一次Firefox弹出的对话框显示我们Cookie应该是设置成功了，返回“1编码1”字符串。

但如果你再次通过Javascript:alert(document.cookie)你会发现，这次弹出的内容变了：

我们通过Web Developer Toolbar查看当前域下的Cookie，发现，目前的Cookie确实是像上面第二个对话框所示的，是带乱码的：

我们现在关心的问题是，这个乱码是怎么来的？

我们先把这串文字拷贝到Notepad++中（注意，需要将Notepad++调到UCS-2编码状态下）看一下对应的字节是什么。

31是字符“1”的ASCII码。而16和01是哪来的呢？

其实是Unicode Code Point。“编码”的Unicode码是“7F16 7801”。上面显示的16和01就是截断了Unicode码高位得到的。为了证实这个结论，我又测试了好几个中文cookie，均是如此。

也就是说，Firefox的地址栏使用的是Unicode码，也就是说当你输入“mycookie=1编码1”这样的字符串的时候，Firefox看到的是：

\u006d\u0079\u0063\u006f\u006f\u006b\u0069\u0065\u003d\u0031\u7f16\u7801\u0031

在存储中文Cookie的时候，他会将Unicode的高位截断，保留低位。然后写入Cookie存储。这也是为什么我们会看到“编码”这个Cookie变成了“16 01”。

Firefox向服务端发送HTTP请求时对于http消息的编码处理方式和IE的一样，也是判断字节流能够以UTF-8进行解码，这里就不再赘述了。有兴趣的朋友可以按照上面的方法去测试。

为什么Firefox无法访问

基于上面对IE和Firefox对中文Cookie的处理方式的了解，我们现在可以知道，对于中文Cookie，IE是用ANSI编码，也就是说Cookie中永远不会出现ASCII字符集中的不可打印字符（GB2312编码每个字节也都是从A0开始的），而Firefox采用Unicode码，却又对其进行了高位截断，导致Cookie有可能会出现ASCII字符集中的非打印字符。

IE和Firefox在构造HTTP消息的时候对于字节流序列编码问题的处理方式一样。无法使用UTF-8解码的字节流序列，将其替换成EF BF BD，这个我们在Fiddler中已经看到了。而对于ASCII字符集的非打印字符则不做任何处理，直接发送到服务器端。

所以用Firefox访问，服务端收到的HTTP Request有可能包含非打印字符，而IE访问的话，则不会出现这样的情况。

例如Firefox上设置了一个中文Cookie，“我”，Unicode码是62 11，被Firefox高位截断了，就剩下11了，对应着ASCII码表中的Device Control 1，也就是控制字符。那么当你带着这个Cookie向服务端发起请求的时候服务端有可能就会直接抛出Bad Request的异常，告诉客户端，你发过来的请求不符合HTTP规范。

所以实际上不只是Cookie不能出现这样的非打印字符，其他HTTP Header中也不能出现这样的非打印字符。我们可以直接使用WFetch来构造这样的“非法”请求：

服务端一样会抛出400 Bad Request。

IIS和Apache的不同处理方式

当客户端发起的请求存在问题时，服务端的处理方式是取决于不同服务器的实现的。我们上面讨论的这个问题，实际上只会对IIS造成影响，对那些后台采用Apache或者LiteSpeed这类的服务器不会有影响。这说明IIS的容错性还是稍微差一点，不知道从安全的角度来考虑是好事还是坏事。

总结回顾

上面讲了那么多，你可能听着有点乱了。我们重新来整理一遍整个故事。

广告代理商投了一个广告，着陆页面Url中添加了google的广告参数，其中带有中文信息，客户网站上部署了GA代码，GA读取到此中文信息之后直接扔到Cookie中而没有经过编码。Firefox内部将此中文的Unicode码高位截断保留低位存下来。当你再次刷新页面的时候，Firefox把这个截断的字符发给IIS服务器，而刚好这个截断之后的字符是一个非打印字符，IIS觉得自己无法处理，就抛出一个Bad Request，告诉客户端此请求非法，我无法处理。

整个故事就这样。

怎么办呢？建议为了保险起见，如果客户网站服务器用的是IIS，那么你还是不要在Firefox上投放那些Url跟踪参数带中文（即使是UTF-8编码过）的广告了，否则可能浪费钱，因为用户来了，再点一次可能就无法访问了，而且以后可能都无法访问了（现在终于知道为什么我那同事当时用Firefox始终访问不了新东方了...）。(update:2010-7-2)或者你在投放广告的时候，Url参数中的广告系列、广告媒介以及广告来源这三个跟踪参数不要包含中文信息（即使是UTF-8编码过的），全部使用英文，这样也不会有问题。

希望整个分析过程对你有所帮助。

——Kevin Yang

你可能对下面的文章感兴趣

• 64位系统下IIS7 ISAPI处理器加载失败
• Document.Referrer丢失的几个原因
• Firefox无法访问特定网站
• Google Analytics中的Page维度
• IE中使用window.open打开新窗口时无法获取Referrer对象
• IE无法设置短域名下Cookie
• IIS中使用子目录文件作为默认文档（Default Document）替代重定向
• Javascript操纵Cookie
• Silverlight启用Assembly Caching之后铁通用户无法访问
• 【推荐】两款HTTP流量分析工具的比较

Invalid length parameter passed to the substring or left function.

奇怪的是，这还不是调用的时候抛出了异常，而是在校验阶段（Validation Stage）就抛出了异常。我感到纳闷，难道SSIS或者Sql Server还能对我的存储过程作单元测试？？

用这句错误信息上Google搜了一下，发现问题是出在CharIndex函数和Substring函数的联合调用上。为了简化，我下面只摘取了一段出问题的代码：

declare @index int
set @index = charindex('/',@url,1)
set @url = substring(@url,1,@index - 1)

以前的VBA函数还有Sql函数都喜欢使用1作为数组起始索引，用0表示返回失败，而不像现在C风格下使用0作为起始索引，-1作为失败返回值。charindex这个sql函数是用来查找某个字符串在特定字符串中的位置，如果找不着匹配的，则返回0。而下一行代码中的substring又传入了一个@index-1的参数，因此此参数有可能为负数。猜测就是因为这样，所以SSIS检测失败，抛出异常。之所以当时这么写，是因为基于一个假设，就是业务系统中，此字段都会包含/字符。但是人家SSIS组件可不认你的假设。（再一次证明了，编程的时候假设越少越好）

既然如此，我们就多加一层检测。修改代码如下：

declare @index int
set @index = charindex('/',@url,1)
if(@index > 0)
  set @url = substring(@url,1,@index - 1)

启动SSIS包，结果还是抛出一样的错误。这就奇怪了。难道做了检测还不行？难道substring的第三个参数非得是大于0的？试了一下，改成if(@index > 1000)都不行。

想了半天，最终我只能怀疑，SSIS的这个校验组件，是通过判断变量什么时候被赋值来获得值的可能范围是多少，而不会判断上下文是否有对变量做有效性检测。也就是说，在上面这个存储过程中，@index变量只在charindex函数返回时被赋值，值范围是0~正无穷。因此传给substring的第三个参数的时候，@index – 1的值范围就变成了-1~正无穷了。它直接无视我上面的if语句了。

把这个猜想和同事讨论了一下，他设计了一个验证方案，就是添加一行永远不会被执行的的赋值语句。代码如下：

declare @index int
set @index = charindex('/',@url,1)
if(@index > 0)
begin
  if(1=0) set @index = 1000
  set @url = substring(@url,1,@index - 1)
end

注意上面代码中将@index赋值为1000的操作，是不会被执行的。可是却通过了SSIS的校验。这说明，SSIS的校验组件做的工作实际上是非常简单的校验而已，不会参考上下文代码。

既然如此，这个校验对于开发人员来说，不但没有意义，而且还会影响我们编写逻辑正确的代码。因为这个校验是不能被关闭的。也就是说，为了绕过这个没意义而且错误的校验，我不得不在charindex和substring这种联合调用的代码中加入一行永远不会被执行的赋值语句来迷惑SSIS的校验组件。否则SSIS的包根本启动不了。

感觉这应该是一个设计上的Bug。

希望对遇到这个问题的人有所帮助。

——Kevin Yang

你可能对下面的文章感兴趣

• Sql Server中修改自增长列经常需要用到的配置
• Sql Server重命名所有外键约束
• Sql Tips——Update语句也使用表别名(Table Alias)
• 全半角空格导致的Analysis Services处理错误
• 释放SQL Server占用的内存

“随机”的gzip行为

问题的症状非常简单而又奇怪。有时候连续访问脚本多次，刚开始没有gzip，再次访问又有gzip。等过好一会再去访问，gzip又没有了。有的时候则是无论怎么访问都不给我返回gzip后的响应。

问题的分析

排除了CPU负载过大的因素，因为发现当深夜机器CPU负载正常的时候也一样出现这样的问题。

在系统日志中发现以下Warning条目，引起了我的注意：

Warning    2010/4/13 6:32:41    IIS-W3SVC-WP    2264    None

The directory specified for caching compressed content C:\inetpub\temp\IIS Temporary Compressed Files\XXX is invalid.  Static compression is being disabled.

通过日志筛选，发现从09年7月份就一直出现这样的Warning了，而且出现频率是隔1-3天左右。

这个文件夹是IIS用于存放压缩后的静态内容缓存。按照上面日志的意思，是说这个目录出了问题，导致静态压缩功能被禁用了。但是我明明可以访问这个文件夹，而且里头确实还放着缓存的脚本。

IIS论坛上提这个问题的帖子很多，但最终得到解答的没看到。不过其中一些人的回复倒是给了我不少思路。其中有人说道可能是文件夹权限问题，我看了看那个压缩缓存目录，上面的权限的确是应用程序池的身份，没有问题。使用ProcessMonitor监测了w3wp.exe进程的活动情况，没有看到这个进程在访问文件系统时出现错误。

后来在网上看到了Kanwaljeet Singla（IIS开发团队成员）的一篇文章，介绍IIS7相比IIS6在压缩模块上的改动，文中提到了一点，从IIS7开始，为了降低开销，IIS只对那些频繁访问的静态资源启用压缩。通过IIS7新引入的两个配置选项frequentHitThreshold和frequentHitTimePeriod，我们可以设定，当某个资源在frequentHitTimePeriod时间内被连续访问了frequentHitThreshold次，那么就算是“频繁访问”了。默认的配置是10秒钟内连续对同一Url发起2次请求就算此Url对应的资源属于频繁访问的资源，IIS服务器就会对其进行压缩，然后丢入缓存目录。

这也就解释了为什么有时候第一次请求脚本的时候，服务器没有返回gzip压缩后的内容，而是等你接着下一次访问的时候才会返回gzip响应。

但是按照这篇文章提到的IIS的设计理念，一旦资源被压缩缓存过，那么以后就不会再应用这个“频繁访问”的检测逻辑了，因为毕竟已经没有压缩开销了。而我非常确信这个脚本已经被缓存在服务器硬盘上了，那为什么我过一段时间再去访问的时候还是没有gzip呢？

在IIS7中有一个功能，叫做失败请求跟踪（Failed request tracing），允许技术人员跟踪那些出问题的请求在IIS内部都发生了什么事。为了揭开我的疑问，我对此网站开启了失败请求跟踪。

IIS7的Bug？！

打开IIS7管理器，定位到相应的网站右侧的操作面板，开启“失败请求跟踪”。默认跟踪日志文件是存放在%SystemDrive%\inetpub\logs\FailedReqLogFiles目录中。

然后在功能面板中找到“失败请求跟踪规则”进行配置：

为了防止其他脚本的干扰，在这里我限定了只跟踪测试的脚本

响应状态填写200即可

接下来是选择跟踪提供程序，也就是给你提供跟踪日志源的程序，由于我们的脚本只经过静态文件处理器，因此这里我们只需要选择www server处理程序即可。

然后我们就可以去测试一下访问出问题的脚本了。一旦IIS中途处理遇到些问题，那么就会以xml形式记录下相关的日志。打开FailedReqLogFiles目录，里头会有一些fr000001.xml这样格式的文件，每个文件代表一次失败请求。我们打开这个文件，查找compression关键词，发现了以下内容：

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
 <System>
  <Provider Name="WWW Server" Guid="{3A2A4E84-4C21-4981-AE10-3FDA0D9B0F83}"/>
  <EventID>0</EventID>
  <Version>1</Version>
  <Level>4</Level>
  <Opcode>3</Opcode>
  <Keywords>0x40</Keywords>
  <TimeCreated SystemTime="2010-05-13T16:59:08.086Z"/>
  <Correlation ActivityID="{00000000-0000-0000-FD2B-008041000061}"/>
  <Execution ProcessID="10752" ThreadID="14504"/>
  <Computer>DMZ</Computer>
 </System>
 <EventData>
  <Data Name="ContextId">{00000000-0000-0000-FD2B-008041000061}</Data>
  <Data Name="Reason">14</Data>
 </EventData>
 <RenderingInfo Culture="zh-CN">
  <Opcode>STATIC_COMPRESSION_NOT_SUCCESS</Opcode>
  <Keywords>
   <Keyword>Compression</Keyword>
  </Keywords>
  <freb:Description Data="Reason">NOT_FREQUENTLY_HIT</freb:Description>
 </RenderingInfo>
 <ExtendedTracingInfo xmlns="http://schemas.microsoft.com/win/2004/08/events/trace">
  <EventGuid>{E60CEE96-4472-448D-A13C-2170B18220EC}</EventGuid>
 </ExtendedTracingInfo>
</Event>

在上面，我们看到了NOT_FREQUENTLY_HIT的字样，看上去响应没有gzip的原因，还是因为没有达到“频繁访问”的要求，即使请求的资源已经被压缩过然后存放在硬盘上了。似乎这个压缩缓存是有一定的时效的，就是过了多长时间就得重新验证一下这个“频繁访问”的逻辑了。

我又进行了大量的测试，发现这个失效时间大约是在5分钟。也就是说，当你频繁访问一个资源，IIS开始对其进行压缩并存放在本地压缩缓存目录之后，大约过5分钟，你再去访问，还是会重新执行“频繁访问”这个验证逻辑。

为了证实我得到的结论，我在推特上向Kanwaljeet Singla（他的推特是@kjsingla）询问了这个问题。出乎我的意料，他很快就回复了我，估计是因为我在做这个测试的时候已经半夜了，他那边刚好是白天的缘故吧。他经过测试，证实“频繁访问”的逻辑检测发生在“响应是否已经压缩”逻辑之前，这确实是IIS7/7.5的一个Bug。

解决办法倒是很简单，只需要将“频繁访问”定义得更宽泛一些即可。例如1分钟内1次访问。

<configuration>
    <system.webServer>
        <serverRuntime frequentHitThreshold="1" frequentHitTimePeriod="00:01:00" />
    </system.webServer>
</configuration>

问题真的解决了吗？

当我以为问题圆满解决，满意的睡着之后，第二天测试的时候发现请求脚本又没有gzip了，而且这次是连着访问好几次都没有压缩，这没法用我昨晚得到的结论去解释。让我非常郁闷-_-|||

冷静！

在系统日志中，我又看到了压缩目录无效的警告信息了，但这次，这个压缩目录是真没了。回想起那个时刻做的操作，当时运营的网站抛出未处理的异常，我修改完这个异常就把应用程序池给重启了。难道是说，当网站出现异常的时候，如果强制回收应用程序池的话，会导致静态压缩目录被删除？更奇怪的是，当我再次回收应用程序池，发现这个压缩目录又被重新创建了。

为了验证我的猜想，我又重复了这个过程，让网站抛出异常=>重启应用程序池=>再次请求脚本，问题重现；我又新建了一个一摸一样配置的测试网站，同样的测试流程，却发现压缩目录正常，没有出现上述的症状。

经过细致的对比，我发现运营的网站和我测试的网站环境还是不大一样的。运营的网站时时刻刻都有外部的请求，而且还很频繁。而测试网站不会有任何干扰的流量。

为了模拟真实的情况，我用iMacro写了一个宏，不间断的向测试网站请求该脚本。一开始，可以看到压缩目录确实是存在的，然后我在中途手动回收了应用程序池。发现压缩缓存目录确实被删除了。

经过再细致的测试，我最终得到一个结论：

在IIS7/7.5中，如果为应用程序池配置了administrator的账号权限，那么如果在应用程序池处理静态文件压缩的时候回收应用程序池，会导致压缩缓存目录被删除。直到下次应用程序池健康重启的时候，此压缩缓存目录才会被重新创建。

这个结论我还没有得到IIS团队的证实。但在我几台机器上的IIS7和7.5测试的结果确实都是这样的。联想之前的系统日志中，每隔1-3天就出现这样的问题，刚好是因为IIS7默认的回收间隔是1740分钟，也就是1天5小时。我计算了一下系统日志中的所有关于静态压缩目录警告出现的时间，和这个回收间隔的倍数非常吻合。

解决办法有两个：

• 如果没有必要，则不要给应用程序池配置administrator的账号，使用内置的账号不会出现这样的问题。
• 禁用固定时间间隔回收，改成在一个相对空闲的固定时刻回收，例如半夜4点。

希望我奋战2个晚上得到的结论对你有所帮助~

——Kevin Yang

你可能对下面的文章感兴趣

• 64位系统下IIS7 ISAPI处理器加载失败
• Button标签鼠标点击事件的触发源问题
• IE中使用window.open打开新窗口时无法获取Referrer对象
• IIS7配置Gzip压缩
• Java/Js如何使用正则表达式匹配嵌套Html标签
• Javascript 中的false,零值,null,undefined和空字符串对象
• Javascript中获取出错代码所在文件及行数
• Javascript字符串哈希函数
• Javascript操纵Cookie
• 使用相对Url无缝切换HTTP-HTTPS

公司一台数据库服务器上部署了IIS网站（IIS7），利用Sql Server Analysis Services的msmdpump.dll组件，实现了通过HTTP层来访问Analysis Services（MSAS不支持HTTP远程访问，非HTTP的远程访问也一直没成功过）。运行状况一直良好，最近突然罢工。Debug发现在建立连接的时候总是抛出“The Connection either timed out or was lost”。

诊断

尝试用企业管理器直接连接Analysis Services，成功，数据访问也正常，说明Analysis Services服务运作正常。那看来问题是出在了IIS这一层。

直接在浏览器中通过http://machinename/olap/msmdpump.dll去访问的时候，会弹出一个保存文件的对话框。正常情况下，服务器会返回500，因为没有数据输入。现在弹出保存文件的对话框，说明IIS把这个dll资源当作一个普通文件来对待了，而不是调用ISAPI处理器来处理。

细看了网站的配置，似乎没有问题，重新部署了一个网站，重新配置了ISAPI处理器映射，问题依旧出现。

自己探索了很久，未果，Google了很久，一篇文章（IIS7 - Running 32-bit and 64-bit ASP.NET versions at the same time on different worker processes）提醒了我。这篇文章讲的是如何在不同的应用程序池进程上同时使用32位和64位的Asp.Net。

公司服务器出于性能考虑，用了64位系统。相应的msmdpump.dll文件也是64位的，但IIS的应用程序池进程是多少位的，我倒还真没考虑过。任务管理器一看，只有一个"w3wp.exe * 32”，果然是32位的。那问题的原因应该是，32位的应用程序池无法加载64位的Isapi处理器。

知道了问题所在，解决方法也很简单，启动一个64位的应用程序池就行了。打开应用程序池的高级设置，找到了“启用32位应用程序（enable32bitAppOnWin64）”的设置，将其从原来的True改成False（默认值为False）。这个选项的作用就是允许在64位操作系统上，以32位的应用程序池去加载32位的程序。

之所以会突然出现这个问题，是因为IIS的机器配置文件ApplicationHost.config文件中，全局应用程序池的enable32bitAppOnWin64默认值被意外修改为True。而我部署的IIS网站，由于没有显式设置此选项，因此会继承ApplicationHost.config文件中的默认值。

举一反三

64位系统下经常会出现一些莫名其妙的问题。因为64位系统允许运行32位应用程序，但是32位程序却无法加载64位程序集。所以如果你发现你的32位程序无法正常启动，查一查是否因为目标程序集是64位的缘故。例如最近安装了微软的StreamInsight，发现是32位的，但是本地的Sql Compact Framework是64位，结果启动的时候抛出了个DllNotFoundException。

——Kevin Yang

你可能对下面的文章感兴趣

• Analysis Services 2005 OLAP设计最佳实践
• Analysis Services：你应该使用多对多维度吗？
• BIDS部署时出现元数据管理器发生错误
• IIS7配置Gzip压缩
• IIS中使用子目录文件作为默认文档（Default Document）替代重定向
• OLAP中的AverageOfChildren聚合方式
• Silverlight启用Assembly Caching之后铁通用户无法访问
• SSAS处理时“找不到属性键”的解决办法
• 【推荐】两款HTTP流量分析工具的比较
• 为什么IIS7/7.5的Gzip不起作用

我的博客以前是摘要输出的，如果用户看到感兴趣的内容，自然会点击feed然后跳转到我的博客上继续阅读全文。但是从去年年底的时候，当用户点击feed标题跳转到我的博客上的时候，中途却被连接重置了。我看了一下被重置的Url，是feedproxy.google.com域下的。为了确认不是我自己博客的问题，我又尝试在Google Reader中点好友的博客文章，也是一样的症状。说明feedproxy.google.com又被封了。于是我就将博客改成全文输出了。当时也没多想。

今天没事的时候又突然想起了这个问题：为什么点击feed会到feedproxy.google.com而不是直接到我博客域名呢？是因为我用的是feedburner服务，所以Url被强制修改的缘故？

后来我又想起了feedburner的统计功能，它可以统计出每个feed条目都被查看和点击了多少次。难道是因为启用了这个分析功能才导致点击feed的时候先到了feedproxy再重定向到我博客的？为了验证我的想法，我在feedburner后台禁用了item link clicks统计功能，保留itemviews统计功能，重新同步了一下feed（重新同步的功能在troubleshootize菜单下）之后，刷新阅读器再次点击feed标题，果然就直接跳到我博客了，没有经过feedproxy这一步了。

貌似默认情况下是启用这两项分析的，所以估计很多用feedburner的中文博主都会遇到和我一样的问题。最好是和我一样把item link clicks功能给禁用了，那个功能可有可无吧。

——Kevin Yang

你可能对下面的文章感兴趣

• 4行Greasemonkey代码最大化Google Reader的阅读空间
• Android手机初体验
• G1手机与笔记本实现Wifi互联共享上网
• Google Analytics中的UniquePageView和Visits的区别
• Google Wave为什么这么火
• Google和微软的一大不同
• Google工程师Matt Cutts谈SEO
• Google排名更新
• Google的价值观
• Visual Studio统计有效代码行数

选快速编辑的时候，倒是有下拉框，但是只有“默认模板”这一项。

Google上搜索了半天也没发现wordpress升级的时候有这个改动或者bug。后来以为是中文版的问题，就切回英文版，结果还是不行。

在快绝望的时候，尝试了一下把主题切换回默认的，然后再换回来现在使用的主题，居然神奇地找回了失落的“模板”项。

——Kevin Yang

你可能对下面的文章感兴趣

• Dynamic Template——非常好用的Windows Live Writer动态模板插件
• WordPress评论中保留Html代码
• 博客空间迁移三步走
• 在WordPress中轻松集成Google自定义搜索引擎
• 解决WordPress自动将半角替换成全角的问题
• 让博客不用Anti-Spam插件一样没有垃圾评论