AsiaTech: 微软全球技术支持中心互联网开发支持团队官方博客

如何解决IE下载时中文文件名变乱码的问题

APGC DSI Team — Wed, 12 Oct 2011 05:36:00 GMT

问题现象

当我们使用IE浏览器下载中文文件名的文件时，先弹出“文件下载”对话框如下：

如果你点击“保存”的话，没有任何问题。但是如果你点击“打开”按钮的话，你会发现文件名变成了一串乱码，见下图

背景

文件下载功能所对应的服务端ASP.NET代码如下：

String value = "test";

Response.Clear();

Response.ClearHeaders();

Response.Buffer = false;

Response.ContentType = "application/octet-stream";

Response.ContentEncoding = System.Text.Encoding.UTF8;

String filename = HttpUtility.UrlEncode("中文.txt", System.Text.Encoding.UTF8); //对中文文件名进行HTML转码

Response.AddHeader("CONTENT-LENGTH", value.Length.ToString());

Response.AddHeader("Content-Disposition", "attachment; filename=" + filename);

Response.CacheControl = "public";

Response.Write(value);

Response.Flush();

Response.End();

环境

实际上此问题只在IE6、IE7的环境下发生，IE8以上版本没有问题

问题起因

如果你通过Fiddler之类的工具来抓取HTTP包的话，可以看到服务器段发回来的Response Header如下。

HTTP/1.1 200 OK
Server: ASP.NET Development Server/9.0.0.0
Date: Sun, 09 Oct 2011 07:32:12 GMT
X-AspNet-Version: 2.0.50727
Content-Length: 4
Content-Disposition: attachment; filename=%e4%b8%ad%e6%96%87.txt
Cache-Control: public
Content-Type: application/octet-stream
Connection: Close

实际上文件名是由Content-Disposition头里面的filename信息来决定的，这是一串经过URLEncode之后的UTF-8码，并不是乱码，它所对应的文字信息正是”中文”两个字。对于IE6、IE7来讲，在弹出“文件下载”对话框的时候IE浏览器实际上已经把文件保存在临时目录，而文件名并没有做转码，所以在临时目录里面的文件名就是%e4%b8%ad%e6%96%87[1].txt。

如果你点击“保存”按钮的话，依然是由IE浏览器在处理保存文件的工作，所以它会自动转码；而当你点击“打开”按钮的时候，IE浏览器只是负责通知相应的应用程序来打开临时目录里的文件，所以我们就看到了文件名在记事本里面显示为乱码的现象。

解决办法

我们所推荐的方式是升级到IE8或者以上版本。如果不升级，针对IE6没有任何办法，针对IE7可以采取以下方法。

1) 下载最新的IE累积补丁。可以先访问http://technet.microsoft.com/en-us/cc264855.aspx找到所有的最新安全补丁。

注意：请访问英文网站，因为中文网站有时候可能没有及时更新

从列表里面找到Cumulative Security Update for Internet Explorer，如下图

进入相关链接(在此时最新的IE补丁是Microsoft Security Bulletin MS11-057)，找到你的操作系统所对应的版本，比如我XP SP3的机器所下载的就是IE7-WindowsXP-KB2559049-x86-ENU.exe

2) 用以下命令来打补丁
IE7-WindowsXP-KB2559049-x86-ENU.exe /b:sp3qfe
注意：由于我的是XP SP3，所以/b后面对应的是sp3qfe；如果你是SP2的机器，就要用sp2qfe

3) 打完补丁添加以下注册表键值
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_ALLOW_LONG_INTERNATIONAL_FILENAMES]
"iexplore.exe"=dword:00000001

4) 重起机器再测试

Zhixing From APGC DSI Team

在SharePoint Web应用中访问Session对象时发生System.NullReferenceException异常

APGC DSI Team — Tue, 13 Sep 2011 02:18:00 GMT

我们有个客户在SharePoint Web应用中集成自定义的代码到时，经常遇到System.NullReferenceException异常。通常来说，如果程序配置成了Web Garden或者非Session Affinity的负载均衡，现象容易出现。

但这次情况有所不同。

通过.NET异常捕获，发现它是在访问Session对象的时候发生的。

000007ff`00fc2067 e8d4bb58ec call system_web_ni+0x25dc40 (000007fe`ed54dc40) (System.Web.HttpContext.get_Current(), mdToken: 060003c6)

000007ff`00fc206c 803800 cmp byte ptr [rax],0

000007ff`00fc206f 488bc8 mov rcx,rax

000007ff`00fc2072 e8511453ec call system_web_ni+0x2034c8 (000007fe`ed4f34c8) (System.Web.HttpContext.get_Session(), mdToken: 060003e2)

000007ff`00fc2077 48bb98c6a37f01000000 mov rbx,17FA3C698h

000007ff`00fc2081 488b13 mov rdx,qword ptr [rbx]

