ASP.NET調試

注 如果在本部分中找不到需要的錯誤消息，請查看處理常規調試問題部分或處理遠程調試問題部分。

消息：無法在 Web 服務器中啟動調試。

原因 1：未將 IIS 應用程序配置為使用 Integrated Windows Authentication。確保已選中“Authentication Method”對話框中的 Integrated Windows Authentication 復選框，如圖 2 所示。

原因 2：檢查 IIS 的 Enable HTTP Keep Alive 選項。如果它是關閉的，則可能需要將其打開，再嘗試調試。

消息：您沒有調試服務器的權限。

原因 1：確保已啟用 Integrated Windows Authentication。可能的原因是僅為 IIS 的 Directory 安全啟用了 Basic authentication。

原因 2：如果您在使用 Integrated Windows Authentication，則需要確保您的用戶帳戶能夠完全控制 IIS 的目錄。

原因 3：如果使用完整的機器名（如 machinename.domainname.something）創建 Web 項目，則該 Web 站點會被識別為 Internet 站點。因此，Internet Explorer 的默認設置將對登錄行為產生影響。在這種情況下，您需要使用當前帳戶在具有 IE 設置的“Internet”區域啟用登錄。

然而，這不是 Internet Explorer 的默認設置，因此最好僅使用機器名來創建項目，將圖 4 用作 Security Settings 的指南。

消息：發送調試 HTTP 請求時發生服務器端錯誤。

原因 1：Web 應用程序沒有應用程序名。為此，請使用 IIS MMC 來檢查 Web 項目的屬性，確保 Web 項目具有應用程序名。當圖 6 中的紅色輪廓出現時，應該出現應用程序名。

原因 2：如果使用的是 NTFS 文件格式，則確保“aspnet”具有“wwwroot”或虛擬目錄文件夾上的適當權限，才能訪問和寫入這些文件夾。

消息：沒有對項目進行配置以接受調試。

如果出現這一錯誤消息，則需要針對調試配置 Web。為此，需要在 web.config 文件中設置 debug = true。此文件位于 Web 項目文件夾中。

您可以啟動調試，同時不出現錯誤消息，但是不能到達斷點。

您使用 F5 鍵啟動了調試，看起來好像正確啟動了調試并且也正確啟動了 Internet Explorer，但是您不能到達代碼隱藏的代碼中的斷點。

原因 1： 在項目屬性中未啟用 Asp.net 調試。按照圖 8 所示將該項設置為 True。

在 VB 項目中，UI 有所不同，但可以輕松地識別等效項。

原因 2：請確保使用匹配的調試符號文件加載期望的 DLL。可以使用 Modules 窗口來檢查這一點。

消息：未正確安裝調試器。

如果看到這一問題，請在 Console Application 項目中檢查調試功能。如果控制臺應用程序項目顯示如圖 10 所示的錯誤消息，則表示未正確安裝 .NET Framework 應用程序。

需要通過執行“regsvr32 mscordbi.dll”來手動注冊“mscordbi.dll”。

消息：服務器不支持對 ASP.NET 或 ATL 服務器應用程序的調試。

如果您在機器上安裝了 Windows XP Pro 或 Windows 2000 Pro，則可能需要考慮 Visual Studio 7 和 IIS 之間的安裝順序。如果在 Visual Studio 7 之后安裝 IIS，則會發生這一錯誤。在這種情況下，請使用“aspnet_regiis.exe –i”注冊“aspnet_isapi.dll”。

消息：訪問被拒絕。檢驗您是否是管理員或某個組成員。

您可能不是該計算機上 Debugger Users 組的成員。將您的用戶帳戶添加到計算機上的 Debugger Users 組中即可解決此錯誤。

要將您的用戶帳戶添加到 Debugger Users 組中，需要執行以下操作：

