本主題描述追蹤數據的格式、如何檢視它，以及使用服務追蹤查看器對應用程式進行疑難解答的方法。
使用服務追蹤檢視工具
Windows Communication Foundation （WCF） 服務追蹤查看器工具可協助您將 WCF 接聽程式所產生的診斷追蹤相互關聯，找出錯誤的根本原因。 此工具可讓您輕鬆地檢視、分組和篩選追蹤，以便診斷、修復和驗證 WCF 服務的問題。 如需使用此工具的詳細資訊，請參閱服務追蹤查看器工具 （SvcTraceViewer.exe）。
本主題包含使用服務追蹤查看器工具 （SvcTraceViewer.exe） 檢視時，執行追蹤和訊息記錄範例所產生的追蹤螢幕快照。 本主題示範瞭如何理解追蹤內容及活動與其關聯性，並在疑難排解中分析大量追蹤。
檢視追蹤內容
追蹤事件包含下列最重要的資訊：
設定時的活動名稱。
發射時間。
追蹤層級。
追蹤來源名稱。
處理序名稱。
線程標識碼。
唯一的追蹤識別符，這是指向 Microsoft 技術參考文件的 URL，可提供與追蹤相關的詳細資訊。
在 [服務追蹤查看器] 的右上方面板中，或在選取追蹤時，右下角面板之格式化檢視的 [ 基本資訊] 區段中可以看到所有這些資訊。
備註
如果客戶端和服務位於同一部計算機上，則這兩個應用程式的追蹤將會存在。 您可以使用 處理序名稱 欄來篩選這些項目。
此外，格式化視圖還會提供追蹤的描述，以及其他詳細資訊（如果有）。 後者可以包含例外狀況類型和訊息、呼叫堆疊、訊息動作、從/到字段，以及其他例外狀況資訊。
在 XML 檢視中，有用的 xml 標籤包含以下內容：
<SubType>（追蹤層級）。<TimeCreated>。<Source>（追蹤來源名稱）。<Correlation>（在發出追蹤時設定的活動識別碼）。<Execution>（進程和線程標識碼）。<Computer>。<ExtendedData>，包括<Action>、<MessageID>和在傳送訊息時設定於訊息標頭中的<ActivityId>。
如果您檢查「透過通道傳送訊息」的追踪，您可能會看到下列內容。
<E2ETraceEvent xmlns="http://schemas.microsoft.com/2004/06/E2ETraceEvent">
<System xmlns="http://schemas.microsoft.com/2004/06/windows/eventlog/system">
<EventID>262163</EventID>
<Type>3</Type>
<SubType Name="Information">0</SubType>
<Level>8</Level>
<TimeCreated SystemTime="2006-08-04T18:45:30.8491051Z" />
<Source Name="System.ServiceModel" />
<Correlation ActivityID="{bbbb1111-cc22-3333-44dd-555555eeeeee}"/>
<Execution ProcessName="client" ProcessID="1808" ThreadID="1" />
<Channel />
<Computer>TEST1</Computer>
</System>
<ApplicationData>
<TraceData>
<DataItem>
<TraceRecord xmlns="http://schemas.microsoft.com/2004/10/E2ETraceEvent/TraceRecord" Severity="Information">
<TraceIdentifier>http://msdn.microsoft.com/library/System.ServiceModel.Channels.MessageSent.aspx</TraceIdentifier>
<Description>Sent a message over a channel.</Description>
<AppDomain>client.exe</AppDomain>
<Source>System.ServiceModel.Channels.ClientFramingDuplexSessionChannel/35191196</Source>
<ExtendedData xmlns="http://schemas.microsoft.com/2006/08/ServiceModel/MessageTransmitTraceRecord">
<MessageProperties>
<AllowOutputBatching>False</AllowOutputBatching>
</MessageProperties>
<MessageHeaders>
<Action d4p1:mustUnderstand="1" xmlns:d4p1="http://www.w3.org/2003/05/soap-envelope" xmlns="http://www.w3.org/2005/08/addressing">http://Microsoft.ServiceModel.Samples/ICalculator/Multiply</Action>
<MessageID xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:7c6670d8-4c9c-496e-b6a0-2ceb6db35338</MessageID>
<ActivityId CorrelationId="aaaa0000-bb11-2222-33cc-444444dddddd" xmlns="http://schemas.microsoft.com/2004/09/ServiceModel/Diagnostics">bbbb1111-cc22-3333-44dd-555555eeeeee</ActivityId>
<ReplyTo xmlns="http://www.w3.org/2005/08/addressing">
<Address>http://www.w3.org/2005/08/addressing/anonymous</Address>
</ReplyTo>
<To d4p1:mustUnderstand="1" xmlns:d4p1="http://www.w3.org/2003/05/soap-envelope" xmlns="http://www.w3.org/2005/08/addressing">net.tcp://localhost/servicemodelsamples/service</To>
</MessageHeaders>
<RemoteAddress>net.tcp://localhost/servicemodelsamples/service</RemoteAddress>
</ExtendedData>
</TraceRecord>
</DataItem>
</TraceData>
</ApplicationData>
</E2ETraceEvent>
ServiceModel E2E 追蹤分析
當追蹤來源設定為除了 Off 的其他值時，WCF 會建立活動和傳輸以供 WCF 處理。
活動是一個邏輯處理單元，將與該處理單元相關的所有痕跡進行分組。 例如，您可以為每個要求定義一個活動。 傳輸會在端點內的活動之間建立因果關係。 傳播活動標識碼可讓您跨端點建立活動關聯。 這可以透過在每個端點的組態中設定 propagateActivity=true 來完成。 活動、轉移和傳播讓您可以執行錯誤關聯。 如此一來，您可以更快速地找到錯誤的根本原因。
在用戶端上，會為每個物件模型呼叫建立一個 WCF 活動（例如 Open ChannelFactory、Add、Divide 等等。每個作業呼叫都會在「處理動作」活動中處理。
在下列螢幕快照中，從 追蹤和訊息記錄 範例擷取的左側面板會顯示在用戶端程式中建立的活動清單，依建立時間排序。 以下是活動的時序列表：
建構信道處理站 （ClientBase）。
開啟通道處理站。
已處理 [新增] 動作。
設定安全會話（第一個要求時發生此事件），並處理了三個安全性基礎結構回應消息：RST、RSTR、SCT（處理訊息 1、2、3）。
已處理減去、乘法和除法要求。
關閉通道處理站，然後這樣做會關閉安全會話，並處理安全性訊息回應 Cancel。
我們因為使用 wsHttpBinding 而看到安全性基礎結構訊息。
備註
在 WCF 中，我們會先在個別活動 （處理訊息） 中顯示正在處理的回應訊息，再透過傳輸將它們與包含要求訊息的對應處理動作活動相互關聯。 這種情況會發生在基礎結構訊息和異步請求中，這是因為我們必須檢查訊息、讀取 activityId 標題，並識別現有的程序操作活動，確保其與該標識相互關聯。 針對同步要求，我們會封鎖回應，因此知道回應所關聯的進程動作。
下圖顯示 WCF 客戶端活動，依據建立時間列出（左面板），並顯示其巢狀活動和追蹤（右上面板）：
當我們在左側面板中選擇一個活動時，可以在右上方的面板中看到其巢狀活動和追蹤記錄。 因此，這會根據選取的父活動，減少左側活動清單的階層式檢視。 由於選取的 [程序] 動作 [新增] 是第一個請求，此活動包含 [設定安全會話] 活動（傳送至、再傳送回），以及對 [新增] 動作的具體處理追蹤。
如果我們按兩下左側面板中的 [處理] 動作 [新增活動]，我們可以看到與 [新增] 相關的用戶端 WCF 活動的圖形表示法。 左邊的第一個活動是根活動 （0000），這是預設活動。 WCF 會從周圍環境中的活動抽離。 如果未定義，WCF 會從 0000 中移出。 在這裡，第二個活動「處理動作新增」會從 0 轉移出。 然後，我們會看到設定安全會話。
下圖顯示 WCF 用戶端活動的圖表檢視，特別是環境活動（這裡為 0）、處理動作和設定安全工作階段：
在右上方面板上，我們可以看到與 [處理動作新增] 活動相關的所有追蹤。 具體而言，我們已在相同活動中傳送要求訊息（「透過通道傳送訊息」）並接收回應（「透過通道接收訊息」。 下圖所示。 為了清楚起見，設定安全會話活動會在圖形中折疊。
下圖顯示進程動作活動的追蹤項目列表。 我們會傳送要求，並在相同的活動中接收回應。
在這裡，我們只為了清楚起見而載入客戶端追蹤，但如果服務追蹤（接收到要求訊息及傳送出的回應訊息）同時在工具中載入，也將會出現在相同的活動中，且 propagateActivity 被設定為 true.。這在稍後的圖例中會顯示出來。
在服務上，活動模型會對應至WCF 概念，如下所示：
我們建構並開啟 ServiceHost（這可能會建立與主機相關的多個活動，例如在涉及安全性時）。
我們為 ServiceHost 中的每個接聽者創建一個接聽活動（在開啟 ServiceHost 時進行的傳入和傳出操作）。
當接聽程式偵測到用戶端起始的通訊要求時，它會傳送至「接收位元組」活動，其中會處理從用戶端傳送的所有位元組。 在此活動中，我們可以看到用戶端服務互動期間發生的任何連線錯誤。
針對每組接收到且對應於訊息的位元組資料，我們會在「處理訊息」活動中建立 WCF Message 物件並處理這些位元組資料。 在此活動中，我們會看到與錯誤信封或格式不正確的訊息相關的錯誤。
訊息形成之後，我們會轉至流程動作活動。 如果在
propagateActivity用戶端和服務上設定為true，則此活動具有與用戶端中定義的識別碼相同的識別碼，如前所述。 在此階段，我們開始受益於端點之間的直接關聯，因為所有與要求相關的 WCF 追蹤，以及回應訊息處理，都屬於同一活動。針對外部進程操作，我們會建立「執行使用者程式代碼」事件，以隔離使用者程式代碼中發出的追蹤與 WCF 中發出的追蹤。 在上述範例中，追蹤「服務傳送新增回應」會發生在「執行使用者程式代碼」活動中，而不是在用戶端所傳播的活動中（如果適用的話）。
在下圖中，左側的第一個活動是根活動 （0000），這是預設活動。 接下來的三個活動是開啟 ServiceHost。 第5欄的活動是監聽器，其餘的活動（6到8）描述訊息的WCF處理過程，從位元組處理到用戶代碼的啟動。
下圖顯示 WCF 服務活動的圖表檢視：
下列螢幕擷取畫面顯示用戶端和服務的活動，並以橙色醒目顯示「跨流程」中的「新增處理動作」活動。 箭頭會關聯客戶端和服務所傳送和接收的要求和回應訊息。 [處理動作] 的追蹤會跨圖形中的進程分隔，但顯示為右上方面板中相同活動的一部分。 在此面板中，我們可以看到已傳送訊息的用戶端追蹤，後面接著已接收和已處理訊息的服務追蹤。
下圖顯示 WCF 用戶端和服務活動的圖表檢視
在以下錯誤情境中，服務端和客戶端的錯誤以及警告追蹤是相關的。 例外狀況會先在服務中的用户代码中發生（最右邊的綠色活動，其中包含例外狀況的警告追蹤「服務無法在用户代码中處理此要求」）。 當回應傳送至客戶端時，會再度發出警告記錄以標示故障訊息（左側粉紅色活動）。 然後，用戶端會關閉其 WCF 用戶端（左下角的黃色活動），這會中止與服務的連線。 右邊最長的粉紅色活動會導致服務拋出錯誤。
服務和客戶端之間的錯誤關聯性
用來生成這些追蹤的範例是一系列使用 wsHttpBinding 的同步請求。 對於沒有安全性或異步要求的案例，此圖表有偏差，其中 Process Action 活動包含構成異步呼叫的開始和結束作業，並顯示對回呼活動的傳輸。 如需其他情境的詳細資訊，請參閱 結束To-End 追蹤場景。
使用服務追蹤查看器進行故障排除
當您在服務追蹤查看器工具中載入追蹤檔案時，可以在左側面板中選取任何紅色或黃色活動，以追蹤應用程式中發生問題的原因。 000 活動通常會有未處理的例外狀況，會向使用者傳出。
下圖顯示如何選取紅色或黃色活動來找出問題的根本原因。
在右上角的面板上，您可以檢查您在左側選擇的活動的痕跡。 然後，您可以檢查該面板中的紅色或黃色痕跡，並查看它們相互關聯的方式。 在上圖中，我們在相同的流程操作活動中看到客戶端和服務的警告追蹤。
如果這些追蹤紀錄未提供錯誤的根本原因，您可以透過按兩下左面板上的選定活動來查看或分析圖表（這裡的 Process action）。 接著會顯示具有相關活動的圖表。 然後，您可以點擊“+” 符號展開相關活動，以便在相關活動中尋找第一個發出紅色或黃色的追蹤事件。 請繼續擴充感興趣的紅色或黃色追蹤活動之前所發生的活動，並傳輸至相關活動或訊息流程，遍及各端點，直到您追蹤到問題的根本原因。
擴充活動以追蹤問題的根本原因
如果 ServiceModel ActivityTracing 已關閉，但 ServiceModel追蹤已開啟，您可以看到在 0000 活動中發出的 ServiceModel追蹤。 不過，這需要更多的努力來瞭解這些追蹤的關聯性。
如果已啟用訊息記錄，您可以使用 [訊息] 索引標籤來查看哪些訊息受到錯誤的影響。 按兩下紅色或黃色的訊息，即可查看相關活動的圖表檢視。 發生錯誤的要求與這些活動最密切相關。
若要開始進行疑難解答，您也可以挑選帶有紅色或黃色提示的訊息追蹤，然後按兩下尋找根本原因。