>>> 000007ff`00fc2084 803800 cmp byte ptr [rax],0

代码片段如下：

HttpContext.Current.Session["userdata"] = "123";

为了解决这类问题，我们在Web.Config中显式地将EnableSessionState设为True。

<%@ Page EnableSessionState="True" %>

并确保所有相关的单独页面不在页面的级别设置这个值为False。之后，问题依然发生，在memory dump中，System.Web.SessionState.InProcSessionState对象不再出现。

再一次检查了SharePoint的Web.Config文件，发现ASP.NET的session模块被注释掉了：

结论

==========

对于当前的SharePoint Web应用，Session对象是默认不可访问的，因为SharePoint应用会移除Session模块，并设置EnableSessionState为False。当把Session模块加回去，并在Web.Config中设置EnableSessionState为True后，抛System.NullReferenceException异常的问题就解决了。

Freist from APGC DSI Team

匿名远程访问COM+应用时被拒绝访问的问题

APGC DSI Team — Mon, 29 Aug 2011 03:23:23 GMT

有个客户在一个Win2k3的域下建立了一个COM+应用服务器，而客户端是一个工作组机器。

为了重现这个场景，我们按照以下的方式，允许以匿名的方式访问调用COM+应用：如何以匿名方式远程调用COM+，但还是在客户端出现了拒绝访问的错误。

在网络监视器中显示了拒绝访问错误（status=0x5）被返回到服务端。

客户用很多客户端在远程调用这个COM+应用，不能把它们全添加到这个域里。

我们通过以下方式进行一个快速的测试：

1.在两台机器上创建相同的用户名和密码。将COM+认证从“交互用户（Interactive User）”改变为这个测试账号。

2.在COM+应用服务器端，启用机器上的安全日志。在本地安全策略->本地策略->审计策略下，启用账号登录事件和登录事件的错误审计

在一个域控制器替代本地安全策略的情况下，我们需要检查域控制器安全策略。之后做一个”gpupdate /force”。做这个就是为了确保在安全日志里生成合适的事件日志项。

3.重演一遍这个问题，发现安全日志里有这个类型的错误：

Event Type: Failure Audit
Event Source: Security
Event Category: Logon/Logoff
Event ID: 534
Description:
Logon Failure:
Reason: The user has not been granted the requested
logon type at this machine
User Name: Domain Test User account
Logon Type: 8
Logon Process: Advapi

这里的登陆类型（Logon Type）8表示“通过网络访问此电脑”的用户权限被禁止。

4.检查Win2K3域，发现客户未被赋予普通域用户“通过网络访问此电脑”的权限。

为了修正这个错误，我们在域控制器（DC）上创建了一个测试组织单位（OU），并将这个COM+应用服务器移到测试组织单位（OU）中，确保应用于此的域组策略没有定义“通过网络访问此电脑”的用户权限。然后在这个COM+应用服务器中，打开GPEDIT.MSC，进入本地安全策略->本地策略->用户权限，给所有人（everyone）“通过网络访问此电脑”的权限。

这个方案最终可以运行正常的。

Freist from APGC DSI Team

在预编译 (Pre-Compiled) 的ASP.NET应用中页面设置失效的问题

APGC DSI Team — Mon, 29 Aug 2011 02:47:10 GMT

我的客户有一个验证视图（viewstate）MAC失败的问题。作为应急措施，他想在找出最终的解决方案之前，禁用视图MAC验证。然而当他在配置文件中添加了如下的设置后，还是有问题。

<pages validateRequest="false" enableEventValidation="false" enableViewStateMac="false" viewStateEncryptionMode="Never">

客户的应用是一个预编译 (Pre_compiled) 的ASP.NET应用，且可更新(updateable)的选项被禁用。看了由编译器通过上述设置生成的代码后，我们发现这些设置是硬编码。所以这意味着仅仅简单地在web.config里添加上述设置，并不会影响预编译的应用。为了使其生效，必须重新编译整个应用。

[DebuggerNonUserCode]

private void __BuildControlTree(default_aspx __ctrl)

{

__ctrl.EnableViewStateMac = false;

__ctrl.EnableEventValidation = false;

__ctrl.ViewStateEncryptionMode = ViewStateEncryptionMode.Never;

这是一个By-Design的行为。

ASP.NET预编译概述如下：

http://msdn.microsoft.com/en-us/library/bb398860.aspx

Wei Zhao from AGPC DSI Team

委托非管理员账号回收IIS 7远程应用池的问题

APGC DSI Team — Mon, 29 Aug 2011 02:43:06 GMT

最近客户频繁问到的一个问题是，当用户没有获得管理员权限时，是否能远程地回收一个IIS主机上的应用池。不幸的是，应用池的回收需要管理员权限才能运行。但是，通过使用MSDeploy，我们能设定recycleAPP provider作为委托，并将其运行在提升后的管理员权限下。然后，通过使用一个本地的标准用户账号或者一个IIS管理员账号，我们能在远程调用recylceApp provider，通过这个提升了权限的recycleApp provider，只要此用户在IIS里有应用池的访问权限，就能远程地回收那些应用池了。

可以通过以下步骤解决此问题：

1) 安装或确认IIS管理服务被激活。

2) 安装服务器和远程机器上最新版本的Web Deploy。相关资料见： http://www.iis.net/download/WebDeploy

3) 在服务器端的IIS中，选择管理服务。勾选“启用远程连接”，如果管理服务（WMSVC）正在停止状态，就启动它。

4) 还是在服务器端，选择管理服务委托，然后选择recycleApp provider。我在IIS的机器里建立了一个管理员账号，叫做Recycler，它将得到提升的权限，以回收应用池。

5) 还是在服务器端，选择“IIS管理员用户”并添加所需的用户。在此例中，我添加了IISUser1。现在，到你所希望被允许执行远程回收的站点，在行为面板中选择“IIS管理员权限”和“允许用户”。

6) 最后，我们现在可以从远程机器运行msdeploy命令进行测试。

msdeploy.exe -verb:sync -source:recycleApp -dest:recycleApp="Default Web Site",wmsvc=remote-computer,userName=IISManagerUserName,Password=IISManagerUserPassword,recycleMode="RecyleAppPool" –allowUntrusted

对于我们的例子，我们将运行如下：

注：如果远程机器上没有合法证书，请使用-allowUntrusted标记。这能忽略那些证书错误。

更多关于Web Deploy recycleApp provider的信息见：http://technet.microsoft.com/en-us/library/ee522997(WS.10).aspx

顺带一提，在某些情境，即使你所有配置都正确，你也可能在运行命令时看到如下的信息。

我有一个客户遇到了这个错误，通过测试能够按下面所述的步骤重现。如果没有安装IIS管理服务角色，就安装msdeploy包；或者当msdeploy在服务器上被激活，而管理服务角色被删了然后重装，缺少必要的handle。要解决此问题，只需重装msdeploy即可。

Matthew from APGC DSI Team

IE访问IIS7.5架设的需Windows认证的网站时出现不停弹框的问题

APGC DSI Team — Wed, 03 Aug 2011 05:35:22 GMT

这是一个安装了IIS的Windows 2008系统，它已运行了一些Sharepoint站点。这些Sharepoint站点使用Windows认证，且他们都正常运行。

现在在此服务器上部署了一个新的Web站点，并启用了Windows认证（采用内核态），但当通过HTTP://MyWebServer:8080或HTTP://MyWebServer.MyDomain.com:8080访问此站点时，IE会不停地请求认证。

首先，我们用域认证信息（domain credentials）测试了基本认证（basic authentication），它是成功的。然后我们启用了登陆事件的审查（audit）功能；不幸的是，不管是否成功进入了Web站点，我们都没能发现任何登陆事件的记录。

为了找出与此有关的更多信息，我们启用了IIS FREB跟踪功能，发现“IIS Web Core”设置了401状态，其错误信息是“拒绝访问”。

现在，我们不得不回来看看对Kerberos纠错最有用的信息——网络监视跟踪记录。从捕获的信息来看，我们确认了Kerberos错误是KRB_AP_ERR_MODIFIED。

有两个引发该错误的常见原因：

1. 错误的DNS设定

2. 客户端发送的ticket被用不同的密钥加密/解密。

我们用netmon确认了DNS的运行在意料之中。我们用Ldp工具审查SPN，当查询SPN时得到了如下的结果

Dn: CN=MyWebServer,……..

……

servicePrincipalName (11):

….

HOST/MyWebServer.MyDomain.com;

HOST/MyWebServer;

….

Dn: CN=SPS_Service_Account…….

….

servicePrincipalName (18):

……

HTTP/ MyWebServer.MyDomain.com;

HTTP/ MyWebServer;

……

我们能看到，HTTP/MyWebServer是SharePoint服务里注册的账号（被用来运行SharePoint应用池），运行在内核态认证的IIS 7以上服务器是不需要它的。然后回IIS MMC查看，我们发现所有SPS站点都采用用户态的Windows认证，它需要把SPN账号注册到应用池认证中。这就是SPS站点以Windows认证的方式运行的原因。

新添加的站点使用用户态Windows认证，需要在机器账号中注册的SPN的账号。这与SharePoint站点产生了冲突。

这解释了为何我们得到了KRB_AP_ERR_MODIFIED错误。当IE访问http://MyWebServer:8080时，请求HTTP/MyWebServer的ticket，它被注册在SharePoint服务的账号里。IE把该ticket传递给Web服务器。在服务器端，IIS尝试使用机器账号对该ticket解密。这必然会失败，因为它被另一个密钥解密。

为了解决此问题：

1. 我们给新添加的站点，如MySite，使用host头，将其加到站点绑定中。

2．注册SPN HTTP/MySite的本机账号

3．现在，我们使用http://MySite访问此Web站点。

随后，我们做以下SPN的配置：

MyWebServer:

HTTP/MySite

HTTP/MySite.MyDomain.com

HOST/ MyWebServer

HOST/ MyWebServer.MyDomain.com

SPS service account:

HTTP/ MyWebServer

HTTP/ MyWebServer. MyDomain.com

如下配置IIS:

	SPS 站点	MySite
SPN	HTTP/MyWebServer 注册在SPS服务账号中	HTTP/MySite 注册在机器账号MyWebServer中
绑定	所有可用的IP 无主机名	所有可用的IP 主机名: MySite
Windows 认证	用户态	内核态
应用池认证	SPS 服务账号	随意
如何访问	HTTP://MyWebServer	HTTP://MySite

顺带一提，若我们想用内核态认证（建议使用），并把SPN注册在应用池认证中，我们可以设置useAppPoolCredentials为true。这里有一个配置的例子。

<system.webServer>

</authentication>

</security>

</system.webServer>

Wei Zhao from DSI team

如何解决请求超时的HttpException异常 (ASP.NET 2.0 32-bit)

APGC DSI Team — Tue, 19 Jul 2011 06:50:00 GMT

注意：下列的步骤适用于ASP.NET 2.0(32 bit) 。没有测试过其他版本的ASP.NET。

症状

========

应用事件记录里可能出现下方的警告文字：

这种问题基本上发生在当ASP.NET的服务器端执行请求的时间超过所允许的最大时间之时。

最大超时时间可以在配置文件的httpRuntime元素的executionTimeout属性中设置。（在.Net 2.0中，默认值是110秒

如何重现

===============

创建一个ASPX页面，命名为sleep.aspx。它将睡眠20秒：

<%@ Page Language="C#" %>

<%@ import Namespace="System.Diagnostics" %>

protected void Page_Load(object sender, EventArgs e)

{

DateTime time = DateTime.Now;

Response.Write(String.Format("Time: {0}:{1}:{2}", time.Hour, time.Minute, time.Second) +

"\tCurrent process: " + Process.GetCurrentProcess().Id.ToString());

Response.Write("<BR>");

Response.Write(String.Format("This application is running in {0}", System.Environment.Version.ToString()));

System.Threading.Thread.Sleep(20000);

}

</script>

<html>

<head>

<title>ASP.NET Simple Page</title>

</head>

</body>

</html>

创建一个web.config文件，将其放在与sleep.aspx同一目录下。在此文件中设置最大超时时间为5秒。

<?xml version="1.0" encoding="UTF-8"?>

<system.web>

</system.web>

</configuration>

使用你的浏览器访问sleep.aspx，过一会儿你就将收到错误信息：“[HttpException (0x80004005): Request timed out.]”。相关的警告信息也将出现在事件日志里。

注意：

你可能发现这个错误信息——“[HttpException (0x80004005): Request timed out.]”——并没有在5秒后立即出现。ASP.NET在内部使用一个定时器（System.Threading.Timer 的一个实例）来调用取消请求的操作。这个定时器15秒触发一次。因此实际上请求可能在5秒到20秒之间的任意时间发生超时。

请参考

http://blogs.msdn.com/b/pedram/archive/2007/10/02/how-the-execution-timeout-is-managed-in-asp-net.aspx

如何捕获“[HttpException (0x80004005): Request timed out.]”的转储文件

===============================================================

当发生HttpException异常时，人们常犯的一种*错误*是设置一个debugger来监视HttpException异常，并生成转储文件。

实际上当发生请求超时之时，ASP.NET尽管显示给用户看地是HttpException，但是抛出的是ThreadAbortExceptiony异常。

为所有ThreadAbortException异常生成转储文件是不可行的。为了解决这个问题，我们必须在ThreadAboutException异常被抛出设定断点。

我用如下的步骤来捕获错误信息“[HttpException (0x80004005): Request timed out.]”的转储文件。

将下方的文本保存成aspnet_timeout.cfg，放在c:\目录下。

<keyword Name="loadbysos"> .loadby sos mscorwks </keyword>

<keyword Name="GetJIT"> !name2ee System.web.dll System.Web.RequestTimeoutManager.CancelTimedOutRequests </keyword>

<keyword Name="JITAddress"> .foreach /pS 0n12 ( record {!name2ee System.web.dll System.Web.RequestTimeoutManager.CancelTimedOutRequests}) { r $t1= ${record}; bp $t1+0x172 ".dump /ma /u ${AdpDumpDirEsc}\\Full Request timed out ${AdpProcName}_.dmp;g"; .printf"*breakpoint list*\n"; bl} </keyword>

</KeyWords>

<Option> NoDumpOnFirst </Option>

<RunMode> CRASH </RunMode>

</Settings>

<DebugActions> loadbysos; GetJIT; JITAddress </DebugActions>

</PreCommands>

</ADPlus>

用*管理员权限*打开命令行，转到Windows的Debugging工具的安装目录（默认路径为%programfiles%\Debugging Tools for Windows (x86)）

运行以下命令：

%windir%\system32\inetsrv\appcmd list wp

你将得到发生问题的应用池的工作进程的PID。

然后运行以下命令：

adplus.exe -c c:\aspnet_timeout.cfg -o <output folder> -p <pid of problematic apppool>

其中<output foder>是你想存放转储文件的存在的目录。

这样就会跳出一个cdb.exe窗口。请保持改窗口运行，因为它将会检测有问题的应用池。如果发生“请求超时”，他就会自动生成转储文件.

如何通过转储文件找到是哪个操作引发的“请求超时”

===========================================================

使用windbg打开转储文件。然后加载sos

0:025> .loadby sos mscorwks

转储（dump）当前线程堆里的所有对象，你将发现System.Threading.Thread对象:

0:025> !dso

OS Thread Id: 0x444 (25)

ESP/REG Object Name

eax 05baf5b0 System.Threading.Thread

ebx 05baf5b0 System.Threading.Thread

ecx 01c4f300 System.Web.RequestTimeoutManager+RequestTimeoutEntry

esi 01c4f300 System.Web.RequestTimeoutManager+RequestTimeoutEntry

0f1ff03c 05b33ad4 System.Web.Util.DoubleLinkList

0f1ff040 01c4b508 System.Collections.ArrayList

0f1ff044 05b3397c System.Web.RequestTimeoutManager

0f1ff064 01c4aa94 System.Threading.ContextCallback

0f1ff068 05b3397c System.Web.RequestTimeoutManager

0f1ff088 05b33b30 System.Threading._TimerCallback

0f1ff094 01c4b4e4 System.Threading.ExecutionContext

0f1ff0a0 01c4b4e4 System.Threading.ExecutionContext

0f1ff0a4 05b33b30 System.Threading._TimerCallback

0f1ff0b0 05b33b30 System.Threading._TimerCallback

0f1ff1c0 01c4b090 System.Collections.Hashtable+HashtableEnumerator

0f1ff25c 05b33b30 System.Threading._TimerCallback

0f1ff260 05b33b30 System.Threading._TimerCallback

转储（Dump） System.Threading.Thread对象中的信息，你将找到DONT_USE_InternalThread字段:

0:025> !do 05baf5b0

Name: System.Threading.Thread

MethodTable: 0e3c10f8

EEClass: 0e17d994

Size: 56(0x38) bytes

(C:\Windows\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)

Fields:

MT Field Offset Type VT Attr Value Name

0e3b1f08 400063f 4 ....Contexts.Context 0 instance 05b20528 m_Context

0e3bd818 4000640 8 ....ExecutionContext 0 instance 01c4d2c8 m_ExecutionContext

0e3c0b24 4000641 c System.String 0 instance 00000000 m_Name

0e3c0f88 4000642 10 System.Delegate 0 instance 00000000 m_Delegate

0e3ba220 4000643 14 System.Object[][] 0 instance 00000000 m_ThreadStaticsBuckets

0e3c2cc0 4000644 18 System.Int32[] 0 instance 00000000 m_ThreadStaticsBits

0e3c3720 4000645 1c ...ation.CultureInfo 0 instance 00000000 m_CurrentCulture

0e3c3720 4000646 20 ...ation.CultureInfo 0 instance 00000000 m_CurrentUICulture

0e3c0740 4000647 24 System.Object 0 instance 00000000 m_ThreadStartArg

0e3c33ec 4000648 28 System.IntPtr 1 instance 1915fa8 DONT_USE_InternalThread

0e3c2d70 4000649 2c System.Int32 1 instance 2 m_Priority

0e3c2d70 400064a 30 System.Int32 1 instance 5 m_ManagedThreadId

0e399740 400064b 16c ...LocalDataStoreMgr 0 shared static s_LocalDataStoreMgr

运行 !threads 命令列出所有线程，你将发现与引发“请求超时”有关的线程（它的操作系统线程ID是dd4）：

0:025> !threads

ThreadCount: 7

UnstartedThread: 0

BackgroundThread: 7

PendingThread: 0

DeadThread: 0

Hosted Runtime: no

PreEmptive GC Alloc Lock

ID OSID ThreadOBJ State GC Context Domain Count APT Exception

8 1 1400 018ad710 8220 Enabled 05baea40:05baf074 018ac928 0 Ukn

19 2 132c 018b8658 b220 Enabled 00000000:00000000 018ac928 0 MTA (Finalizer)

22 3 16ec 018d7718 80a220 Enabled 00000000:00000000 018ac928 0 MTA (Threadpool Completion Port)

23 4 830 018d7ee8 1220 Enabled 00000000:00000000 018ac928 0 Ukn

24 5 dd4 01915fa8 380b220 Enabled 01c57b44:01c58fe8 018d8590 1 MTA (Threadpool Worker)

25 6 444 01923d00 180b220 Disabled 01c4b604:01c4d008 018d8590 0 MTA (Threadpool Worker)

14 7 180 01933348 880a220 Enabled 00000000:00000000 018ac928 0 MTA (Threadpool Completion Port)

切换到那个有问题的线程，列出调用栈。你将发现sleep函数:

0:025> ~~[dd4]s

eax=0000002d ebx=00000000 ecx=00004e20 edx=00000000 esi=0edced40 edi=00000000

eip=777f96f4 esp=0edcecfc ebp=0edced64 iopl=0 nv up ei pl nz na po nc

cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202

ntdll!KiFastSystemCallRet:

777f96f4 c3 ret

0:024> !clrstack

OS Thread Id: 0xdd4 (24)

ESP EIP

0edcee4c 777f96f4 [HelperMethodFrame: 0edcee4c] System.Threading.Thread.SleepInternal(Int32)

0edceea0 015806e1 ASP.sleep_aspx.Page_Load(System.Object, System.EventArgs)

0edceedc 6d59a7ff System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr, System.Object, System.Object, System.EventArgs)

0edceeec 62562544 System.Web.Util.CalliEventHandlerDelegateProxy.Callback(System.Object, System.EventArgs)

0edcef00 6255ba44 System.Web.UI.Control.OnLoad(System.EventArgs)

0edcef14 6255ba83 System.Web.UI.Control.LoadRecursive()

0edcef2c 62557b34 System.Web.UI.Page.ProcessRequestMain(Boolean, Boolean)

0edcf084 62557764 System.Web.UI.Page.ProcessRequest(Boolean, Boolean)

0edcf0bc 62557691 System.Web.UI.Page.ProcessRequest()

0edcf0f4 62557626 System.Web.UI.Page.ProcessRequestWithNoAssert(System.Web.HttpContext)

0edcf100 62557602 System.Web.UI.Page.ProcessRequest(System.Web.HttpContext)

0edcf114 01580455 ASP.sleep_aspx.ProcessRequest(System.Web.HttpContext)

0edcf118 6255dad6 System.Web.HttpApplication+CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()

0edcf14c 6253132c System.Web.HttpApplication.ExecuteStep(IExecutionStep, Boolean ByRef)

0edcf18c 62b2583f System.Web.HttpApplication+PipelineStepManager.ResumeSteps(System.Exception)

0edcf190 62b1b96c [InlinedCallFrame: 0edcf190]

0edcf230 62b06071 System.Web.HttpRuntime.ProcessRequestNotificationPrivate(System.Web.Hosting.IIS7WorkerRequest, System.Web.HttpContext)

0edcf2a0 62bdb5e6 System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr, IntPtr, IntPtr, Int32)

0edcf2a4 62bdb7d7 [InlinedCallFrame: 0edcf2a4]

0edcf7f8 005522b4 [NDirectMethodFrameStandalone: 0edcf7f8] System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr, System.Web.RequestNotificationStatus ByRef)

0edcf808 62bdb67d System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr, IntPtr, IntPtr, Int32)

0edcf88c 62bdb7d7 System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr, IntPtr, IntPtr, Int32)

0edcf98c 005522b4 [ContextTransitionFrame: 0edcf98c]

Xinjin from APAC DSI

为什么第一次访问ASP.NET应用会很慢

APGC DSI Team — Mon, 25 Apr 2011 02:00:00 GMT

问题现象

==========

ASP.NET页面第一次访问的时候很慢，时间可以持续几十秒到几分钟

问题原因

==========

当程序里面需要调用到一些Authenticode Signed的.NET Assembly的时候，它需要连接到外网来验证数字证书。当服务器是无法连接到外网时，这个校验证书的过程需要等到timeout之后才会结束。

解决办法

==========

建议采用以下方法中的任何一种

让您的服务器能连接到外网
参考http://support.microsoft.com/kb/936707的方法来禁止证书的验证过程

请同时在以下两个aspnet.config文件中加入以下内容。

C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet.config

C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet.config

<?xml version="1.0" encoding="utf-8"?>

<configuration>

<runtime>

<generatePublisherEvidence enabled="false"/>

</runtime>

</configuration>

或者参考http://blogs.msdn.com/b/tom/archive/2008/10/28/web-site-stops-responding-for-15-25-seconds.aspx对"Network Service"帐号下运行的所有程序禁止证书检查

导入以下注册表键值并重起IIS服务

Windows Registry Editor Version 5.00

[HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing]

"State"=dword:00023e00

详细分析

==========

这个时候如果我们抓取一个hang dump的话，页面所对应的managed callstack往往如下，很明显它正在加载一个Assembly

0:022> !CLRStack

OS Thread Id: 0xeb4 (22)

Child-SP RetAddr Call Site

000000001af1c900 000007fef91747c3 System.Reflection.Assembly.InternalLoad(System.Reflection.AssemblyName, System.Security.Policy.Evidence,

System.Threading.StackCrawlMark ByRef, Boolean)

000000001af1c990 000007ff0141f0f9 System.Reflection.Assembly.Load(System.Reflection.AssemblyName)

000000001af1c9d0 000007fef9fdd502 Microsoft.SharePoint.Portal.WebControls.StringResourceManager..cctor()

000000001af1db50 000007ff014135e2 Microsoft.SharePoint.Portal.WebControls.MySiteLinkUserControl.SetControl()

000000001af1dce0 000007fef398e04f Microsoft.SharePoint.Portal.WebControls.MySiteLinkUserControl.OnInit(System.EventArgs)

000000001af1de80 000007fef398f3af System.Web.UI.Control.InitRecursive(System.Web.UI.Control)

000000001af1dee0 000007ff014133c8 System.Web.UI.Control.AddedControl(System.Web.UI.Control, Int32)

000000001af1df50 000007ff0134115e Microsoft.SharePoint.WebControls.DelegateControl.AddControlResilient(System.Web.UI.Control)

000000001af1dff0 000007fef398fb22 Microsoft.SharePoint.WebControls.DelegateControl.CreateChildControls()

000000001af1e170 000007ff01341024 System.Web.UI.Control.EnsureChildControls()

000000001af1e1d0 000007fef398e04f Microsoft.SharePoint.WebControls.DelegateControl.OnInit(System.EventArgs)

000000001af1e210 000007fef398e147 System.Web.UI.Control.InitRecursive(System.Web.UI.Control)

000000001af1e270 000007fef398e147 System.Web.UI.Control.InitRecursive(System.Web.UI.Control)

000000001af1e2d0 000007fef398e147 System.Web.UI.Control.InitRecursive(System.Web.UI.Control)

000000001af1e330 000007fef398e147 System.Web.UI.Control.InitRecursive(System.Web.UI.Control)

000000001af1e390 000007fef398e147 System.Web.UI.Control.InitRecursive(System.Web.UI.Control)

000000001af1e3f0 000007fef398a935 System.Web.UI.Control.InitRecursive(System.Web.UI.Control)

000000001af1e450 000007fef398a1f0 System.Web.UI.Page.ProcessRequestMain(Boolean, Boolean)

000000001af1e520 000007fef398a11b System.Web.UI.Page.ProcessRequest(Boolean, Boolean)

000000001af1e580 000007fef398a0b0 System.Web.UI.Page.ProcessRequest()

000000001af1e5e0 000007fef3991557 System.Web.UI.Page.ProcessRequest(System.Web.HttpContext)

000000001af1e640 000007fef395567b System.Web.HttpApplication+CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()

000000001af1e6f0 000007fef39634b5 System.Web.HttpApplication.ExecuteStep(IExecutionStep, Boolean ByRef)

000000001af1e790 000007fef3954733 System.Web.HttpApplication+ApplicationStepManager.ResumeSteps(System.Exception)

000000001af1e840 000007fef3958a54 System.Web.HttpApplication.System.Web.IHttpAsyncHandler.BeginProcessRequest(System.Web.HttpContext, System.AsyncCallback,

System.Object)

000000001af1e8a0 000007fef395863c System.Web.HttpRuntime.ProcessRequestInternal(System.Web.HttpWorkerRequest)

000000001af1e930 000007fef395726c System.Web.HttpRuntime.ProcessRequestNoDemand(System.Web.HttpWorkerRequest)

000000001af1e970 000007fef9fdd502 System.Web.Hosting.ISAPIRuntime.ProcessRequest(IntPtr, Int32)

其实它所要加载的Assembly名字如下

Microsoft.SharePoint.Portal.intl

此线程所对应的native callstack如下

0:022> k20

Child-SP RetAddr Call Site

00000000'1af1a208 000007fe'fdc610ac ntdll!ZwWaitForSingleObject+0xa

00000000'1af1a210 000007fe'f5dfa2fa KERNELBASE!WaitForSingleObjectEx+0x79 00000000'1af1a2b0 000007fe'f5df76fa cryptnet!CryptRetrieveObjectByUrlWithTimeout+0x263

00000000'1af1a5b0 000007fe'f5df4646 cryptnet!CryptRetrieveObjectByUrlW+0x20f 00000000'1af1a7a0 000007fe'f5df9c34 cryptnet!RetrieveObjectByUrlValidForSubject+0x162 00000000'1af1a8d0 000007fe'f5df4243 cryptnet!RetrieveTimeValidObjectByUrl+0x2de 00000000'1af1a9c0 000007fe'f5df3c72 cryptnet!CTVOAgent::GetTimeValidObjectByUrl+0x2e3 00000000'1af1ab20 000007fe'f5df38ad cryptnet!CTVOAgent::GetTimeValidObject+0x7cf

00000000'1af1ad00 000007fe'f5df3810 cryptnet!FreshestCrlFromCrlGetTimeValidObject+0x61

00000000'1af1ad70 000007fe'f5df99fc cryptnet!CryptGetTimeValidObject+0xb0 00000000'1af1adf0 000007fe'f5df345d cryptnet!GetTimeValidCrl+0x4b7

00000000'1af1af30 000007fe'f5df3f82 cryptnet!GetBaseCrl+0x7d 00000000'1af1afc0 000007fe'f5df3d58 cryptnet!MicrosoftCertDllVerifyRevocation+0x238

00000000'1af1b110 000007fe'fdb157c7 cryptnet!CertDllVerifyRevocation+0x28

00000000'1af1b160 000007fe'fdb1552e crypt32!VerifyDefaultRevocation+0x398 00000000'1af1b250 000007fe'fdb15c09 crypt32!CertVerifyRevocation+0x144

...

00000000'1af1bcc0 000007fe'f9e46c27 mscorwks!PEFile::CheckSecurity+0x39b924

00000000'1af1bd50 000007fe'f9e5eb5d mscorwks!PEAssembly::DoLoadSignatureChecks+0x37

00000000'1af1bd90 000007fe'f9e52ff8 mscorwks!PEAssembly::PEAssembly+0x12d 00000000'1af1be00 000007fe'f9e40b9d mscorwks!PEAssembly::DoOpen+0x11c 00000000'1af1c130 000007fe'f9f24a3e mscorwks!PEAssembly::Open+0x71

从这些函数名我们知道它正在做一些证书检查之类的事情。而实际上它正在等待下面的这个线程。

0:036> kn

# Child-SP RetAddr Call Site

00 00000000'2409e1c8 000007fe'fdc610ac ntdll!ZwWaitForSingleObject+0xa

01 00000000'2409e1d0 000007fe'f5d7f38e KERNELBASE!WaitForSingleObjectEx+0x79

02 00000000'2409e270 000007fe'f5d80a27 winhttp!IsWpadEnabledForConnectedNetworks+0x1f2

03 00000000'2409e340 000007fe'f5d806dc winhttp!ReadWinInetProxySettings+0x1c3

04 00000000'2409e3c0 000007fe'f5dfae42 winhttp!WinHttpGetIEProxyConfigForCurrentUser+0x28a

05 00000000'2409e510 000007fe'f5df9237 cryptnet!InetGetProxy+0x11e

06 00000000'2409e600 000007fe'f5df983d cryptnet!InetSendAuthenticatedRequestAndReceiveResponse+0x190

07 00000000'2409f770 000007fe'f5df9d9c cryptnet!InetSendReceiveUrlRequest+0x57e

.....

0:036> .frame 7

07 00000000'2409f770 000007fe'f5df9d9c cryptnet!InetSendReceiveUrlRequest+0x57e [d:\w7rtm\ds\security\cryptoapi\pki\rpor\inetsp.cpp @ 2603]

0:036> dv

hInetSession = 0x00000000'218211f0

pwszUrl = 0x00000000'1f8abe50 "http://crl.microsoft.com/pki/crl/products/CSPCA.crl"

dwRetrievalFlags = 1

pCredentials = 0x00000000'00000000

pcba = 0x00000000'2409fab0

ppfnFreeObject = 0x00000000'2409fb38

ppvFreeContext = 0x00000000'2409fb30

pAuxInfo = 0x00000000'1f8abd78

phInetRequest = 0x00000000'00000000

我们可以看到，当时我们抓取dump的时候它正在尝试连接http://crl.microsoft.com/pki/crl/products/CSPCA.crl

Zhi Xing - 微软APAC技术支持中心 Internet Developer Support Team

如何用IIS Web Portal管理windows user password

APGC DSI Team — Fri, 22 Apr 2011 02:38:01 GMT

大多IIS用户都可能还记得我们曾经用老的版本的IIS（例如IIS 5或者IIS 6）架设的叫做IISADMPWD的web application。这个应用对domain user更改密码很有用。可能很多人还在想既然我可以通过简单的Ctrl+Alt+Delete来更改密码，那这个还有什么用呢？我们先来看一个例子。

IISAPDPWD in Use

当我不在办公室的时候必须要通过OWA来收发邮件。然而，由于我忘记更新我的密码而且它已经过期，我没有能够成功的收到重要邮件。（VPN可能能够帮我解决，但是如果我同样不能连接VPN）

IT部门帮助我设置了IISADMPWD，这样我就可以进入一个页面来更改我的密码。现在OWA又恢复了正常，我也能够成功的检查到邮件！

IISAPDPWD Setup（for IIS 5/6）

下面文章可以帮助我们在IIS 5和6设置这样一个web application。

http://support.microsoft.com/kb/269082

http://support.microsoft.com/kb/833734

Tony DeCock提供了一篇文章，介绍可能在此过程中碰到的各种问题。

http://support.microsoft.com/kb/907271

IISAPDPWD on IIS 7

IIS 7中不再有IISAPDPWD这个功能。因此在Windows Server 2008下也没有IISADMPWD目录。这样除了使用VPN，我们还有别的办法来更改密码么？事实上如果我们从Windows Server 2003 box上拿到一份IISADMPWD的copy并且把它作为一个ASP/COM应用来使用，它也是可以帮助我们来更改密码的。解决方案如下：

1. 复制Server 2003 box到Server 2008 box，在这边我用的是C:\Windows\system32\inetsrv\Iisadmpwd on Server 2008。
2. 在IISADMPWD目录下注册IISpwchg.dll文件
a. 打开一个命令运行栏。
b. 在Open box中，输入下述命令后按Enter：regsvr32 c:\windows\system32\inetsrv\iisadmpwd\iispwchg.dll
3. 配置PasswordChangeFlags特性，注意Password Change功能必须开启：
a. 打开一个命令运行栏。
b. 进入C:\Inetpub\Adminscripts目录（注意IIS 6 Scripting Tools feature必须打开）
c. 输入以下命令，按enter：

cscript.exe adsutil.vbs set w3svc/passwordchangeflags Value

注意这里Value为你所设置的PasswordChangeFlags的位置标识符，有如下几个数值，也可以使用它们的组合数值：

0:默认值。这个值表明当你试图更改密码的时候一定要使用安全网路连接（SSL）
1：这个值允许对non-secure端口进行密码更改。如果SSL被禁用的话可以使用这个值。
2：这个值禁用了密码更改功能。
4：这个值禁用了密码过期提示。
4. 在IISADMPWD目录下创建一个应用：
a. 打开IIS Manager，左边面板右键Default Web Site节点。
b. 选中Add Application。在对话框中，输入alias（我用的是IISADMPWD）和路径（C:\Windows\system32\inetsrv\Iisadmpwd）。然后选中Select来选择一个合适的application pool，点击两次OK就可以了。
5. 现在就可以进入password change的页面：http://<server>/iisadmpwd/aexp4b.asp（或者https的页面）

注释：

如果只有x86版本的Server 2003，但是Server 2008却是x64版本，上诉步骤要稍作修改：首先，必须复制文件到%windir%\SysWOW64\inetsrv文件夹中，这个路径也要在之后介绍的步骤中用到。然后，application必须在一个32-bit的application pool中。

微软全球技术支持中心Internet 开发者支持组

如何用Indexing Service来对Windows Server 2008中的IIS 7.0网站进行索引

APGC DSI Team — Fri, 22 Apr 2011 02:31:07 GMT

根据如下步骤进行操作：

安装IIS 6 Management Compatibility

=============================

点击Start->All Programs->Administrative Tools, 之后点击ServerManager
在Console tree of Server Manager, 展开Roles，之后右键Web Server（IIS），点击Add Role Services
在Add Role Service Wizard中，选择IIS 6 management compatibility, 然后点击Next
按照Add Role Service Wizard中的instruction来完成安装

选择你要找的 web site

==============================

在Indexing MMC中右键点击你的catalog选择Properties
点击Tracking tab
在"WWW Server"下拉列表中选择web site
点击OK
如果再次打开property页面，你可以看到"WWW Server"区域还是空的，这个只是一个UI的问题。
为验证是否选择了这个web site，检查下苏注册表的值：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ContentIndex\Catalogs\[Catalog Name]

IsIdexingW3Svc

W3SvcInstance

IsIdexingW3Svc的值应该是1，W3SvcInstance应当是所选的web site instance

设置ContentIndexed metabase property

==============================

在windows 2003中如果想要索引一些webpage的话可以在virtual directory中选择"Index this resource"。但是在windows 2008中没有相关选项的管理界面。必须要使用下述命令：

打开命令行，指向当前目录%systemdrive%\inetpub\adminscripts。
运行命令：cscript adsutil.vbs set w3svc/[web site instance]/root/[virtual director]/ContentIndexed 1
例如如果想开启虚拟目录MyVIR of the default web site 的"Index this resource"功能，运行cscript adsutil.vbs set w3svc/1/root/MyVIR/ContentIndexed 1

在开启上诉功能后，就可以重启Indexing Service，Indexing Service会自动检查IIS配置并生成catalog。

XinJin

-微软全球技术支持中心Internet 开发者支持组

如何在IIS 6.0中使用256 bit SSL

APGC DSI Team — Fri, 22 Apr 2011 02:26:00 GMT

3个步骤：

1. 安装此修复程序http://support.microsoft.com/kb/948963，以支持AES128加密和AES256加密。
2. Cipher suites的顺序在Windows 2003命令是固定好的， AES 128是最高优先级的，AES 256排在其后。我们只需要禁用AES 128而开启AES 256使得AES 256拥有最高的优先权。
a. 在IIS6.0中打开regedit.exe的机器。
b. 进入HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers，应该能够发现有很多子项，例如AES 128/128。
c. 在子项的AES 128/128，创建一个DWORD值"启用"，将其设置为值0。这意味着我们将禁用AES 128。
3. 重新启动IIS 6.0的机器。

这对支持AES 256的Vista/Windows7机器，可以使用IE浏览IIS6.0 HTTPS网站，这里的SSL使用256位加密。

Xin Jin

-微软全球技术支持中心Internet 开发者支持组

由string.IndexOf引起的ASP.Net应用挂起

APGC DSI Team — Wed, 02 Mar 2011 01:32:00 GMT

最近有一个有趣的案例，我们发现String.IndexOf会造成ASP.Net应用挂起。

问题描述：

通常这种ASP.Net应用程序将挂起，因此IIS工作进程需要重新启动使得应用程序能够正常运行。即使当负载比较低的时候也会发生这种情况。

排除故障：

像以前一样，我们抓获挂起dump，我们可以看到几乎请求都会被GC阻止。下面是一个示例调用堆栈。

ntdll!ZwWaitForSingleObject

kernel32!WaitForSingleObjectEx

mscorwks!CLREventWaitHelper

mscorwks!CLREvent::WaitEx

mscorwks!SVR::gc_heap::wait_for_gc_done

mscorwks!SVR::gc_heap::try_allocate_more_space

…

Some customer code here

…

System_Web_ni!System.Web.Hosting.ISAPIRuntime.ProcessRequest(IntPtr, Int32)

但是，如果去查看一下GC线程，发现他们根本不在GC状态。之后我们发现线程48禁用了PreEmptive GC，不允许GC来暂停它。所以GC必须等到这个线程结束。

PreEmptive Lock

ID OSID ThreadOBJ State GC GC Alloc Context Domain Count APT Exception

24 1 1e48 000000000015f280 1808220 Enabled 00000000902c9e50:00000000902c9e70 00000000001bbbe0 1 MTA (Threadpool Worker)

……………………

48 8 2070 00000000091043e0 180b222 Disabled 0000000000000000:0000000000000000 00000000001bbbe0 1 MTA (Threadpool Worker)

………………..

线程48正在替换strings。

mscorwks!COMStringBuffer::LocalIndexOfString

mscorwks!COMString::ReplaceString

MyAssembly!MyFunction.RemoveSpaces(System.String)

然后线程 48占用了所有CPU.

0:048> !runaway

User Mode Time

Thread Time

48:2070 0 days 0:01:02.468

52:20b8 0 days 0:00:16.359

34:1ef0 0 days 0:00:16.171

….

如果我们dump出字符串，它是非常小的字符串，其中只包含200个字符。替换字符串里面的东西不应该花费这么长的时间。代码下面，它试图用单个空格替换所有连续的空格。其实，字符串中已经没有连续空格。此外，在这里我们不需要while循环，因为String.Replace会返回一个新字符串，其中在这个新字符串当前所有与指定的字符串匹配的字符串会被替换为指定字符串。此时我怀疑while循环是无法终止的。

if ((str != null) && (str.Length != 0))

{

while (str.IndexOf(" ") != -1) // as long as there are two continuous spaces

{

str = str.Replace(" ", " "); //replace it with single space

}

看看此字符串的十六进制值，我找到了异常：字符串里面有一个特殊的字符0xfffd。

0:048> dd 801fc6d8

00000000`801fc6d8 0041004d 00200058 0020fffd 00680054

