本主题介绍跟踪数据的格式、查看方式以及使用服务跟踪查看器对应用程序进行故障排除的方法。
使用服务跟踪查看器工具
Windows Communication Foundation （WCF） 服务跟踪查看器工具可帮助你关联 WCF 侦听器生成的诊断跟踪，以查找错误的根本原因。 该工具提供了一种轻松查看、分组和筛选跟踪的方法，以便诊断、修复和验证 WCF 服务的问题。 有关使用此工具的详细信息，请参阅服务跟踪查看器工具（SvcTraceViewer.exe）。
本主题包含运行跟踪和消息日志记录示例生成的跟踪在通过服务跟踪查看器工具 (SvcTraceViewer.exe) 查看时的情况的屏幕截图。 本主题演示如何了解跟踪内容、活动及其相关性，以及如何在故障排除时分析大量跟踪。
查看跟踪内容
跟踪事件包含以下最重要的信息：
设置时的活动名称。
发射时间。
跟踪级别。
跟踪源名称。
进程名称。
线程 ID。
唯一的跟踪标识符，它是指向 Microsoft 技术参考的 URL，该参考提供了与跟踪相关的更多信息。
所有这些内容都可以在服务跟踪查看器的右上角面板中看到，或者在选择跟踪时，在右下角面板的格式化视图的“基本信息”部分中看到。
注释
如果客户端和服务在同一台计算机上，则两个应用程序的跟踪将存在。 可以使用 “进程名称 ”列筛选这些属性。
此外，格式化视图还提供跟踪说明以及可用时的其他详细信息。 后者可以包括异常类型和消息、调用堆栈、消息操作、从/到字段以及其他异常信息。
在 XML 视图中，有用的 xml 标记包括：
<SubType>（跟踪级别）。<TimeCreated>。<Source>（跟踪源名称）。<Correlation>（发出跟踪时设置的活动 ID）。<Execution>（进程和线程 ID）。<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 之外的 switchValue 以及 ActivityTracing 设置 System.ServiceModel 跟踪源时，WCF 将创建活动和传输进行 WCF 处理。
活动是一个逻辑处理单元，用于对与该处理单元相关的所有跟踪进行分组。 例如，可以为每个请求定义一个活动。 传输在终结点内的活动之间创建因果关系。 传播活动 ID 使你能够跨终结点关联活动。 可以通过在每个端点上设置 propagateActivity=true 配置来实现这一操作。 活动、传输和传播允许您执行错误关联。 通过这种方式，可以更快地找到错误的根本原因。
在客户端上，为每个对象模型调用创建一个 WCF 活动（例如，Open ChannelFactory、Add、Divide 等）。每个作调用都在“进程作”活动中进行处理。
在以下屏幕截图中，从 “跟踪和消息日志记录 ”示例中提取的左侧面板显示客户端进程中创建的活动列表，按创建时间排序。 下面是按时间顺序排列的活动列表：
构造了通道工厂 (ClientBase)。
打开了通道工厂。
处理了加操作。
设置安全会话（此事件发生在第一个请求上），并处理了三条安全基础结构响应消息：RST、RSTR、SCT（处理消息 1、2、3）。
处理了减法、乘法和除法请求。
关闭了通道工厂，这样做还关闭了安全会话并处理安全消息响应 Cancel。
我们看到由于 wsHttpBinding 所致的安全基础结构消息。
注释
在 WCF 中，响应消息最初在一个单独的活动（处理消息）中进行处理，然后通过传递将其与包含请求消息的相应处理动作活动相关联。 这发生在基础结构消息和异步请求中，这是因为我们必须检查消息、读取 activityId 标头，并识别具有该 ID 的现有进程作活动来关联它。 对于同步请求，我们将为响应截留这些信息，因此可以知道响应与哪个处理操作相关。
下图显示了通过创建时间（左面板）及其嵌套活动和跟踪（右上方面板）列出的 WCF 客户端活动：
在左面板中选择一个活动时，可以在右上面板上看到其嵌套活动和跟踪。 因此，这是左侧活动列表的简化分层视图（基于所选的父活动）。 因为所选处理操作“加”是发出的第一个请求，所以此活动包含“设置安全会话”活动（传输到，再传输回）和对“加”操作实际处理的跟踪。
如果我们双击左侧面板中的“进程操作添加活动”，就可以看到与“添加”相关的客户端 WCF 活动的图形表示形式。 左侧的第一个活动是根活动（0000），这是默认活动。 WCF 在环境活动之外传输。 如果未定义此活动，则 WCF 在 0000 之外传输。 在这里，第二个活动“处理操作添加”在 0 之外传输。 然后，我们看到“设置安全会话”。
下图显示了 WCF 客户端活动的图形视图，特别是环境活动（此处 0）、进程作和设置安全会话：
在右上面板中，可以看到与“处理操作添加”活动相关的所有跟踪。 具体而言，我们已在同一活动中发送了请求消息（“通过通道发送了消息”），并收到了响应（“已通过通道收到消息”。 下图中显示了这种情况。 为清楚起见，图形中折叠了“设置安全会话”活动。
下图显示了过程操作活动的追踪列表。 我们发送请求并在同一活动中接收响应。
此处，我们仅为了清晰起见加载客户端跟踪，但如果服务跟踪（收到请求消息和发送响应消息）也加载到了工具中，并且 propagateActivity 已设置为 true.，那么服务跟踪也会显示在后面的图示中。
在服务上，活动模型映射到 WCF 概念，如下所示：
我们构造并打开 ServiceHost（这可能创建多个与主机相关的活动，例如，在安全性方面）。
在 ServiceHost 中为每个侦听器创建“侦听”活动（包括传入和传出“打开 ServiceHost”）。
当侦听器检测到客户端发起的通信请求时，它会传输到“接收字节”活动，在该活动中处理从客户端发送的所有字节。 在此活动中，我们可以看到客户端服务交互期间发生的任何连接错误。
对于收到的与消息对应的每组字节，我们在创建 WCF 消息对象的“进程消息”活动中处理这些字节。 在此活动中，我们看到与错误信封或格式不正确的邮件相关的错误。
形成消息后，传输到“处理操作”活动。 如果在客户端和服务中都将
propagateActivity设置为true，则此活动将拥有与客户端中定义的相同 ID，并且此前已进行描述。 在此阶段，我们开始受益于跨终结点的直接关联，因为 WCF 中发出的所有与请求相关的跟踪都位于同一活动中，包括响应消息处理。对于进程外作，我们将创建一个“执行用户代码”活动，将用户代码中发出的跟踪与 WCF 中发出的跟踪隔离开来。 在前面的示例中，“服务发送添加响应”跟踪是在“执行用户代码”活动中发出的，而不是在客户端传播的活动中（如果适用）。
在下图中，左侧的第一个活动是根活动（0000），这是默认活动。 接下来的三个活动是打开 ServiceHost。 第 5 列中的活动是侦听器，其余活动（6 到 8）描述消息的 WCF 处理，从字节处理到用户代码激活。
下图显示了 WCF 服务活动的图形视图：
以下屏幕截图显示了客户端和服务的活动，并用橙色突出显示了跨进程的“添加进程操作”活动。 箭头将客户端和服务发送和接收的请求和响应消息相关联。 跨进程处理操作的跟踪在图形中单独显示，但在右上面板中作为同一活动的一部分显示。 在此面板中，我们可以看到已发送消息的客户端跟踪，随后是已接收和处理消息的服务跟踪。
下图显示了 WCF 客户端和服务活动的图形视图
在下面的错误情形中，服务和客户端上的错误和警告跟踪是相关的。 异常首先在服务中的用户代码中被引发（最右侧的绿色活动，其中包含异常的警告跟踪：“服务无法在用户代码中处理此请求。”）。 将响应发送到客户端时，会再次发出警告跟踪以指示错误消息（左侧的粉红色活动）。 然后，客户端关闭其 WCF 客户端（左下侧的黄色活动），这会中止与服务的连接。 服务引发一个错误（右侧最长的粉红色活动）。
跨服务和客户端的错误关联
用于生成这些跟踪的示例是一系列使用 wsHttpBinding 的同步请求。 对于没有安全性或具有异步请求的情形，与此图形存在偏差，其中处理操作活动包括造成异步调用的开始操作和结束操作，并显示到回调活动的传输。 有关其他方案的详细信息，请参阅端到端跟踪方案。
使用服务跟踪查看器进行故障排除
在服务跟踪查看器工具中加载跟踪文件时，可以选择左侧面板中的任何红色或黄色活动来跟踪应用程序中出现问题的原因。 000 活动通常具有未经处理的异常，这些异常会弹出给用户。
下图显示了如何选择红色或黄色活动来查找问题的根源。
您可以在右上角的面板中查看左侧所选活动的跟踪记录。 然后，您可以检查该面板中的红色或黄色痕迹，并查看它们如何关联。 在前面的图表中，我们在同一活动流程中同时看到了客户端和服务的警告记录。
如果这些跟踪未提供错误的根本原因，则可以通过双击左面板上的所选活动（此处为处理操作）来利用图形。 然后会显示包含相关活动的图形。 然后可以展开相关活动（单击“+”符号），以找出相关活动中发出的第一个红色或黄色跟踪。 在传输到相关活动或跨终结点的消息流之后，一直展开刚好在相关的红色或黄色跟踪之前发生的活动，直到查明问题的根本原因为止。
扩展活动以跟踪问题的根本原因
如果已关闭 ServiceModel ActivityTracing 但打开了 ServiceModel 跟踪，则可以看到在 0000 活动中发出的 ServiceModel 跟踪。 但是，这需要更多的努力来理解这些跟踪信息的关联性。
如果已启用消息日志记录，可以使用“消息”选项卡查看哪些邮件受错误影响。 通过双击红色或黄色的消息，可以查看相关活动的图形视图。 这些活动与发生错误的请求最紧密相关。
若要开始故障排除，还可以选取红色或黄色消息跟踪，然后双击它来跟踪根本原因。