1.	作為 Administrator 登錄。
2.	運行 Administrator tools 中的 Computer management。
3.	選擇 Local users and groups\groups 節點。
4.	雙擊右邊窗格中的 Debugger Users 組。
5.	單擊 Debugger users properties 對話框中的 Add 按鈕。
6.	鍵入用戶帳戶并單擊 OK。

消息：無法啟動 ASP.NET 或 ATL 服務器調試。

原因 1：您可能安裝了 IIS Lockdown 工具。如果這樣，則查找 urlscan.ini 文件，并將 DEBUG（區分大小寫）添加到 [allowverbs] 部分中。

原因 2：如果將域控制器用作服務器，并且項目是使用機器名（非完整域名）創建的，則可能需要將項目的 URL 更改為完整域名。

原因 3：如果將 IIS 設置為使用專用 IP（例如 Web site identification，可以在 IIS MMC 的 IIS 設置中找到這一選項），則可能看到這條錯誤消息。在這種情況下，需要更改項目名，直接使用 IP 地址。對于現有項目，需要更改項目以使用 IP 地址，而不用通過編輯 .sln 文件和 .webinfo 文件使用機器名。

原因 4：web.config 文件的 中的值太大。默認單位是千字節而非字節，因此如果更改此數字，使用了錯誤的單位，則可能導致調試問題。

消息：訪問被拒絕。

原因：您可能是 Debugger Users 組的成員，但是您不具有調試 aspnet 輔助進程的權限，因為您不是 aspnet 用戶帳戶或 Administrators 組的成員。將您的用戶帳戶添加到機器上的 Administrators 組即可解決此問題。

無法使用包括文件進行調試

在 ASPX 中，無法使用包括文件進行調試。將舊的 ASP 項目轉換為 ASPX 時，往往產生包括文件。

如果通過 包括文件，則可能無法正確調試該包括文件。您需要使用 來代替。

更改密碼后，需要注銷/登錄才能進行 ASP.NET 調試。

更改密碼后，需要注銷，然后再登錄才能正確進行 ASP.NET 調試。

安裝 Windows2000 SP4 后，ASP.NET 調試不能運行，同時顯示消息“訪問被拒絕”。

此問題的解決方法是，使用 regsvr32 –i aspnet_isap.dll 重新注冊 aspnet_isap.dll。

僅在首次加載頁面時遇到斷點。

針對這一特定問題，可能存在多種原因，但是最大的可能性是您在 web.config 文件中設置了頁面緩存選項。

如果在 web.config 中看到類似于 的內容，則需要將值設置為“False”，以關閉 Web 頁面緩存。更改該設置并刷新頁面后，可能遇到斷點。

您需要共享 Web 服務器以進行調試，但是不想讓其他用戶成為計算機管理員。

在 Visual Studio .NET 中，以下二者可以確定用戶是否可以進行調試。其中之一是 Debugger Users 組，另一個是用戶權限，如管理員、Power User 或 SEDebug。

Debugger Users 組確定用戶是否可以訪問 VS 調試組件（主要是 MDM-Machine Debug Manager，Visual Studio 的一部分），所以成為該組的成員意味著保證可以訪問 MDM。因此在這一點上，您可以調試開放進程并查看機器上的進程列表。

不過在此之后，您是否可以調試其他用戶的進程取決于您的權限。例如，如果您想調試別人的本地進程，則需要具有 SEDebug 權限.針對其他用戶的托管進程，您應該是該機器上的管理員，才有權進行調試。

因為存在這一限制，所以在您的方案中，應該授予學生管理員權限。否則，默認情況下無法對 ASP.NET 輔助進程進行調試。

我們有一種變通方法。Cassini 是一個獨立的小型 ASP.NET 服務器。對學生來說，他們可以使用 Cassini 進行開發，稍后將開發結果部署到實際服務器上來提交結果。Cassini 位于 http://www.asp.net/Projects/Cassini/Download/。

常規調試

這些案例基于 Console application 項目類型。

消息：無法啟動調試。

導致圖 15 中所示問題的原因是沒有正確注冊 mscordbi.dll。此問題的補救辦法是手動注冊該文件。