此后我用下面代码重现了问题。.IndexOf总是返回0x0而不是所希望的-1。

char[] test= {'\u0020', '\ufffd', '\u0020'};

string testStr = new string(test);

int i = testStr.IndexOf(" ");

0xFFFD是一个特殊的Unicode字符。U+FFFD(“ �”)是未知或不可打印字符的替换字符。为安全起见，在一个Unicode文本中的无效字节被替换为U+ FFFD，即Unicode替换字符。例如，字符串“Ad\ xD800min\ xDC00istrator“将改为“广告\ xFFFDmin\ xFFFDistrator“这个字符串解码为“Ad�min�istrator“，其中“ �”是Unicode替换字符0xFFFD。

原因在于“String.Replace”执行了顺序的（culture-insensitive）搜索，这里当Unicode标值一样时，两个字符是被认为是等价的。但是“IndexOf（string）”方法用当前的culture执行了case-sensitive和culture-sensitive的字符搜索。为了解决这个无限循环的问题，我们应该使用string.IndexOf("AA", StringComparison.Ordinal);

static void Main(string[] args)

{

char[] test = { '\u0020', '\ufffd', '\u0020' }; // A string "� "

string testStr = new string(test);

int i = testStr.IndexOf(" ", StringComparison.Ordinal); //This returns 0x0 which means “ ”(two spaces) was found at position 0x0

while (i != -1)

{

testStr = testStr.Replace(" ", " "); //replace two continuous spaces with single space.

i = testStr.IndexOf(" ", StringComparison.Ordinal);

}

可以参考“Remarks”一栏获取更多相关信息：

String::IndexOf Method (String)

http://msdn.microsoft.com/en-us/library/k8b1470s(v=VS.90).aspx

String.Replace Method (String, String)

http://msdn.microsoft.com/en-us/library/fk49wtc1(v=VS.80).aspx

当一个进程中加载多个.NET Runtime的时候如何在托管调试中加载指定的mscordacwks.dll

APGC DSI Team — Wed, 02 Mar 2011 01:20:00 GMT

当多个.NETRuntime加载在一个目标进程或一个dump文件中，例如：

0:030> lm

start end module name

00000000'1b6d0000 00000000'1b9ba000 System_Data (deferred)

...

000007fe'f3e60000 000007fe'f47c5000 clr (deferred)

...

000007fe'f9880000 000007fe'fa230000 mscorwks (deferred)

...

0:030> lmvm clr

start end module name

000007fe'f3e60000 000007fe'f47c5000 clr (deferred)

Image path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll

Image name: clr.dll

......

CompanyName: Microsoft Corporation

ProductName: Microsoft® .NET Framework

InternalName: clr.dll

OriginalFilename: clr.dll

ProductVersion: 4.0.30319.1

FileVersion: 4.0.30319.1 (RTMRel.030319-0100)

PrivateBuild: DDBLD431

FileDescription: Microsoft .NET Runtime Common Language Runtime - WorkStation

Comments: Flavor=Retail

0:030> lmvm mscorwks

start end module name

000007fe'f9880000 000007fe'fa230000 mscorwks (deferred)

Image path: C:\Windows\Microsoft.NET\Framework64\v2.0.50727\mscorwks.dll

Image name: mscorwks.dll

.......

CompanyName: Microsoft Corporation

ProductName: Microsoft® .NET Framework

InternalName: mscorwks.dll

OriginalFilename: mscorwks.dll

ProductVersion: 2.0.50727.4206

FileVersion: 2.0.50727.4206 (VistaSP2GDR.050727-4200)

FileDescription: Microsoft .NET Runtime Common Language Runtime - WorkStation

Comments: Flavor=Retail

.NET runtime 4.0中的clr.dll 和.NET runtime 2.0中的mscorwks.dll加载在一个进程中，托管调试可能会为错误的结果，如下面所示：

0:030> .loadby sos mscorwks

0:030> !clrstack

OS Thread Id: 0x2674 (30)

Unable to walk the managed stack. The current thread is likely not a managed thread. You can run !threads to get a list of managed threads in the process

其实线程30是一个托管线程，是.NET 2.0 的托管线程，但不是.NET 4.0的托管线程。

如果通过使用.cordll 来加载托管调试模块 mscordacwks.dll，如下所示，可以看到调试器总是会默认尝试为最新的.NET runtime加载mscordacwks.dll，在我们的示例里面是.NET runtime 4.0 运行库，这就是解释了为什么.NET runtime 2.0托管线程不能被正常调试。

0:030> .cordll -ve -u -l

CLRDLL: Loaded DLL C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscordacwks.dll

CLR DLL status: Loaded DLL

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\mscordacwks.dll

在这种情况下如何加载指定的 mscordacwks.dll来进行托管调试？例如，加载托管调试模块.NET runtime 2.0的 mscorwks.dll 吗？假定匹配的 mscordacwks.dll 复制到文件夹 c:\tempzhong ，下列两个命令可以用来加载模块的托管调试：

.cordll -ve -se -u -I <Start address of the target .NET runtime module> -N

或者

.cordll -ve -se -u -I <Start address of the target .NET runtime module> -lp <path of the managed debugging module>

在我们的示例中，该命令为：

*note* -N switch causes the debugger to search the matched mscordacwks.dll in the configured symbol path. -lp switch causes the debugger to load the matched mscordacwks.dll from the specified path.

0:030> .cordll -ve -se -u -I 000007fe'f9880000 -N

CLRDLL: C:\Windows\Microsoft.NET\Framework64\v2.0.50727\mscordacwks.dll:2.0.50727.4952 f:0

doesn't match desired version 2.0.50727.4206 f:0

CLRDLL: Loaded DLL

\\SymbolShare\websymbols\mscordacwks_AMD64_AMD64_2.0.50727.4206.dll\4BF4C1819b0000\mscordacwks_AMD64_AMD64_2.0.50727.4206.dll

CLR DLL status: Loaded DLL

\\SymbolShare\websymbols\mscordacwks_AMD64_AMD64_2.0.50727.4206.dll\4BF4C1819b0000\mscordacwks_AMD64_AMD64_2.0.50727.4206.dll

....

或者

0:030> .cordll -ve -se -u -I 000007fe'f9880000 -lp c:\temp

CLRDLL: Loaded DLL c:\temp\mscordacwks.dll

CLR DLL status: Loaded DLL c:\temp\mscordacwks.dll

现在，通过执行托管调试命令可以得到正确结果。

0:030>.loadby sos mscorwks

0:030> !clrstack

OS Thread Id: 0x2674 (30)

(!clrstack processes a max of 1000 stack frames)

Child-SP RetAddr Call Site

0000000005fb71a0 000007fef6fc79b5 System.Net.Sockets.Socket.MultipleSend(System.Net.BufferOffsetSize[], System.Net.Sockets.SocketFlags)

0000000005fb7290 000007fef6fc747b System.Net.Sockets.NetworkStream.MultipleWrite(System.Net.BufferOffsetSize[])

0000000005fb7310 000007fef6fc7381 System.Net.ConnectStream.ResubmitWrite(System.Net.ConnectStream, Boolean)

0000000005fb73c0 000007fef6fc7240 System.Net.HttpWebRequest.EndWriteHeaders_Part2()

......

高性能ASP.NET应用程序（2）——ASP.NET缓存简介

APGC DSI Team — Fri, 25 Feb 2011 01:55:10 GMT

上次我们介绍了ASP.NET应用程序状态管理方面的一些内容。今天，我们将继续上次关于编写高性能ASP.NET程序的话题，探讨一下ASP.NET的缓存机制。在编写ASP.NET应用程序时,能否有效地利用缓存对于程序的响应时间和资源管理方面至关重要。这一次，我们将讨论以下四个部分：

1）正确地使用缓存API

2）利用输出缓存和片段缓存

3）缓存在Web Farm中的应用

4）有效应用缓存方面的一些建议

缓存API非常简单并易于使用，但仍然有一些情况下，你应该避免使用它们。例如，如果你要缓存的数据是特定于某个用户的，那么还是保存在会话状态中为好。如果某些数据更新非常频繁，那么这些数据在缓存中也不会被保存很久，因此缓存这样的数据对性能提高没有任何好处。我想提请您特别注意一下的是AddValidationCallback。这个函数在当你想为不同的客户定制缓存数据时是非常有用的。下面的代码演示了如何使用AddValidationCallback来依据输入的查询字符串自定义请求的处理过程的。

HttpContext ctx = HttpContext.Current;

static string validationstate;

public void Page_Load()

{

Response.Cache.AddValidationCallback(new HttpCacheValidateHandler(ValidateCache), null);

ctx.Response.Write("");

}

public static void ValidateCache(HttpContext context, Object data, ref HttpValidationStatus status)

{

if (context.Request.QueryString["Customer"] != "Bob")

{

status = HttpValidationStatus.IgnoreThisRequest;

context.Response.Write("You are not Bob. Your request will be handled explicitly.");

}

else

{

status = HttpValidationStatus.Valid;

context.Response.Write("Respond with cached data");

}

</script>

有三种缓存过期策略可供选择，这使得您可以更有效的利用缓存机制。绝对过期策略，这种策略会指定一个绝对的日期和时间，某个对象一旦过期便会被从缓存中删除；滑动过期策略，如果某个对象在超过指定的时间间隔之后仍未被试用，那么它便会过期并从缓存中删除；依赖过期策略，缓存的对象可能被关联到某个资源，那么只有在这个关联的资源发生变化时才会导致对象过期。例如一个对象关联了磁盘上的某个文件，那么该对象将保留在缓存中，一直到该文件内容发生变化时为止。有一点需要注意的是，你不能将绝对过期策略和滑动过期策略一起使用，而虽然你可以将依赖过期策略和绝对或者滑动过期策略一起使用，但我们并不推荐这样做。

输出缓存是一种强大的技术，通过缓存从动态页面生成的内容该技术能够显著提高程序的请求/响应吞吐量。它使得您可以将整个页面的内容缓存一段指定的时间。因此当动态生成的网页不包含用户特定的数据时请考虑到使用输出缓存。另外应该考虑为生成起来比较耗时但有经常访问的内容启用输出缓存，例如报表。比如生成一个报表需要花去你1分钟时间，而它由仅包含少量的变化，那么这个报表便是一个很好的缓存候选。但是，应该避免在下列这些情况下使用输出缓存：

1．您需要以编程方式访问页面上的数据。使用缓存API。

2．该网页包含大量的变量。

3．该网页包含混合类型的数据：静态的，动态的还有用户特定的。在这种情况下，使用片段缓存机制为好。

4．每次请求都会更新的网页。

片段缓存机制可以通过使用用户控件配合@OutputCache指令来实现。当一个页面中的混合有不同种类的数据时，应该通过用户控件来将你的页面划分为若干个独立的逻辑模块。一些适宜采用片段缓存机制的情形包括：非用户特定的导航菜单，以及页眉/页脚这种通常不需要在每个视图刷新的静态内容。

同会话状态管理类似，缓存的管理，在Web Farm的情形下也变得比单独服务器时更加复杂。基本上，你有三种方案可供选择：

1. 在Web Farm同步所有节点。这种方式简单，快捷，优雅。我们只需简单的为程序增加一些处理逻辑，使得当任何缓存操作（API）发生时我们只是通过遍历节点并把Web请求转发到每一个节来同步所有节点上的缓存。如果它不是一个简单对象，你必须考虑到串行化的问题。

2. 集中式缓存。你可以通过Web服务组件来设计一个集中式的缓存：1）确定什么样的信息需要被缓存。例如，假设你的应用程序生成了一个大型数据集集合，用于为每个用户提供相同的首页2）创建一个Web服务，其中包含一个生成这个大数据集的方法。3）编译此Web服务和并安装到Web Farm可以访问的一个服务器上。理想的情况下，这个服务器应该在同一个域，并在同一物理网络，以尽量减少通信时间。4）在你的程序中代码添加一个Web引用到以从此Web服务中获得这个大数据集。

3. SQL服务器缓存。SQL Server是强大的，尤其是当你需要应对跨进程的持久性数据回收，服务器重新启动，电源故障/系统崩溃这样的事情时。如果你的应用程序需要这样的数据保护，那么基于例如SQL Server这样的持久性数据存储的缓存机制应该足以满足的需求了。

当您编写ASP.NET应用程序时，请务必记住牢记以下一些规则：

1. 使用用户控件来分割您的网页。隔离动态数据和静态数据，以便能够应用片段缓存。

2. 配置内存限制，以避免造成任何内存问题。参考：http://msdn.microsoft.com/en-us/library/7w2sway1（VS.71）aspx。

3. 使用Location属性选择合适的位置来缓存你的数据。 http://msdn.microsoft.com/en-us/library/system.web.ui.outputcachelocation(v=VS.71).aspx

4. 使用VaryBy。VaryBy属性决定了数据是否被缓存。下面的示例显示了如何使用VaryBy属性。

<%@ OutputCache Duration="30" VaryByParam="a" %>

在上面示例中所示的设置使得以下页面具有相同的缓存版本：

如果您添加b到VaryByParam属性，你将有三个不同版本的网页，而不是一个版本。

当你决定使用VaryBy属性时，确保有一个有限数量的变化，因为每个变化都增加了对Web服务器上的内存消耗。

以上就是一些我想分享的关于ASP.NET缓存的经验。根据我的经验的基础上，即使有经验的.NET开发人员也经常会在ASP.NET缓存方面失误，比如由于缓存太频繁造成的内存问题，缓存了本不应该被缓存的东西而引起的性能问题.还好我们有一些诊断/调试工具来帮助我们找出真正的罪魁祸首。但是，如果我们谨慎设计我们的缓存代码，应该就不至于那么痛苦的调程序了。

Yawei

高性能ASP.NET应用程序（1）——优化状态管理

APGC DSI Team — Mon, 24 Jan 2011 09:29:25 GMT

今天我们来聊一下在编写ASP.NET应用程序的时候如何优化状态管理。我相信绝大多数的ASP.NET开发人员或多或少的都会对使用ASP.NET的状态有所了解。在本文中，我们不会把如何使用ASP.NET的状态作为重点，而更侧重于讨论如何更加有效率和有效果的管理ASP.NET的状态。Web应用程序为状态管理提出了一些具体的挑战，尤其是Web场/园的情形。您就状态存储的位置和方法所作出的决定对您的应用程序的性能和扩展性将会产生巨大的影响。

总的来说，ASP.NET中有3种状态：应用程序状态、会话状态和视图状态。他们分别需要在不同的情形下使用。应用程序状态应用于所有的用户和会话。而会话状态用于存储单个用户的状态。在这里单个用户可以理解为来自同一个浏览器的请求。视图状态用于存储单个页面的状态信息，就像在某个具体网页的控件中包含的内容。归结起来有2种状态管理指南：1）在客户端上存储简单的状态；2）考虑序列化带来的开销。对于第一点，当视图状态不可用时您可以考虑利用客户端cookie、查询字串或者隐藏控件。考虑到状态的序列化，请确保只在必要时才进行存储，并且倾向于存储简单的类型（约15%到25%的性能影响）而非复杂的对象（可能会有更大的影响）。

现在我们来分别谈一下怎样最优化应用程序状态、会话状态和视图状态管理。

应用程序状态管理技巧：

1. HttpApplicationState VS 静态属性：您应该避免在应用程序对象中存储数据。取而代之的是，您可以使用应用程序类的静态成员。您可以由此获得性能提升因为访问静态成员会比访问应用程序对象快得多。一个例子是：

private static string[] _states[];

private static object _lock = new object();

public static string[] States

{

get {return _states;}

}

public static void PopulateStates()

{

//ensure this is thread safe

if(_states == null)

{

lock(_lock)

{

//populate the states... }

}

public void Application_OnStart(object sender, EventArgs e)

{

PopulateStates();

}

2. 应用程序状态VS ASP.NET 缓存：当您可以使用缓存来存储可读写的数据来避免服务器/进程关联问题，请倾向于在应用程序状态中存储只读日期。

3. 避免在应用程序状态中存储STA COM对象。所有访问STA COM的线程都会被序列化从而引发一些严重的性能事件。

会话状态技巧：

基本上，我们有3种选择来存储会话状态：InProc、 StateServer 和 SQL server。InProc是速度最快的选择然而状态数据有可能会在进程回收和进程崩溃。这不能应用于Web场或者Web园部署。状态服务器既不能安装在本地服务器上也不能安装在远程服务器上。这种做法很好但是因为将状态从存储处提取和传输到存储处所需要的状态序列化和反序列化而对性能造成影响。SQL Server能够在大型网络平台上为存储无数的用户会话数据提供高可扩展性和性能。序列化和反序列化的开销会比状态服务器稍微多一些。然而，带有SQL簇的SQL Server可以提供更好的鲁棒性。

会话状态管理技巧：

1. 侧重于基本类型以减小序列化开销。基本类型是指Int、Byte、Decimal、String、DataTime、TimeSpan、Guid、IntPrt和UintPtr等类型。基本类型序列化的速度快于复杂类型的原因是ASP.NET使用了一种优化过的内部方法来序列化基本类型而复杂类型却使用BinaryFormatter对象。
2. 关闭会话状态，如果不使用此项的话。
3. 正如应用程序状态，请在会话状态中也避免存储STA COM对象。
4. 尽量使用只读标签。因为内部使用会话状态的页面请求使用了一个ReaderWriterLock，这意味着它将在任何给定时间允许多线程的同时只读访问，或者可写的单线程访问。如果您的请求需要修改会话状态，这些请求将被序列化。以下是一个简单的例子。当您浏览Main.aspx页面并点击slow区域和quick区域的Refresh按钮时，您将会看到请求被序列化，这意味着快和慢的页面将会被同时呈现到客户端。

Main.aspx:

<%@ Page Language="C#" enableSessionState="true"%>

</frameset>

Quickpage.aspx:

<%@ Page Language="C#" enableSessionState="true"%>

protected void Page_Load(object sender, EventArgs e)

{

Session["test"] = "testquickpage";

Response.Write(DateTime.Now.ToLongTimeString());

Response.Write(" " + Session["test"]);

}

</script>

<asp:button runat="server" text="refresh" />

</form>

Slowpage.aspx:

<%@ Page Language="C#" enableSessionState="true"%>

protected void Page_Load(object sender, EventArgs e)

{

Session["test"] = "testslowpage";

System.Threading.Thread.Sleep(50000);

Response.Write(DateTime.Now.ToLongTimeString());

Response.Write(" " + Session["test"]);

}

</script>

<asp:button runat="server" text="refresh" />

</form>

访问Main.aspx页面将会导致3个页面出现在同一会话中。这个请求处理将会被序列化。调用堆栈显示了线程30正在处理slowpage.aspx，而quickpage.aspx将会被另外一个线程处理但却正在等待线程30来完成。查看Timeout值可以发现，它在slow和quick页面之间几乎以同样的步伐保持增长。

HttpContext Timeout Completed Running ThreadId ReturnCode Verb RequestPath+QueryString

0x0000000155740530 110 Sec no 10 Sec 28 200 POST /sessionRWLock/slowpage.aspx

0x000000019570b2d8 110 Sec no 305 Sec XXX 200 GET /sessionRWLock/main.aspx

0x00000001957af010 110 Sec no 9 Sec XXX 200 POST /sessionRWLock/quickpage.aspx

HttpContext Timeout Completed Running ThreadId ReturnCode Verb RequestPath+QueryString

0x0000000155740530 110 Sec no 89 Sec XXX 200 POST /sessionRWLock/slowpage.aspx

0x000000019570b2d8 110 Sec no 384 Sec XXX 200 GET /sessionRWLock/main.aspx

0x00000001957af010 110 Sec no 88 Sec XXX 200 POST /sessionRWLock/quickpage.aspx

以下是线程30的托管堆栈，可以看出它停留在了Page_load状态。

0:030> !clrstack

OS Thread Id: 0x664 (30)

Child-SP RetAddr Call Site

000000000436de70 000007feece23ec9 ASP.slowpage_aspx.Page_Load(System.Object, System.EventArgs)

000000000436ded0 000007fee3e4800a System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr, System.Object, System.Object, System.EventArgs)

000000000436df00 000007fee3e3e7e4 System.Web.Util.CalliEventHandlerDelegateProxy.Callback(System.Object, System.EventArgs)

000000000436df30 000007fee3e3e842 System.Web.UI.Control.OnLoad(System.EventArgs)

000000000436df70 000007fee3e3adcc System.Web.UI.Control.LoadRecursive()

000000000436dfc0 000007fee3e3a2d0 System.Web.UI.Page.ProcessRequestMain(Boolean, Boolean)

000000000436e090 000007fee3e3a1fb System.Web.UI.Page.ProcessRequest(Boolean, Boolean)

000000000436e0f0 000007fee3e3a190 System.Web.UI.Page.ProcessRequest()

000000000436e150 000007ff00190219 System.Web.UI.Page.ProcessRequest(System.Web.HttpContext)

000000000436e1b0 000007fee3e41637 ASP.slowpage_aspx.ProcessRequest(System.Web.HttpContext)

...

视图状态管理技巧：

视图状态是被服务器端控件用来保持将数据反馈给它们自己（同一个页面）的内容。1个叫做-_VIEWSTATE的特别隐藏变量持有所有的视图状态信息。视图状态的读取发生在页面初始化之后而存储发生在网页的渲染（Render）之前。由于从视图状态存储/获取数据是如此之容易，视图状态容易被不正确的使用。视图状态实际上是一个页面非必需的开销。以下是一些技巧：

1. 在可能的情形下关闭试图状态。如果页面没有提交返回（post back）、没有服务器端控件事件发生或者没有旧的数据被存储了，您不妨简单的将视图状态关闭。
2. 将存储在试图状态的信息最小化。如果你需要在视图状态存储数据，请记住存储基本类型和较小的对象。
3. 请随时留意视图状态的大小。开启一个跟踪或者以其他方式来监视每一个控件视图状态大小。

Reference: Understanding ASP.NET ViewStat

http://msdn.microsoft.com/en-us/library/ms972976.aspx

以上基本上是ASP.NET状态管理中我认为比较重要的内容。希望能对您有所帮助。如果有任何问题或者担心，请告知我，我将非常高兴的和您一起探讨任何技术问题。非常感谢您花费宝贵时间阅读我们小组的博客！

Yawei

如何解决在Win2003的Oracle链接服务器上MSDTC事务失败问题

APGC DSI Team — Tue, 28 Dec 2010 06:16:00 GMT

在企业环境中，客户有时需要设置MSDTC事务来与远程Oracle目标服务器协同工作。由于跨产品的设置十分复杂，有时我们在更新一个已链接的Oracle数据库中的数据时可能会面临事务失败，例如：

服务器：消息 7391，级别16，状态1，行1

该操作无法执行，因为OLE DB Provider 'MSDAORA' 无法启动分布式事务。

OLE DB错误跟踪 [OLE / DB Provider 'MSDAORA' ITransactionJoin：：JoinTransaction返回0x8000d048]。

下面是帮助我们缩小和解决类似的问题的一般的步骤（开始操作之前，先尝试使用SQL的普通的select语句查询Oracle，确保服务器名称解析和它们之间的网络正常）：

1。在Windows Server 2003中，选择"添加/删除程序程序"控制台，Windows组件中的"启用网络DTC访问"必须启用。可以在Windows组件\应用程序服务器\启用网络DTC访问下启用它。请参考：

817064如何在Windows Server 2003启用网络DTC访问

http://support.microsoft.com/default.aspx?scid=kb;EN-US;817064

2。打开DCOMCNFG，确保MSDTC选项卡下的安全配置的设置是正确的：

3。打开注册表，在Security键中，确保注册表值和UI设置相匹配：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\Security

4。注册表中Oracle模块的配置是正确的：

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\MTxOCI

OracleXaLib=oraclient9.dll

OracleSqlLib=orasql9.dll

OracleOciLib=oci.dll

尽管在这里我们使用Oracle 9i客户端作为举例，我们应该知道，在Microsoft数据访问组件（MDAC）2.5版本之后，微软的ODBC驱动和OLE DB Provider都只支持Oracle7和Oracle 8i：http://support.microsoft.com/Default.aspx?id=244661

一个新的支持Oracle 9i客户端的Microsoft.NET Managed Oracle Provider现已推出。请访问以下Microsoft网站来下载这个Provider：http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=4F55D429-17DC-45EA-BFB3-076D1C052524

对于其他版本的Oracle客户端（7 / 8）注册表键值设置，请参考：

193893 有关Oracle与Microsoft Transaction Server和COM +组件协同使用的信息

http://support.microsoft.com/default.aspx?scid=kb;EN-US;193893

5。从SQL服务器管理控制台中找到已连接的Oracle服务器名称。如果你不清楚如何找到Oracle服务器名称，请与当地的Oracle管理团队联系。

6。创建一个指向您的Oracle数据库的ODBC数据源名称（DSN）。请确保您的DSN使用的是Microsoft Oracle ODBC驱动程序。

a. 从管理工具中打开数据源对话框：

b. 单击用户 DSN选项卡上的添加按钮，选择Microsoft ODBC for Oracle，然后完成向导：

运行此命令，我们应该得到正确的结果，这说明纯Oracle事务工作正常：

Msdtcora.exe -U<oracle用户名> -P<oracle密码> -S<我们在第五步中找到的服务名 >

该Msdtcora.exe可以从如下地址得到：

http://download.microsoft.com/download/transaction/Utility/1/NT5/EN-US/DTCOra.exe

这个工具将跳过MSDTC并直接使用Oracle事务。如果Oracle测试程序可以连接到Oracle数据库服务器且不报错，很可能COM + / MTS也可以与Oracle正常工作。如果这一步失败，您应该联系Oracle支持团队以获取更多信息。

7。确保网络服务帐户（这是在Win2003中为MSDTC建立的新帐户）已被添加在c:\program files\oracle和c:\oracle（如果您设置了不同的Oracle根文件夹，需要做同样的工作），强制所有子对象继承父文件夹相同的设置。否则，MSDTC服务可能无法跟Oracle库进行交流。

如果Oracle事务仍然失败，即使在第6步中Msdtcora返回成功的信息，我们应该检查一下纯MSDTC服务是否工作正常。

你可以对其他已连接的SQL服务器发起MSDTC分布式事务处理（SQL服务器的链接也应该遵循的步骤1,2,3）来查看事务的进展。如果发生任何困难，联系 MSDTC的支持小组以获得进一步的故障排除思路。

更多信息

==============

280106如何在 SQL 服务器中设置到 Oracle 的链接服务器并进行故障排除

http://support.microsoft.com/default.aspx?scid=kb;EN-US;280106

微软Internet开发者支持小组

如何解决浏览ASP网页时IIS7出现404.17错误

APGC DSI Team — Tue, 28 Dec 2010 01:43:00 GMT

症状：

用户报告在Windows2008 64位系统上浏览ASP页面时出现404.17的问题。如果重装IIS服务，问题就不会再出现，但是在安装了SMS（System Management Server）后，同样问题又会出现：

需要检查的东西：

1. 启用IIS7的Failed Request Tracing log功能来检查具体的报错信息。这个案例中的报错信息如下所示：

-MODULE_SET_RESPONSE_ERROR_STATUS

ModuleName StaticFileModule

Notification 128

HttpStatus 404

HttpReason Not Found

HttpSubStatus 17

ErrorCode 2147942450

ConfigExceptionInfo

Notification EXECUTE_REQUEST_HANDLER

ErrorCode The request is not supported. (0x80070032)

这个错误信息是在告诉用户没有ASP handler来处理请求，所以最后一个模块-StaticFileModule处理.asp的请求时候，以"not supported"结束。

事实上这个错误信息只是在告诉用户这个ASP handler不能正常处理.asp的请求。所以我们还是需要找出真正引起错误的原因。

检查了ApplicationHost.config:

</system.webServer>

<system.webServer>

可以看到如红色字体标注的，现在IIS是运行在32位的模式下，所以我们应当删除preCondition="bitness64"使得正确的mapping asp.dll.

但是之后在这个删除后，客户反映问题仍然存在。

在Windows2008使用了Process Monitor来追踪ASP.dll的装载进程，发现，IIS工作进程是在32位的模式下运行，但是装载的是C:\Windows\SysWOW64\inetsrv\asp.dll而并非是C:\Windows\System32\inetsrv\asp.dll。因为32位的IIS工作进程所需要的是32位的ASP.dll. 所以我们建议做如下改动：

最后一点也是最重要的一点，在IIS7中，IIS配置不仅保存在ApplicationHost.config里面，而且也存在于相应web Application中的web.config里面。所以不要忘记检查web.config以确认ASP handler在web.config中被定义。

更多信息：

默认情况下，ASP handler的配置如下：

这就是为什么工作进程能够顺利地在32位和64位之间转换。

谢谢！

微软Internet开发者支持小组

如何解决系统事件出现DCOM 10009错误？

APGC DSI Team — Tue, 28 Dec 2010 01:39:18 GMT

症状：

我们有时在系统事件中会遇到DCOM 10009的错误（如下所示），或者会在DCOM客户应用程序中接收到错误代码0x800706ba：

Event Type:        Error
Event Source:    DCOM|
Event Category:                None
Event ID:              10009
Date:                     2010-2-22
Time:                     10:02:07
User:                     N/A
Computer:          <Computer Name>
Description:
DCOM was unable to communicate with the computer <Target Computer Name> using any of the configured protocols.

Simply speaking, DCOM 10009 indicates that the DCOM client located on this <Computer Name> can't communicate with the DCOM|COM+ server located on that <Target Computer Name>.

发生过程：

当用户调用CoGetClassObject或者CoCreateInstance(CreateObject或者在VB中 new)来启用一个组件的时候， COM runtime会联系它的本地SCM COM的启用者（PRCSS服务），登陆相应的提供这个组件的COM服务器。

如果这个组件是远端的，本地的RPCSS服务会把请求传输给远端机器上的RPCSS服务。

但是如果远端服务器的RPCSS服务不可用的话，DCOM 10009会出现并通知管理员，调用栈内容如下所示：

ChildEBP RetAddr

006df364 757f8b72 ADVAPI32!ReportEventW-> then DCOM 10009 is logged.

006df3a0 757f6542 rpcss!LogRemoteSideUnavailable+0x63 ->here we don't found the server.

006df40c 757f6781 rpcss!CRemoteMachine::Activate+0x294

006df648 757f6861 rpcss!RemoteActivationCall+0xf2

006df664 757edb5c rpcss!ActivateRemote+0x8e

006df6c0 757d629c rpcss!Activation+0x343

006df718 757d7680 rpcss!ActivateFromProperties+0x1c2

006df724 757d76c0 rpcss!CScmActivator::CreateInstance+0xd
...
...

发生原因：

概括说来，发生DCOM 10009错误的原因在于：本地RPCSS服务不能连接到远端目的服务器的RPCSS服务。有几种情形造成这种情况的出现：

1．远端的目的服务器可能出于offline的状态，例如可能是在维护。
2．双方服务器都出于online的状态，但是在两个服务器的PRC通信出现问题，例如服务器名称解析失败，可提供RPC通信的端口资源耗尽，防火墙配置等等。

解决方法：

正如上文所提到的，引起DCOM 10009出现有着很多可能性，我们需要针对不同的情形来做不同的处理:

情形1：

如果远端的服务器是处于维护阶段， DCOM 10009的出现是正常的，我们可以通过ping <远端服务器>来确认远端服务器状态。

情形2：

如果远端服务器是处在online的状态却仍然出现DCOM 10009的话，请执行以下步骤：

1. Ping<远端服务器>和IP地址来确认网络状况良好。
2. Telnet<远端服务器>135以确认Port 135没有被防火墙阻止。
3. 如果已经配置过PRC通信的动态端口，可以通过以下命令来两个服务器的端口资源：Netstat -anb

如果所有的动态端口都在被使用了，或者只有很少可用，可以考虑扩展动态端口。

关于如何配置与防火墙一起使用的 RPC 动态端口分配请参考：http://support.microsoft.com/?id=154596
关于DCOM端口范围配置问题请参考：http://support.microsoft.com/kb/217351/en-us

4. 如果以上步骤都正常，可以使用DTCPing工具来确认两个服务器之间的DCOM通信是否正常。

关于如何使用DTCPing工具来解决MS DTC中的连接问题请参考：

http://support.microsoft.com/kb/918331/en-us

注意：DTCPing工具并非专门指用来解决MSDTC问题的，这个工具可以用来解决所有DCOM通信问题。

参考：

FIX: You cannot obtain detailed error information about DCOM 10009 errors in Windows Server 2003

http://support.microsoft.com/kb/910695

微软Internet开发者支持小组

IIS6.0中应用程序池的下拉列表中显示

APGC DSI Team — Mon, 27 Dec 2010 09:38:34 GMT

症状：

应用程序池的下拉列表中只显示<Invalid Application Pool>条目。

参照文档做了以下步骤和IIS reset，但是仍然没有解决问题：

1． Cannot Select an Application Pool in IIS 6.0 "Invalid Application Pool" message：

http://blogs.iis.net/lprete/archive/2008/06/22/cannot-select-an-application-pool-in-iis-6-0-quot-invalid-application-pool-quot-message.aspx

2．使用Metabase Explorer，没有发现问题。应用程序池的KeyType和Websit的AppPoolID都是正确的
3．在c:\windows\system32\inetsrv用记事本打开IIS 配置文件meatbase.xml，检查<IIsApplicationPools>和<IIsApplicationPool>部分，发现有如下所示多出一个节点：

-<IIsApplicationPool Location="/LM/W3SVC/AppPools/DefaultAppPool" AppPoolAutoStart="TRUE" AppPoolIdentityType="2" ... PeriodicRestartTime="0">

</IIsApplicationPool>

对比本地的metabase.xml文件，发现在<IIsApplicationPools>和<IIsApplicationPool>之间没有<IIsConfigObject>的部分。

解决方法：

1. 备份metabase.xml。
2. 停止IIS管理服务。
3. 删除meatbase.xml文件中的<IIsConfigObject>部分。
4. 重启IIS管理服务以及HTTP SSL，W3Svc等等。

之后IIS中应用程序池中的下拉列表正常显示。

通过与客户的确认，这个多出来的节点应当使用第三方配置工具来添加。

谢谢！

微软　Internet　开发者支持小组

如何在一个跨域环境中用Silverlight客户端使用自托管的WCF服务

APGC DSI Team — Mon, 27 Dec 2010 09:28:00 GMT

背景介绍：

当一个Silverlight客户端试图使用WCF服务时，默认情况下，它只被允许进行在原始站点下的通讯。例如，一个http://domainA/default.aspx托管的Silverlight控件默认情况下只能使用同一个域内的服务，如：http://domainA/WCFService.svc。而http://domainB/WCFservice.svc则不行。

为了使http://domainA/default.aspx托管的Silverlight可以连接到http://domainB/WCFservice托管的WCF服务，我们需要显式配置一个跨域选择策略，即clientaccesspolicy.xml或crossdomain.xml。有很多文章与这个主题相关：

建立可跨网域界限访问的服务

http://msdn.microsoft.com/en-us/library/cc197955(VS.95).aspx

警告：无法在'<URL>'定位跨域策略

http://msdn.microsoft.com/en-us/library/cc838225(VS.95).aspx

当我们的WCF服务托管在IIS中时，我们只需要在发布WCF服务的根文件夹中部署clientaccesspolicy.xml。例如：如果我们的WCF服务发布为：http://domainB/WCFservice.svc，那么跨域策略应该可以通过http://domainB/clientaccesspolicy.xml访问。

然而，自托管的WCF服务有些许不同。在这篇文章中，我们将演示Silverlight客户端如何在一个跨域环境中使用自托管的WCF服务。同时，因为Silverlight4 目前已支持NET.TCP绑定，这些针对NET.TCP绑定的步骤将与basicHttpBinding完全不同。在这篇文章中，我将分别介绍在basicHttpBinding和NET.TCP 绑定这两种不同情景下的步骤。

如何使用自托管WCF服务

场景1：自托管的WCF服务与basicHttpBinding

步骤1：

定义一个接口"IPolicyRetriever"

[ServiceContract]

public interface IPolicyRetriever

{

[OperationContract, WebGet(UriTemplate = "/clientaccesspolicy.xml")]

Stream GetSilverlightPolicy();

[OperationContract, WebGet(UriTemplate = "/crossdomain.xml")]

Stream GetFlashPolicy();

}

步骤2：

在你的WCF服务中实现上述接口：

public class WCFService:IWCFService,IPolicyRetriever

{

//IWCFService 实现

...

//IPolicyRetriever 实现

private Stream StringToStream(string result)

{

WebOperationContext.Current.OutgoingResponse.ContentType = "application/xml";

return new MemoryStream(Encoding.UTF8.GetBytes(result));

}

public Stream GetSilverlightPolicy()

{

string result = @"<?xml version=""1.0"" encoding=""utf-8""?>

<access-policy>

<cross-domain-access>

<allow-from http-request-headers=""*"">

</allow-from>

<grant-to>

</grant-to>

</policy>

</cross-domain-access>

</access-policy>";

return StringToStream(result);

}

步骤3：

发布一个endpoint，地址为""，基于HTTP schema的主机地址来为clientaccesspolicy.xml接收请求。我们可以通过编程或管理的方式达到此目的。

编程的方式：

Type serviceType = typeof(WCFService);

ServiceHost host = new ServiceHost(serviceType);

host.AddServiceEndpoint(typeof(IPolicyRetriever), new WebHttpBinding(), "").Behaviors.Add(new WebHttpBehavior());

管理的方式：

</behavior>

</endpointBehaviors>

...

</behaviors>

...

<endpoint behaviorConfiguration="WebHttpNewBehavior" binding="webHttpBinding"

bindingConfiguration="" name="PolicyEndpoint" contract="WCFService.IPolicyRetriever" />

...

</service>

</services>

在以上步骤之后，当一个Seliverlight控件向跨域自托管的WCF 服务发出一个请求时，这个服务端的服务器应该能够检索它的客户端访问策略，然后决定请求是否被授权。

场景2：自托管的WCF服务与NET.TCP binding

即使如下文章宣布了Sliverlight4支持NET.TCP binding：

Sliverlight4 中的WCF NET.TCP协议

http://www.silverlightshow.net/items/WCF-NET.TCP-Protocol-in-Silverlight-4.aspx

在开始我们的步骤之前，我想特别指出一些与basicHttpBinding场景不同的地方。

1. 实际上NET.TCP schema并不能被Silverlight 4识别。至少当前如此。为了使用NET.TCP 绑定，我们需要使用customBinding。

2. TCP 端口范围被限制在4502-4534，这意味着你的WCF服务必须在以上端口范围中发布，从而使Silverlight客户端能够访问它。

为了使客户端能够访问策略，在Silverlight4 RC之前，TCP 943端口专门用来暴露策略。

参考如下文章以获得更多细节信息：

Silverlight中的网络安全访问限制

http://msdn.microsoft.com/en-us/library/cc645032(VS.95).aspx

为了使我们的工作变得简单，Microsoft的Tomasz Janczuk创建了一个免费的针对那些工作如TCP 套接字策略服务器的命令行程序的模板。

然而，Silverlight 4 RC中的NET.TCP协议希望能通过HTTP协议在域名的根目录中访问到套接字策略，而不是像之前那样通过TCP协议在943端口访问到。

参考如下文章以获悉这个改变：

Sliverlight 4 中使用WCF net.tcp 协议的发布/订阅例子

http://tomasz.janczuk.org/2009/11/pubsub-sample-with-wcf-nettcp-protocol.html

在这里，我们展示针对于Silverlight 4 RC场景的步骤，这意味着套接字策略通过HTTP协议在域名的根目录下被访问到。

步骤1：

配置WCF 服务使用customBinding，和一个基于NET.TCP 模式的元数据交换端点。你可以参考如下配置：

</binding>

</customBinding>

</bindings>

...

<endpoint address="WCFService" binding="customBinding" bindingConfiguration="NewBinding0"

name="ServiceEndpoint" contract=" Demo.IWCFService " />

<endpoint address="mex" binding="mexTcpBinding" bindingConfiguration=""

name="MEXEndpoint" contract="IMetadataExchange" />

<host>

</baseAddresses>

</host>

</service>

</services>

步骤2：

将clientaccesspolicy.xml部署到http://domainB的根目录下，以确保clientaccesspolicy.xml能够通过http://domainB/clientaccesspolicy.xml访问到。clientaccesspolicy.xml的内容应该与如下相似：

<access-policy>

<cross-domain-access>

<allow-from>

</allow-from>

<grant-to>

<socket-resource port="4502-4534" protocol="tcp" />

</grant-to>

</policy>

</cross-domain-access>

</access-policy>

经过如上步骤后，你的Silverlight 应该能够成功地通过NET.TCP 绑定请求自托管的WCF 服务。

谢谢！

微软Internet开发者支持小组

IIS7中的自定义 404页面错误- 500.19

APGC DSI Team — Mon, 27 Dec 2010 09:23:00 GMT

在进行如下带静态文件的自定义404页面配置时，

您可能会收到如下错误（见下图），

500.19 - Internal Server Error

Absolute physical path "driver:\path" is not allowed in system.webServer/httpErrors section in web.config file. Use relative path instead.

根本原因：

当在web.config文件中检测到绝对路径时，就会产生此错误。

目前针对该问题有2种解决方案。

方案1：

1. 在ApplicationHost.config文件中将<system.webServer> <httpErrors>的allowAbsolutePathsWhenDelegated设置为"true"。

<system.webServer>

...

．．．．

</httpErrors>

</system.webServer>

</location>

<system.webServer>

... ...

</httpErrors>

</system.webServer>

</location>

2. 重启IIS。

方案2

1. 在IIS Manager中，找到Features Views->Management Area，双击"Feature Delegation"。选择Error Pages并单击Read Only，如下图。

2. 在C:\inetpub\wwwroot或您的任何网页应用程序的物理目录下，打开web.config文件，移除以下部分。

</httpErrors>

如果在config文件中没有其他配置，您可以直接删除由IIS为delegation Read/Write生成的web.config文件。

3. 重启IIS。

更多信息

如何在IIS7中进行自定义404页面设置。您能通过以下步骤达到该目的：

1. 创建一个名为custom404.html的文件，并保存至您的网页目录（一般情况下为c:\inetpub\wwwroot）。
2. 打开Internet Information Services (IIS) Manager。
3. 在Connections窗口内（左边），展开相关节点至某个您想要进行自定义错误配置的站点，并选定该站点。
4. 在中间窗口的底部，单击Features View。
5. 在中间窗口，双击Error Pages。
6. 双击Status Code 404。
7. 在Edit Custom Error Page对话框中，
a. 在"Insert content from static file into the error response"域中输入物理路径。当出现找不到页面的情况时，就会返回http 404错误并显示自定义的404错误页面。
b. 在"Exectute a URL on this site"域中，输入绝对路径。在本实例中，输入/custom404.html。当出现找不到页面的情况时，就会返回http 200错误并显示自定义的404错误页面。

8. 点击OK。

参考

HTTP Errors <httpErrors>

http://www.iis.net/ConfigReference/system.webServer/httpErrors

谢谢！

微软　Internet　开发者支持小组

如何解决组件服务中的“红色箭头”问题

APGC DSI Team — Mon, 27 Dec 2010 09:04:00 GMT

在分布式环境中，当调用DCOM组件或者COM+应用程序出现问题时，我们第一件需要做的事是打开Components Manager来检查或者重新设置COM+/DCOM参数。然而，当打开Component Services的时候，可能会有一个"红色箭头"出现在"My Computer"节点上：

如果我们试图展开"My Computer"节点，可能会显示多个错误信息。为了解决这种问题，我们可以参照以下Check list，这样大多数常见的问题都可以得到解决：

1. 确保MSDTC服务处于Started状态；

2. 确保Users 用户组拥有注册表HKEY_CLASSES_ROOT\CLSID子键的Read权限。如果 Users group没有这样的权限，COM+系统应用程序服务可能无法正常启动，并导致"红色箭头"问题。可以参阅以下步骤来赋予Users 用户组相应权限（请在操作前备份HKEY_CLASSES_ROOT\CLSID）：

a. 打开 Regedt32，找到HKEY_CLASSES_ROOT\CLSID；
b. 选择CLSID，点击菜单栏中的Security -> Permission；
c. 在Security选项卡中，添加Users到允许列表中，并赋予Read权限。
d. 单击Advanced按钮，选中"Replace permissions entries on all child objects with entries shown here that apply to child objects"，之后单击"Apply"。

3. 确保用户Everyone对C:\Windows\Registration及其子对象拥有阅读权限，可以使用命令"cacls"来配置，具体请参阅：

909444 You may experience various problems after you install the Microsoft Security Bulletin MS05-051 for COM+ and MS DTC

http://support.microsoft.com/default.aspx?scid=kb;EN-US;909444

4. 保证COM+ System Application服务处于Started状态：

5. 确保MSDTC服务允许Authenticated Users查阅服务状态。可以在命令行窗口中使用以下命令来查看：

sc sdshow msdtc

如果Authenticated Users用户组没有对MSDTC服务对象的query权限，这意味着大多数用户没有权限来获取MSDTC服务的状态，例如：

(A;;CR;;;AU)

我们需要运行此命令来为Authenticated Users赋予足够权限，然后重启DLLHOST.exe（请首先备份"sc sdshow msdtc"命令的输出信息）：

sc sdset msdtc D:(A;;CCLCSWRPLOCRRC;;;S-1-2-0)(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)(A;;CCLCSWRPLORC;;;NS)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

注意：关键部分是： (A;;CCLCSWLOCRRC;;;AU)，而其他字符串来自于"sc sdshow msdtc"命令的结果。

如需有关ACL的说明信息，请参考：

914392 Best practices and guidance for writers of service discretionary access control lists

http://support.microsoft.com/default.aspx?scid=kb;EN-US;914392

注意：该权限更改是针对Service Object ACL，而并不会影响NTFS文件属性。

该设置亦在我们之前的博客中有详尽阐述，请参考：

http://blogs.msdn.com/asiatech/archive/2009/05/22/security-audit-failure-560-caused-by-permission-setting-of-msdtc-service.aspx

http://blogs.msdn.com/asiatech/archive/2009/04/13/cannot-expand-the-com-list-in-the-component-services-ui-error-0x8004e00f-or-0x8004d01b.aspx

6. 如果以上步骤没有帮助，则需要查看Application和System的事件日志。有时我们会考虑重新构建COM+系统。这一步骤可能有些冒险，如果您之前已经安装了很多COM+应用程序，在重构COM+系统后会需要您重新安装这些COM+应用程序：

How to clean up a damaged COM+ catalog

http://support.microsoft.com/?id=315296

在您开始第6步骤之前，请最好先向您的Application team 和Microsoft Support进行咨询。

谢谢！

Internet 开发者支持小组

AsiaTech: 微软全球技术支持中心互联网开发支持团队 官方博客

如何解决IE下载时中文文件名变乱码的问题

问题现象

背景

环境

问题起因

解决办法

在SharePoint Web应用中访问Session对象时发生System.NullReferenceException异常

匿名远程访问COM+应用时被拒绝访问的问题

在预编译 (Pre-Compiled) 的ASP.NET应用中页面设置失效的问题

委托非管理员账号回收IIS 7远程应用池的问题

IE访问IIS7.5架设的需Windows认证的网站时出现不停弹框的问题

如何解决请求超时的HttpException异常 (ASP.NET 2.0 32-bit)

为什么第一次访问ASP.NET应用会很慢

如何用IIS Web Portal管理windows user password

如何用Indexing Service来对Windows Server 2008中的IIS 7.0网站进行索引

如何在IIS 6.0中使用256 bit SSL

由string.IndexOf引起的ASP.Net应用挂起

当一个进程中加载多个.NET Runtime的时候如何在托管调试中加载指定的mscordacwks.dll

高性能ASP.NET应用程序（2）——ASP.NET缓存简介

高性能ASP.NET应用程序（1）——优化状态管理

如何解决在Win2003的Oracle链接服务器上MSDTC事务失败问题

如何解决浏览ASP网页时IIS7出现404.17错误

如何解决系统事件出现DCOM 10009错误？

IIS6.0中应用程序池的下拉列表中显示

如何在一个跨域环境中用Silverlight客户端使用自托管的WCF服务

如何使用自托管WCF服务

IIS7中的自定义 404页面错误- 500.19

如何解决组件服务中的“红色箭头”问题

AsiaTech: 微软全球技术支持中心互联网开发支持团队官方博客