本文章是由機器翻譯。
深究 CLR
CLR 4 中生產環境診斷的改良內容
瓊 Langdon
在通用語言執行階段 (CLR)] 小組我們有的群組，其焦點會提供 API 和服務，可讓其他人來建置 Managed 程式碼的診斷工具。兩個的最大元件，我們擁有 (方面的工程專用的資源) 是受管理的偵錯和分析 API (ICorDebug * 和 ICorProfiler * 分別)。
其餘的 CLR 」 和 「 架構小組，像我們值實現只能透過建置在我們所佔的比重的最上層的應用程式。例如，Visual Studio 團隊使用這些偵錯] 和 [程式碼剖析 API 他們 Managed 偵錯工具和程式碼剖析工具，效能，以及許多協力廠商開發人員正在建置程式碼剖析 API 的工具。
過去 10 年大部分的焦點放在為 CLR 和 Visual Studio 這個區域已經上啟用開發人員桌面案例：來源逐步來尋找程式碼錯誤 ； 啟動應用程式效能的程式碼剖析工具下可協助找出慢速的程式碼路徑 ； 偵錯工具中編輯後繼續以協助減少時間花費在編輯建置偵錯週期 ； 依此類推。這些工具可以用在應用程式中尋找 Bug，它們被使用者 ’s 機器上安裝或部署到伺服器兩 (種情況下此後稱為 之後生產)，而且我們嗎有許多協力廠商建置世界級的實際執行診斷工具，在我們的工作的最上層。
不過，我們一致的意見反應從取得客戶和加強的讓您更容易尋找整個應用程式的生命週期的 Bug 重要性這些廠商。之後所有軟體錯誤通常視為更昂貴修正，稍後它們在應用程式生命週期中找到。
CLR 4 (Runtime 基礎 Microsoft.NET Framework 4) 是第一版的我們做重大的努力解決該意見反應，並且開始展開案例接近頻譜生產結尾我們診斷 API 支援。
本文章中我將看看一些案例我們瞭解會特別痛苦今天，我們採取解決它們和它們所啟用的工具類型方法。特別，我會解釋如何我們發展偵錯 API 來支援傾印偵錯應用程式損毀和-擱置案例以及如何我們變得更容易地偵測何時擱置所造成的 multi-threading 問題。
我也將說明如何加入能力附加 程式碼剖析工具 至已經執行應用程式將會進一步簡化疑難排解這些相同的案例而且大幅減少診斷所造成的過度的記憶體耗用量問題所花的時間量。
最後，我簡短地將解釋如何我們進行程式碼剖析工具容易部署藉由移除登錄的依存。整個，焦點主要是在新的工具可讓我們的工作，類型上但情況適用時我已將包含協助您瞭解如何您可以利用我們的工作，透過 Visual Studio 的額外資源的參考。
傾印偵錯
其中一個受歡迎的功能，我們傳遞與 Visual Studio 2010 是受管理的傾印偵錯。處理序傾印通常稱為剛傾印，通常用在實際執行環境偵錯原生和 Managed 程式碼的案例。傾印的時間是基本上是在特定時點的程序 ’ 狀態的快照集。特別，它 ’s 處理程序 ’s 虛擬記憶體 (或或是其他某些子集) 的內容傾印到檔案。
之前 Visual 的 Studio 2010 為了要偵錯傾印的 Managed 程式碼您需要使用特定的 Windows 偵錯工具擴充功能 sos.dll 來分析傾印代替更熟悉的工具 (像是 Visual Studio (您可能撰寫並在產品開發期間偵錯您的程式碼)。我們的目標，高階經驗我們希望您有當來診斷問題 Visual Studio 中的使用一個傾印時停止狀態的現場偵錯：內容當偵錯程式碼時，遇到及停止於中斷點。
有 ’s 應用程式中發生未處理的例外狀況時的時間來收集傾印中最常見的點 — 當機。您可以使用傾印算出當機發生的原因，通常起始藉由查看錯誤的執行緒的呼叫堆疊。傾印會使用其他情況是應用程式當機和記憶體使用量的問題。
比方說如果您的網站已停止處理要求，您可能會附加一個偵錯工具、 收集傾印並重新啟動應用程式。比方說離線分析傾印的可能會顯示所有您處理要求的執行緒等候該資料庫的連接，或可能是程式碼中尋找死結。記憶體使用狀況問題可以資訊清單以各種方式從使用者 ’s 觀點來看：應用程式減慢因為的過多的記憶體回收 ； 服務會中斷，因為應用程式的虛擬記憶體不足，而需要重新啟動; 等等。
透過 CLR 2 偵錯 API 提供支援偵錯執行中的處理程序只，其中困難目標只是描述案例的工具。基本上，API 不被設計與偵錯案例記住的傾印。API 使用 Helper 執行緒來服務偵錯工具要求在目標處理序中執行事實 underscores 這一點。
比方說 CLR 2 中 Managed 偵錯工具要查核執行緒 ’s 堆疊時它會傳送要求至 Helper 執行緒被偵錯處理序中。在該處理序中的 CLR 服務要求，並傳回結果至偵錯工具。因為傾印只是檔案有在這種情況下 ’s 沒有 Helper 執行緒來服務要求。
若要提供解決方案的偵錯傾印檔案中的 Managed 程式碼，我們需要建造並未要求必須在目標來檢查 Managed 程式碼狀態中執行程式碼的 API。但因為寫入器 (主要是 Visual Studio) 偵錯工具在 CLR 偵錯 API 提供現場偵錯中已經有重大的投資，我們不是否要強制兩個不同的 API 使用。
我們登陸 CLR 4 中已 reimplementing 許多偵錯工具 API (主要的所需的程式碼和資料的視察) 若要移除的 Helper 執行緒使用。結果是現有 API 不再需要小心目標是傾印檔案] 或 [即時處理序。在另外偵錯工具撰寫者就可以使用相同的 API 到兩者即時和傾印偵錯案例的目標。當即時特別為執行控制偵錯 — 設定中斷點和逐步執行程式碼 — 偵錯 API 仍然使用 Helper 執行緒。透過的長期我們想要移除這些情況下的相依性。Rick Byers (在偵錯服務 API 前者開發人員) 有實用的部落，描述這項工作更詳細地在 blogs.msdn.com/rmbyers/archive/2008/10/27/icordebug-re-architecture-in-clr-4-0.aspx.
您現在可以使用 ICorDebug 檢查 Managed 程式碼和傾印檔案中的資料：堆疊查核行程、 列舉區域變數、 依此類推取得例外狀況型別。當機和當機，有 ’s 通常足夠內容可從執行緒堆疊和輔助的資料，以找出問題的原因。
我們知道記憶體診斷和其他案例也是重要我們只是沒有足夠的時間在 CLR 4 排程來建置新的 API 讓偵錯工具能夠檢查 Managed 的堆積的方式時需要這種情況。向前移動，我們繼續展開實際執行診斷案例我們支援，我相信這是我們將會加入的項目。在本文稍後我將討論我們以協助解決完成其他工作該分析藍本。
我也喜歡明確地呼叫這項工作支援 32 位元和 64 位元目標和同時管理僅和混合模式偵 (原生和 Managed) 錯。Visual Studio 2010 提供混合模式的傾印包含 Managed 程式碼。
監視器鎖定視察
多執行緒的程式設計可能會很困難。是否要明確地撰寫多執行緒程式碼或運用架構或正在做為您的程式庫，診斷非同步和平行程式碼中的問題可以是相當具挑戰性。當您在單一執行緒上執行工作的邏輯單元瞭解原因就會是更直接的方法，並且可以經常判斷藉由只查看執行緒 ’s 呼叫堆疊。但是，當該工作分割多個執行緒之間，追蹤流程成為得更難。為什麼工時未完成？是的某些部分封鎖上的東西嗎？
多核心變得 commonplace，開發人員正在尋找更多，多平行程式設計做效能改進的方法，而不是只需依賴晶片速度改進。Microsoft 開發人員包含在這個很多，而且過去幾年我們已大幅致力於讓此區域中會成功的開發人員更容易。以診斷觀點我們加上啟用工具，可協助開發人員更好的幾個簡單又幫助 API 應付多執行緒程式碼的複雜性。
CLR 偵錯工具 API 來我們新增監視器鎖定的檢查 API。簡單地說監視器提供一種方式，讓程式跨多個執行緒同步處理共用資源 (在您的.NET 程式碼中某些物件) 的存取。因此一個執行緒具有鎖定的資源，而另一個執行緒等候它。當擁有鎖定的執行緒會釋放它時，第一個執行緒等候現在可能會取得該資源。
在.NET] Framework 監視器會公開直接透過 System.Threading.Monitor] 命名空間，但更常透過鎖定和 SyncLock 關鍵字 (C# 和 Visual Basic 中的分別。它們也用於同步的方法、 [工作平行程式庫 (TPL) 和其他非同步程式設計模型的實作。新的偵錯工具 API 可讓您更加了解哪些物件如果有任何，指定的執行緒封鎖上以及何種執行緒如果有任何，持有鎖定指定的物件上。運用這些 API，偵錯工具可以協助開發人員找出死結及了解當對付資源 (鎖定護航) 的多個執行緒可能會影響應用程式 ’s 效能。
這項工作可讓工具類型的範例，請檢查出偵錯功能，在 Visual Studio 2010 平行。提供絕佳概觀這些在九月 2009年問題的 奧 Moth 和提夫 ToubMSDN 雜誌 (msdn.microsoft.com/magazine/ee410778).
excites 我們關於傾印偵錯工作大部分是建置偵錯目標的抽象的檢視時表示新的視察功能的事情之一加入，如 [監視器鎖定檢查] 功能提供即時兩者的值和偵錯案例的傾印。預期為開發人員非常珍貴，它們最初開發應用程式時這項功能時它 ’s 傾印偵錯 CLR 4] 中使監視器鎖定視察吸引人的加法生產診斷功能的支援。
黛 Ferrandez Microsoft 支援工程師具有通道 9 視訊 (channel9.msdn.com/posts/Glucose/Hanselminutes-on-9-debugging-crash-dumps-with-Tess-Ferrandez-and-VS2010/) 在其中她模擬什麼她已經找到疑難排解客戶的應用程式時的一般鎖定護航艦隊案例。她接著逐步如何使用 Visual Studio 2010 來診斷問題。它 ’s 啟用這些新功能的案例類型中的一個好範例。
超過傾印
雖然我們相信這些功能可讓的工具有助於減少開發人員可以解決在實際執行環境的問題所需的時間量， we 做不預期 (也想要) 唯一的方法來診斷生產問題偵錯傾印。
在診斷問題的過多的記憶體使用問題的情況下我們通常以開始根據其計數與彙總大小與瞭解物件參考鏈結的進展的型別編組來的物件執行個體的清單。shuttling 包含這項資訊生產及開發機器作業人員之間的傾印檔案支援工程師和開發人員可以冗長且耗時。以及應用程式變大 — 這是特別常見與 64 位元應用程式 — 傾印檔案也會變大，並且花較長的時間來四處移動和處理。它是與這些高階的案例，別忘了，我們準備下列章節所述的程式碼剖析功能。
分析工具
有許多不同類型的工具建置的頂端 CLR 程式碼剖析 API。通常涉及程式碼剖析 API 的案例把重點放在三個功能分類：效能、 記憶體和檢測。
效能分析工具 (如船在某些 Visual Studio 版本中的) [專注於告訴您的程式碼花的時間。記憶體分析工具著重於詳細描述應用程式 ’s 記憶體耗用量。執行檢測的分析工具動作，良好，其餘的項目。
讓我有點釐清的最後一個陳述式。一種設備程式碼剖析 API 提供是能夠插入中繼語言 (IL) 至 Managed 程式碼在執行階段。我們呼叫此程式碼檢測。客戶使用這項功能來建置傳遞自程式碼涵蓋範圍的範圍廣泛的案例的.NET Framework 為基礎的應用程式對企業級生產監視錯誤注入的工具。
其中一個程式碼剖析 API 的偵錯 API 高於好處是它設計為極輕量。兩者都是事件驅動的 API —，例如在組件載入為兩者都有事件，執行緒建立，所擲回例外狀況等等 — 但僅供您關心的事件註冊的程式碼剖析 API。此外，程式碼剖析的 DLL 會載入目標處理程序內確保執行時間狀態的快速存取。
相較之下，偵錯工具 API 報告每個事件到已逾時的處理序偵錯工具附加時，並會在執行階段暫止上每個事件。這些是只需幾個程式碼剖析 API 是一個吸引人的選項來建置為目標的生產環境的線上診斷工具的原因。
程式碼剖析工具附加和卸離
雖然許多廠商都建置永遠-上，實際執行應用程式監視工具，透過 IL 檢測，我們並沒有充分運用效能和記憶體監視設備中程式碼剖析 API 提供反應式的診斷支援許多工具。在此案例中主要對造成阻礙已經無法附加 CLR 程式碼剖析 API 為基礎的工具，來已經執行的程序。
在前面 CLR 4 的版本中 CLR 會檢查來查看是否程式碼剖析工具已註冊的啟動過程。如果它在找到已註冊的程式碼剖析工具在 CLR 載入它，並依要求會傳遞回呼。DLL 會永遠不會被卸載。這是通常細緻如果工具 ’s 工作來建置的應用程式行為的端對端圖片中，但不適用於 didn’t 知道的問題存在於應用程式啟動時。
或許最痛苦的範例之一是記憶體使用量診斷的案例。今天，在這種情況下我們常發現的診斷模式是來收集多個傾印、 查看之間每個配置類型差異、 建置的成長，時間表，然後在應用程式程式碼中尋找可疑的型別會被參考。或許問題在於不良實作快取配置，或也許中一種類型的事件處理常式會保有 ’s 否則的範圍之外的另一種類型的參考。客戶和支援工程師花大量時間診斷這類問題。
比方首先如前所述簡短地，傾印的大型處理程序是大型本身，向專家來取得的診斷可以介紹長時間延遲時間中解析度。進一步，是您不必牽涉到的專家，主要是因為的資料只透過 Windows 偵錯工具延伸公開的問題。有 ’s 可讓消耗資料，並建置直覺檢視它的上方或整合與其他工具可以協助您分析工具沒有公用 API。
若要減輕這種情況下 (以及一些其他人) 的痛苦，我們加入新的 API，讓分析工具附加至執行中的處理序，並充分利用現有的程式碼剖析 API 的子集。附加至處理序之後，您可以使用的那些允許取樣 (請參閱 「 VS 2010::附加在程式碼剖析工具至受管理的應用程式 」 在 blogs.msdn.com/profiler/archive/2009/12/07/vs2010-attaching-the-profiler-to-a-managed-application.aspx) 和記憶體診斷：查核堆疊 ； 對應函式位址到符號的名稱 ； 大部分的記憶體回收行程 (GC) 回呼 ； 以及將物件的檢查。
在案例中只說明，工具可以運用這項功能允許客戶附加至應用程式遇到較慢的回應時間或過多的記憶體成長時，瞭解什麼 ’s 目前執行，以及知道什麼類型存留在 Managed 堆積上，以及什麼保持它們活著。之後蒐集資訊，分離工具，CLR 會卸載程式碼剖析工具 DLL]。雖然工作流程的其餘部分將會很類似 — 正在尋找參考或在程式碼中建立這些類型的位置 — 我們預期在平均數-時間-至-解析度針對這些問題上具有可調大小的影響此性質的工具。Dave Broman 開發人員在程式碼剖析 API，在 CLR 上討論這和深入其他程式碼剖析功能上他的部落格 (blogs.msdn.com/davbr).
我不過，，要明確地在本文中的兩個限制對外呼叫。記憶體診斷在附加前，受限於非同時 (或封鎖) GC 模式：當 GC 暫止所有 Managed 程式碼執行時執行一個 GC。雖然並行的 GC 預設 ASP.NET 會使用伺服器模式 GC 即非同時模式。這是在其中，我們看到這些問題的大部分的環境。我們嗎感謝附加-程式碼剖析用戶端應用程式的診斷用途，並希望在未來的版本中傳遞此。我們只是針對 CLR 4 優先順序更常見的情況。
第二個，而無法使用要檢測 IL 程式碼剖析 API 之後附加。這項功能是我們企業監視工具廠商希望能變更其檢測動態地在執行階段條件回應特別重要的。我們常把這項功能稱為回覆 JIT。今天，您有一個機會變更 IL 主體的方法：當它先被 JIT 編譯。我們預期提供回覆-JIT 是重大及重要 ． 並主動地調查客戶價值和技術的含意當我們在考慮在未來的版本中傳遞工作。
無登錄的分析工具的啟動
程式碼剖析工具附加，並支援工作的啟用後的特定程式碼剖析 API 附加了最大份工作程式碼剖析 API 的 CLR 4 CLR 中我們做。但我們樂意尋找另一個非常小 (方面工程成本) 的功能，對客戶建置工具，生產類別的是令人意外大的影響。
CLR] 4 工具來取得其程式碼剖析工具 DLL 之前先載入受管理的應用程式，它必須建立兩個索引鍵部份的組態資訊。第一個被一對的告知來啟用程式碼剖析 CLR 的環境變數和載入 (其 CLSID 或 ProgID) 何種程式碼剖析工具實作 CLR 啟動時。假設程式碼剖析工具 DLL 會實作成同處理序 COM 伺服器 (與 CLR 所用戶端)，第二段組態資料已對應的 COM 註冊資訊儲存在登錄中。這基本上告知執行階段的 COM，何處可以找到 DLL 在磁碟上。
嘗試了解如何我們可以讓更容易建置生產類別工具廠商時 CLR 4 規劃期間我們與我們的支援工程師和工具廠商的某些一些有趣交談。我們收到的意見反應是，面臨在生產環境中發生應用程式失敗時客戶通常負責小於有關應用程式的影響 (已經失敗; 他們只想取得診斷資訊，並移動上) 和更多關於該機器的狀態的影響。許多客戶前往大費周章記錄和 police 其機器的設定，該組態中引入的變更可能造成風險。
所以，相對於方案的 [CLR ’s 一部分我們想要讓它可能啟用可 xcopy 部署診斷工具，這兩風險的狀態變更，並減少取得工具所需花費的時間降至最低，並在電腦上的執行。
在 CLR 4 我們移除需要在登錄中註冊 COM 分析工具 DLL。我們仍需要環境變數如果要啟動您的應用程式，在程式碼剖析工具下，但在先前的詳細案例附加，沒有沒有所需的設定。A 工具只是新附加傳遞的 API 的呼叫路徑 DLL 和 CLR 載入程式碼剖析工具。向前移動，我們尋找到客戶仍然找到環境變數方案在某些案例中具挑戰性的進一步簡化程式碼剖析工具組態的方式。
結合，只討論這兩個程式碼剖析功能可讓客戶可以在未預期的失敗的情況下快速部署到實際執行機器來收集效能或記憶體診斷資訊，以協助找出造成問題的原因的低負荷工具類別。然後就像快速，使用者可以為其原始狀態傳回機器。
總結
在診斷功能上的 [工作] 的 CLR 是 bittersweet。我看到許多的特定問題的客戶奮力多少範例並尚有 ’s 永遠酷工作，我們可以做來協助簡化開發，並讓客戶更快樂。如果 isn’t 變更該清單的挑戰我們的客戶的問題 — 也就我們不移除項目它 — 然後我們不成功。
在 CLR 4 我認為我們建置不僅提供解決部分的頂端的客戶問題的即時運算值，而且也奠定的基礎，在其我們可以繼續在未來建置的功能。向前移動，我們將繼續投資在 API 和服務，可讓您更容易公開應用程式 ’s 生命的所有階段中有意義的診斷資訊，因此您可以專注在為客戶建置新功能的更多時間和偵錯現有的較少時間。
如果您 ’re 興趣提供我們意見對我們考慮我們下一個發行的診斷工作，我們張貼在 問卷surveymonkey.com/s/developer-productivity-survey.當我們現在是關於以船 CLR 4，我們著重大部分我們的時間在即將發行的規劃，調查的資料將會幫助我們排定優先順序我們努力。如果您數分鐘我們會喜歡聽到您的。
Jon Langdon 他專注在診斷是 CLR 團隊上的一個程式管理員。之前要加入 CLR 團隊，他是使用 Microsoft 服務幫助客戶診斷並修正大規模，企業應用程式的問題顧問。
多虧給來檢閱這份文件的技術專家下列：Rick Byers