消息：無法啟動調試。訪問被拒絕。

確保正確啟動 Machine Debugger Manager 服務，并且確保您是 Debugger Users 或 Administrators 的成員。

我可以啟動托管調試，但是 PDB 不加載，并且不能遇到任何斷點。

如果正確啟動了調試器，但不能遇到任何斷點，則您可能需要檢查 diasymreader.dll 的安裝。可能沒有注冊該文件。要注冊該文件，需要執行以下操作：

regsvr32 \diasymreader.dll

托管調試不運行

在進程創建 CLR 對象前，以 CLR 模式連接本地進程。托管調試不運行。

解決方案 1：在進程中使用了 CLR 代碼后再連接進程。

解決方案 2：以 InterOp 模式連接進程。在這種情況下，不必在調用 CLR 代碼之后再連接進程。

托管調試器不響應

使用托管代碼啟動調試時，調試器不響應。

解決方案：確保已停止并禁用 .NET FrameworkSupport 服務（僅停止該服務還不夠）。

如果沒有運行 .NET FrameworkSupport 服務，則禁用 IIS admin 服務。

使用 C# 代碼單步調試不正確

考慮以下代碼：

string someStr; 
someStr = "SomeValue"; 
if(someStr == null) 
  Console.WriteLine("what's up?"); 

try 
{ 
} 
catch(Exception e) 
{ 
}

如果使用此代碼，則會看到遇到“if”語句時，指令指針將移動到“if”語句體 (Console.WriteLine("what's up?");)。

這不是一個調試器 bug，而是一個眾所周知的 try catch 塊調試信息問題。請參見以下調試器中 try catch 塊示例的反匯編代碼。

if(someStr == null) 
a cmp        dword ptr [ebp-18h],0 
e jne        C 

Console.WriteLine("what's up?"); 
 mov        ecx,dword ptr ds:[01C50070h] 
 call       dword ptr ds:[02F0257Ch] 
c jmp        

catch(Exception e) 
e mov        dword ptr [ebp-1Ch],eax 
 call       C0846 
 jmp        

} 
 nop      

值沒有匹配時，指令指針移動到 0000003c jmp 行，但是該行已經錯誤地與“if”語句體相匹配。當代碼功能正確時，顯示就不正確了。

因果性調試：Web 服務客戶端和 Web 服務之間的步驟

無法從 Web 服務客戶端到 Web 服務設置調試

默認設置不允許從 Web 服務客戶端進入 Web 服務。它的運行方式類似 step-over。

ASPNET 輔助進程（aspnet_wp.exe 或 w3wp.exe）在“aspnet”或“network service”用戶帳戶之下運行，而這些帳戶沒有通過 DCOM 訪問 MDM 的權限。因此，需要將這些帳戶添加到 Debugger Users 組中。

啟用 Web 服務模擬后，無法再使用因果性步驟。

使用“web.config”為 Web 服務啟用模擬時，不能從 Web 服務客戶端代碼進入 Web 服務代碼。因為，它的運行方式類似于 step over。

您需要執行以下操作來更正客戶端和服務之間的步驟。

•	關閉 IIS 中的 Anonymous access。
•	更改客戶端代碼，將憑據設置為 Web 服務，如下所示：
•	Service1 obj = new Service1();
•	obj.Credentials = System.Net.CredentialCache.DefaultCredentials;

在此之后，您將能夠從客戶端進入 Web 服務。

這些操作是必需的，因為當您進入 Web 服務時，某些 .NET Framework 組件需要使用系統級調試器組件 (MDM) 來共同創建它。如果不能提供正確的憑據，則此步驟將失敗。如果沒有這些正確的憑據，“step into”的運行將類似于“step over”。

調試器掛起

如果 Web 服務客戶端代碼在 STA (Single Thread Apartment) 模型中運行，并且它在等待異步調用完成，如下所示：

Service1 obj = new Service1(); 
System.IAsyncResult ar = obj.BeginHelloWorld(new System.AsyncCallback(Class1.Handle),obj); 
while(ar.IsCompleted != true) 
{ 
  System.Threading.Thread.Sleep(1000); 
}

則調試器將掛起。發生此掛起操作，原因在于調試器中的代碼已鎖定一個調試器組件。解決方案 1 是更改代碼以使用與事件或 mutex 同步的線程。另一個解決方案是注銷 csm.dll。第二個解決方案禁用 causality 步驟（從 Web 服務客戶端代碼到 Web 服務方法的步驟）。您可能需要手動連接 aspnet_wp.exe 才能調試 Web 服務。

遠程調試

無法查看遠程機器上的任何進程

確保在遠程機器上安裝了 Remote full debug 設置，并且您是 Debugger Users 組的成員。

因 RPC 問題而無法連接到遠程機器

以下信息摘自 Mike Clay 撰寫的 KB 文章。

如果通過“Processes”對話框連接到遠程機器上時看到以下錯誤消息：

Error while trying to run project: Unable to start debugging on the 
web server. Not enough storage is available to complete this operation.

或者在進行 ASP.NET 調試期間看到這一消息：

Error while trying to run project: Unable to start debugging on the web
server. Unable to map the debug start page URL to a machine name.

則確保 RPC 在您的機器與遠程機器之間正確運行。下面的行為可能導致 RPC 問題：

•	通過防火墻進行調試。Microsoft 不建議或支持通過防火墻的遠程 ASP.NET 調試。解決此問題最好的方式是，使用“終端服務”登錄遠程服務器并在本地進行調試。
•	RPC 的一種常見故障是無力解析遠程機器名。RPC 依靠名稱解析在計算機之間通信。如果未能將遠程服務器機器名解析為正確的 IP 地址，則可能發生錯誤。
•	RPC 通信只能單向流動，另一個方向卻不行。RPC 通信必須能夠從用于調試的機器到達遠程服務器，并從遠程服務器返回用于調試的機器，這樣才能成功進行遠程調試。確保以雙向方式啟用 RPC 通信。

要分析 RPC，可以使用 RPCPing 工具。

遠程調試工作組中的機器失敗

當您的兩臺 Windows XP Pro 機器都不在域中但在工作組中時，將發生這種情況。在它們之間進行遠程調試時，您根本無法訪問遠程機器。

在工作組環境中，您需要確保兩臺機器具有相同的用戶帳戶名和相同的密碼。否則，DCOM 進行身份驗證時將失敗。

另外，在 Windows XP Pro 上，將 Sharing and security model for local accounts 的默認安全設置設置為現在允許共享。下面是更改此設置的步驟：

1.	運行管理員工具中的 Local Security Settings。
2.	選擇 Security settings\Local policies\Security 選項。
3.	將 Network access : Sharing and Security model for local accounts 從 Guest only - local users authenticate as Guest 更改為 Classic - local users authenticate as themselves。
4.	重新啟動計算機。

應該將此更改應用于進行遠程調試的兩臺機器。

更改設置后，即可使用同一名稱的用戶帳戶在兩臺機器上進行遠程調試。請確保每臺機器上的用戶帳戶都具有密碼。在某些情況下，沒有實際密碼機器不能運行。

然而，因為更改了安全模型的默認設置，所以可能公開下面的內容：

•	意外的文件共享
•	意外的 DCOM 組件共享。

在進行這一更改之前，從遠程機器到您的機器的任何種類的連接都是以 Guest 身份進行的；但更改后，他/她即可接受使用本地用戶帳戶的身份驗證。因此，在調試案例中，如果將一個文件夾或 DCOM 對象共享出來，其他機器上的任何匹配用戶（具有相同用戶名和相同密碼）都可能可以訪問您的共享對象。

我極力建議，如果您要使用這一變通方法，則請確保所有用戶帳戶都具有強密碼，否則應該設置一個網絡孤島來調試機器，以防止惡意攻擊。