通过

如何在 BizTalk Server 进程中排查内存泄漏或内存不足异常

本文介绍如何排查 Microsoft BizTalk Server 的 BizTalk Server 进程中的内存泄漏或内存不足异常。

原始产品版本： BizTalk Server 2010、2009
原始 KB 数： 918643

总结

内存泄漏是一个常见问题。 可能需要尝试几个步骤来查找Microsoft BizTalk Server 中内存泄漏或内存不足（OOM）异常的特定原因。 本文讨论评估内存使用情况和可能的内存相关问题时要考虑的重要事项。 这些注意事项包括以下事项：

  • 物理 RAM
  • 大型消息处理
  • 使用 /3GB 交换机
  • 使用自定义组件
  • 系统运行的Microsoft .NET Framework 版本
  • 处理器的数目

当Microsoft Windows 任务管理器中的内存使用率消耗超过物理 RAM 的 50% 时，BizTalk Server 进程可能会遇到内存泄漏。 当内存使用率增加时，内存泄漏可能会导致内存不足异常，直到进程耗尽系统内存或进程停止运行为止。 对于此问题，请考虑以下事项：

物理 RAM 和内存使用情况

由于进程可能会预期使用大约一半的物理RAM，因此请将内存使用情况作为指导。 例如，如果 BizTalk Server 的 RAM 为 4 GB（GB），并且 BizTalk Server 进程使用约 500 兆字节（MB）的 RAM，则可能不会泄漏。 如果 BizTalk Server 进程使用大约 1 GB 的 RAM，则可能存在内存泄漏或内存过高的情况。 内存消耗可能是由长时间运行的存储过程或业务流程引起的。 请确保您了解 BizTalk 主机通常的内存使用量，以确定是否发生内存泄漏或内存使用过高的情况。

大型消息

当 BizTalk Server 处理大型消息时，系统似乎有内存泄漏。 但是，消息可能正在使用大量内存。

此外，如果 BizTalk Server 正在处理大型消息，请考虑预期内存使用率较高。 你可能想要升级硬件，以满足环境中的 BizTalk Server 的性能要求。

重现内存泄漏需要多长时间

内存泄漏可以立即发生，或者可能会随着时间的推移而累积。 这两种方案都是常见的。

在 32 位计算机上使用 /3GB 开关

通常，进程可以访问 2 GB 的虚拟地址空间。 /3GB 交换机是需要更多可寻址内存的系统的选项。 此选项可以提高处理消息的内存使用率。 但是，/3GB 开关 只允许 1 GB 的可寻址内存用于内核模式操作。 此外，此开关可能会增加池内存不足的风险。

在 32 位版本的 Windows 上启用 /3GB 交换机 时，如果进程知道大地址，进程可以访问 3 GB 的虚拟地址空间。 当可执行文件在映像标头中设置了 IMAGE_FILE_LARGE_ADDRESS_AWARE 标志时，进程可以识别大地址。 由于 BizTalk 进程可识别大地址，因此 BizTalk 将受益于 /3GB 交换机。

如果 32 位 BizTalk 主机实例在 64 位版本的 Windows 上运行（AMD64），则 BizTalk 进程受益于 4 GB 内存地址空间，因为 BizTalk 可以识别大地址。 因此，将高内存应用程序移动到 64 位服务器可能是最佳解决方案。

64 位版本的 Windows（AMD64）上的 64 位 BizTalk 进程具有 8 TB 的可寻址内存。

还应考虑虚拟字节和进程使用的专用字节。 BizTalk 主机实例（即 .NET Framework 应用程序）可能会在虚拟字节值达到 2 GB 之前收到内存不足错误。 即使 32 位版本的 Windows（没有 /3GB 开关）上的进程可寻址的最大内存为 2 GB，也可能出现这种情况。 有关这种情况发生的原因的说明，请访问以下Microsoft开发人员网络（MSDN）网站：
ASP.NET 性能监视，以及何时向管理员发出警报

/3GB 交换机还会将 BizTalk 进程的最大专用字节数从 800 MB 增加到 1800 MB。 有关启用了 /3GB 交换机 的 .NET Framework 应用程序性能的详细信息，请访问 第 17 章 - 优化 .NET 应用程序性能。

下表汇总了此信息，并包括虚拟字节和专用字节的实际限制。

过程 Windows操作系统 可寻址内存（具有大型地址感知进程） 虚拟字节的实际限制 专用字节的实际限制
32 位 32 位 2 GB 1400 MB 800 MB
32 位 32 位（启用/3GB 开关） 3 GB 2400 MB 1800 MB
32 位 64 位 4 GB 3400 MB 2800 MB
64 位 64 位 8 TB 不适用 不适用

有关 32 位与 64 位 Windows 的可寻址内存的详细信息，请访问 Windows 和 Windows Server 版本的内存限制。

下表列出了不同版本的 BizTalk Server 的 PAE 和 3 GB 可支持性。

产品 PAE 3 GB
BizTalk Server 2004 是 否
BizTalk Server 2006 是 是
BizTalk Server 2006 R2 是 是
BizTalk Server 2009 是 是

如果必须启用 /3GB 开关 以满足运行 BizTalk Server 的计算机的性能要求，可能需要考虑将服务器添加到 BizTalk 组。 这样，便可以横向扩展内存密集型主机实例。

启用 /3GB 交换机 时，在 Internet Information Services （IIS） 进程中运行的 BizTalk 组件也可能受益。

运行 Windows SharePoint Services 2.0 或更高版本或 SharePoint Portal Server 2003 SP2 或更高版本的计算机上不支持 /3GB 开关 。 Windows SharePoint Services 2.0 或更高版本或 SharePoint Portal Server 2003 Service Pack 2 或更高版本中不支持 Windows Server 2003 /3GB 开关 。

使用自定义组件

如果使用自定义组件（如管道或服务组件），则必须知道这些组件执行的操作。 还应知道这些组件对内存使用情况的潜在影响。 组件正在转换文档时，会出现常见的内存问题。 转换操作是内存密集型操作。 转换文档后，BizTalk Server 会将消息流传递到 BizTalk 进程中的 Microsoft .NET Framework XslTransform 类。

当存在密集的字符串操作时，会出现另一个常见问题。 密集的字符串操作可能会消耗大量记忆。 有关提高性能的方法的详细信息，请访问 改进托管代码性能。

.NET Framework 的版本

Microsoft .NET Framework 2.0 和 .NET Framework 1.1 具有不同的内存行为。 因此，你可能会看到它们之间的不同结果。 如果使用 .NET Framework，请确认已安装最新的 .NET Framework Service Pack 1。 此 Service Pack 可解决多个已知内存问题。

处理器数目

公共语言运行时（CLR）支持以下垃圾回收器（GCs）：

  • 工作站（Mscorwks.dll）
  • 服务器 （Mscorsvr.dll）

如果运行 BizTalk Server 的计算机是多处理器系统，则 .NET Framework 使用执行引擎的服务器版本。 这是默认行为。 服务器垃圾回收器旨在实现最大吞吐量。 此外，服务器垃圾回收器能够调整以提供高性能。 此垃圾回收器分配内存，然后释放内存，以在系统上提供高性能。 因此，运行 BizTalk Server 的计算机与一些 .NET Framework 组件似乎存在内存泄漏。 但是，在此方案中，高内存使用率是预期行为。 如果计算机耗尽系统内存，或者进程因可寻址内存不足而停止工作，则可能存在内存泄漏情况。

如果运行 BizTalk Server 的计算机是单个处理器系统，则 .NET Framework 使用执行引擎的工作站版本。 这是默认行为。 工作站垃圾回收器的分配算法并非为扩展性或最大吞吐量而设计。 此垃圾回收器使用并发垃圾回收方法。 这些方法专为具有复杂用户界面的应用程序而设计。 此类应用程序可能需要更积极的垃圾回收。

重要

此部分（或称方法或任务）介绍了修改注册表的步骤。 但是，如果错误地修改注册表，则可能会出现严重的问题。 因此，请确保仔细执行这些步骤。 作为额外保护措施，请在修改注册表之前先将其备份。 如果之后出现问题，您就可以还原注册表。 有关如何备份和还原注册表的详细信息，请参阅 如何在 Windows 中备份和还原注册表。

有时，可能需要在多处理器系统上运行执行引擎的工作站版本。 可以使用以下注册表项切换到执行引擎的工作站版本。

BizTalk 2006 及更高版本

使用相应的值创建以下 CRL Hosting 字符串注册表项：

  • 键：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc$BizTalkHostName\CLR Hosting
  • 值名称：风味
  • 值数据：wks

BizTalk 2004

使用相应的值创建以下 CRL Host 字符串注册表项：

  • 键：HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BTSSvc{GUID }\CLR Hosting
  • 值名称：风味
  • 值数据：wks

有关详细信息，请访问 .NET Framework 中 Run-Time 技术的性能注意事项。

以下是常见原因和解决方法：

进程和物理内存使用限制阈值

可以在 BizTalk Server 2006 和更高版本中更改进程内存使用情况和物理内存使用限制阈值。

  • 默认情况下， 进程内存使用率 限制阈值设置为 25。 如果超出此值并且 BizTalk 进程内存使用量超过 300 MB，则可能会发生限制情况。 在 32 位服务器上，可以将进程内存使用率值增加到 50。 在 64 位服务器上，可以将此值增加到 100。 这使得 BizTalk 进程在限制机制启动之前消耗更多的内存。

  • 物理内存使用限制阈值的默认值为 0。 此阈值度量系统内存总量。 因此，如果配置了 0 以外的值，在非 BizTalk 进程使用高内存时，可能会出现节流现象。

脱水节流阈值

当编排在 64 位主机上运行时，默认内存脱水阈值可能会导致内存过度脱水。 有关此问题的详细信息，请参阅 脱水默认属性。

注意

BizTalk Server 2006 及更高版本中支持 64 位主机。

在等效硬件的 32 位主机实例中，以默认内存脱水节流阈值运行相同的编排时，观察到的脱水程度不显著。

由于 64 位体系结构提供扩展的内存地址空间（16 TB 而不是 4 GB），因此 64 位主机实例的分配内存超过 32 位主机实例。 这可能会导致超出默认内存限制阈值。

若要解决此问题，请更改 BTSNTSvc64.exe.config 文件中的 VirtualMemoryThrottlingCriteria 和 PrivateMemoryThrottlingCriteria 值。 使用 \Process\Virtual Bytes 和 \Process\Private Bytes 性能监视器 计数器来确定业务流程实例分配的最大内存量。

  • 基于以下两个属性设置 OptimalUsage 值：

    • VirtualMemoryThrottlingCriteria：\Process\Virtual Bytes 值 + 10%
    • PrivateMemoryThrottlingCriteria：\Process\Private Bytes 值 + 10%

  • 将两个属性的MaximalUsage设置为OptimalUsage + 30%

例如，如果编排实例的 \Process\Virtual Byte Performance Monitor 计数器值为 5,784,787,695 字节（5,517 MB），则将 OptimalUsage 值设置为 6,069 MB，对于 VirtualMemoryThrottlingCriteria（5,784,787,695 * 1.10 = 6,363,266,464.5 字节）。

将 VirtualMemoryThrottlingCriteria 的 MaximalUsage 值设置为 7,889 MB（6,363,266,464.5 * 1.30 = 8,272,246,403.85 字节）。

如果 \Process\Private Bytes Performance Monitor 计数器值435689400字节（415 MB），请将 PrivateMemoryThrottlingCriteria 的 OptimalUsage 值设置为 457 MB（435689400 * 1.10 = 479258340 字节）。

将 PrivateMemoryThrottlingCriteria 的 MaximalUsage 值设置为 594 MB（479258340 * 1.30 = 623035842）。

对于此示例，将在 BTSNTSvc64.exe.config 文件中指定以下值以减少限制。

性能监控计数器 分配的内存 最佳使用 最大用量
\Process\Virtual Bytes 5,784,787,695 字节（5517 MB） 6069 7889
\进程\私有字节 435,689,400 字节（415 MB） 457 594

然后，这些值将在 BTSNTSvc64.exe.config 文件中表示，如下所示：

<xlangs>
    <Configuration>
       <Dehydration>
         <VirtualMemoryThrottlingCriteria OptimalUsage="6069" MaximalUsage="7889" IsActive="true" />
         <PrivateMemoryThrottlingCriteria OptimalUsage="457" MaximalUsage="594" IsActive="true" />
       </Dehydration>
    </Configuration>
</xlangs>

若要确定哪个主机实例正在运行业务流程编排，可以匹配 \BizTalk\Messaging\ID Process 和 \Process\ID Process 性能监视器计数器的 ID 进程。 然后，检查在对应 \Process\Virtual Bytes 和 \Process\Private Bytes 性能监视器计数器中显示的平均值。

注意

用户即使在浏览时也应注意的信息：在 SQL Server 2008 上运行 BizTalkMsgBoxDb 数据库时，高度脱水可能会导致性能显著下降。

BizTalk Server 服务包和累积更新

BizTalk Server 服务包和累积更新包括最新的修补程序。 其中包括影响已知 System.OutOfMemoryException 问题的那些问题。

HeapDeCommitFreeBlockThreshold (堆释放自由块阈值)

默认情况下， HeapDeCommitFreeBlockThreshold 注册表项值为 0。 值为 0 表示堆管理器将每 4 KB（KB） 页取消提交可用。 取消提交操作可能会导致虚拟内存碎片。 在堆管理器中，HeapDeCommitFreeBlockThreshold 设置的大小取决于系统正在执行的操作类型。 建议使用0x00040000大小的推荐起始值。

在更改注册表项的值 HeapDeCommitFreeBlockThreshold 之前，请考虑以下信息：

  • 此更改仅适用于内存碎片问题。
  • 此更改是系统范围的。 因此，大多数进程将在启动时使用更多内存。
  • 仅针对主要运行 BizTalk Server 的系统考虑此更改。

为了帮助减少虚拟内存碎片，可以通过更改以下注册表项的值HeapDeCommitFreeBlockThreshold来增加堆管理器中设置的大小HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager：

  • 值名称：HeapDeCommitFreeBlockThreshold
  • 值类型：REG_DWORD
  • 值数据：0x00040000（建议使用起始值）。
  • 默认值：不存在

转换操作

当 BizTalk Server 在接收端口、发送端口或 XLANG 三者中对相当大的消息执行 XML 转换操作时，XSL 转换会将整个消息加载到内存中。

若要解决此问题，请使用以下一种方法：

  • 减少 BizTalk Server 同时处理的消息数。
  • 减小正在转换的 XML 消息的大小。

该 System.Policy.Security.Evidence 对象经常用于转换，并且消耗大量内存。 当地图包含使用内联 C# 或任何其他内联语言的脚本 functoid 时，程序集在内存中创建。 该 System.Policy.Security.Evidence 对象使用实际调用程序集的对象。 这种情况会创建一个根对象，该对象在重新启动 BizTalk 服务之前不会删除。

大多数默认 BizTalk functoids 都作为内联脚本实现。 这些项可能会导致 System.Byte[] 对象在内存中收集。 为了最大程度地减少内存消耗，我们建议将使用这些functoids的任何映射放入一个较小的程序集。 然后，引用该程序集。 使用以下图表确定哪些 functoids 使用内联脚本，哪些 functoids 不使用内联脚本。

第二列中的 “是 ”表示这是 functoid 作为内联脚本实现的，并且将导致 System.Byte[] 对象在内存中收集。 否表示functoid不是作为内联脚本实现的，并且不会导致System.Byte[]对象在内存中收集。

Functoid 内联脚本？
所有字符串功能元 是
所有数学函数小工具 是
除 IsNil 之外的所有逻辑函数元 是
逻辑 IsNil 功能块 否
所有日期/时间功能块 是
所有转换功能构件 是
所有功能附加组件 是
所有累积功能块 是
所有数据库 Functoid 否
高级功能体 内联脚本？
“循环”Functoid 否
值映射展开函数体 否
断言功能元件 否
表提取程序 functoid 否
表循环函数小组件 否
使用内联 C# 编写 Functoid 脚本 是
使用内联 JScript.NET 编写 Functoid 脚本 是
使用内联 Visual Basic .NET 编写 Functoid 脚本 是
使用内联 XSLT 编写 Functoid 脚本 否
使用内联 XSLT 调用模板编写 Functoid 脚本 否
编写调用外部程序集的 Functoid 脚本 否
“空值”Functoid 否
值映射功能点 否
“批量复制”Functoid 否
“迭代”Functoid 否
索引Functoid 否
“记录计数”Functoid 否

BizTalk Server 2006 及更高版本显著改进了大型文档的内存管理。 为此，BizTalk Server 实现可配置的消息大小阈值，以便在转换操作期间将文档加载到内存中。 默认消息大小阈值为 1 MB。 有关 TransformThreshold 设置的详细信息，请访问 BizTalk Server 如何处理大型消息。

大型属性值和大型元素值

当 BizTalk Server 对 XML 文档执行接收管道或发送管道时，如果文档包含以下一个或多个实体，则会在内存中处理有效负载：

  • 大型属性值
  • 大型元素值
  • 大型属性或元素标记

若要解决此问题，请限制这些实体的大小。 如果此方法不可行，请确保 BizTalk HOST 实例不会同时处理多个文档，例如这些文档。

自定义管道组件

你正在使用将整个流加载到内存中的自定义管道组件。 BizTalk Server 中包含的所有组件（转换除外）都支持流式处理。 这些组件在流式处理期间使用的内存较少。 但是，自定义管道组件可能不支持流式处理。

在重压下进行流式传输

发送的主机在承受沉重压力时会耗尽内存。 BizTalk Server 发送管道并发送适配器支持流式传输。 在流式处理中，每个组件将流的小片段加载到内存中。 由于每个消息都包含其他数据结构，以及可能很大或较小的消息上下文，因此此行为会影响承受沉重压力的 BizTalk Server 的行为。

BizTalk Server 的行为受到影响，因为引擎加载了预配置的消息数。 引擎加载的消息数量基于 中 LowWaterMark 字段和 Adm_serviceClass 字段呈现的值。 该 Adm_serviceClass 表位于 BizTalk 管理数据库中。 这些值控制 BizTalk Server 处理或同时发送的消息数。

HighWaterMark 值是引擎同时处理的消息总数。 默认值为每个 CPU 200 条消息。 因此，在 8 处理器服务器上，发送主机将尝试同时处理 1,600 条消息（200 * 8）。

如果假定每条消息为 50 KB，则消息等于 80 MB（1,600 * 50=80,000 KB）。

若要解决此问题，可以更改数据库中 的 HighWaterMark 值和 LowWaterMark 值。 所使用的值取决于消息的大小。 对于 BizTalk Server 2006 及更高版本，可以更改默认主机限制设置。

尝试简化问题

如果已确定内存泄漏，请尝试通过删除自定义组件或简化地图来确定原因。 此外，尝试使用简单的编排或简单的解决方案来重现问题。 通常，应为接收适配器创建单独的接收主机。 还应为发送适配器创建单独的发送主机。 使用此方法时，每个适配器都可以在单独的进程中运行。 因此，如果 BizTalk Server 进程遇到内存不足的情况，你将知道涉及哪些组件。

疑难解答步骤

若要排查内存不足情况问题，请使用调试诊断工具监视一段时间内的内存分配。 调试诊断工具可以创建和分析内存泄漏转储文件（.dmp）。 排查内存泄漏问题时，目标是在高内存条件重现之前附加 Leaktrack.dll ，以捕获随时间推移的内存增长。 调试诊断工具包含Leaktrack.dll。

  1. 安装调试诊断工具。

    从 Microsoft 下载中心可以下载以下文件：
    立即下载调试诊断工具包

    有关如何下载Microsoft支持文件的详细信息，请参阅 如何从联机服务获取Microsoft支持文件。

    Microsoft 已对该文件进行病毒扫描。 Microsoft 使用的是文件发布时可以获得的最新病毒检测软件。 该文件存储在安全性得到增强的服务器上，以防止对文件进行未经授权的更改。

  2. 使用性能监视器收集有关系统性能的数据。 此数据可能会提供有关 BizTalk Server 环境效率的重要指示器。 目标是记录一段时间内的过程性能。 因此，在内存泄漏发生前启用性能监视器日志记录。

如何使用性能监视器日志记录

以下部分介绍如何使用性能监视器日志记录。

选择要记录的数据

若要选择要记录的数据，请使用适用于操作系统的方法：

  • 对于 Windows Server 2008 和 Windows Server 2008 R2

    1. 在管理工具中，打开 可靠性和性能监视器。

    2. 右键单击 性能监视器，单击“ 新建 ”，然后单击“ 数据收集器集”。

    3. 在 “名称 ”框中，键入描述性名称，然后单击“ 下一步”。

    4. 记下 根 目录，然后单击“ 下一步”。

    5. 单击“立即启动此数据收集器集”，然后单击“完成”。

    6. 展开 数据收集器集，展开 用户定义，然后选择你的文件。

    7. 右键单击 “系统监视器日志”，然后单击“ 属性”。

    8. 单击“性能计数器”选项卡上的“添加”。选择以下对象，然后在选择每个对象后单击“添加”：

      • .Net CLR 异常
      • .Net CLR 内存
      • BizTalk：消息传送
      • BizTalk：TDDS
      • 记忆
      • 过程
      • 处理器
      • XLANG/s 业务流程

      如果 SQL Server 是本地的，则还添加以下对象：

      • SQLServer：数据库
      • SQLServer：常规统计信息
      • SQLServer：内存管理器

    9. 单击“确定”。

    10. 将 “采样间隔”值 框更改为 5 秒。

      注意

      采样间隔值和开始监视的时间是主观的。 这些值取决于内存泄漏的重现时间。 由于日志文件可能很大，因此请指定一个间隔，在该间隔中可以获取必须具有的信息，而无需压倒服务器。

    11. 单击“确定”。

若要停止收集数据，请单击“作”菜单上的“停止”。

  • 对于 Windows Server 2003 或 Windows XP

    1. 展开 性能日志和警报。

    2. 右键单击“ 计数器日志”，然后单击“ 新建日志设置”。 此时会显示“ 新建日志设置” 对话框。

    3. 在 “名称 ”框中，键入描述性名称，然后单击“ 确定”。

    4. 记下日志文件位置。 （也可以单击“ 日志文件 ”选项卡，然后单击“ 配置 ”以更改日志文件位置。

    5. 单击“ 添加计数器”。

    6. 选择 “所有计数器 ”和 “所有实例”。

    7. 在 “性能对象 ”列表中，选择以下对象。 选择每个对象后，单击“ 添加 ”。

      • .Net CLR 异常
      • .Net CLR 内存
      • BizTalk：消息传送
      • BizTalk：TDDS
      • 记忆
      • 过程
      • 处理器
      • XLANG/s 业务流程

      如果 SQL Server 是本地的，则还添加以下对象：

      • SQLServer：数据库
      • SQLServer：常规统计信息
      • SQLServer：内存管理器

    8. 单击“关闭” 。

    9. 将数据 采样间隔 中的值更改为 5 秒。

      注意

      数据采样间隔值和开始监视的时间是主观的。 这些值取决于内存泄漏的重现时间。 由于日志文件可能很大，因此请指定一个间隔，在该间隔中可以获取必须具有的信息，而无需压倒服务器。

    10. 单击“确定”。 若要停止收集数据，请右键单击计数器日志的名称，然后单击“ 停止”。

获取转储文件

若要获取转储文件，请使用以下方法之一：

方法 1：自动

使用 DebugDiag 创建内存和句柄泄漏规则是获取内存转储的推荐方法。 内存和句柄泄漏规则会自动附加 Leaktrack.dll。 这用于跟踪内存分配。 若要创建内存和处理泄漏规则，请执行以下步骤：

  1. 启动调试诊断工具 1.1。

  2. 选择 “内存”和“处理泄漏”，然后单击“ 下一步”。

  3. 选择 Btsntsvc.exe 进程，然后单击“ 下一步”。

  4. 在 “配置泄漏规则 ”页上，执行以下步骤：

    1. 单击以选中规则激活时立即开始内存跟踪复选框。 否则，可以在 BTSNTSvc.exe 过程中注入 LeakTrack.dll 之前指定预热时间。

    2. 单击“ 配置”，然后执行以下作：

      • 确认已选择 “自动创建崩溃规则 ”。 选择此选项后，如果BTSNTSvc.exe进程停止，将自动创建内存转储。

      • 单击选中“当虚拟字节达到时生成用户转储”复选框，并保留默认值为1024。

      • 单击以选中 及每个附加 复选框，并保持默认值为 200。 通过选择虚拟字节访问选项，当虚拟字节使用 1024 MB 时，将自动创建内存转储。 如果虚拟字节增加 200 MB，将自动创建另一个内存转储。

    3. 单击“保存并关闭”。

    4. 单击“ 下一步”。

    5. 在 “选择转储位置和规则名称 ”页上，单击“ 下一步”。

      注意

      还可以在此页上的 “用户转储位置” 框中更改转储文件的路径。

    6. 单击“完成”使规则立即处于活动状态。

      注意

      规则状态现在为 “跟踪”。 每次创建内存转储时，“规则”选项卡上的“用户转储计数”列中的值都会增加。默认内存转储位置为 C:\Program Files\DebugDiag\Logs。

方法 2：手动

还可以手动附加Leaktrack.dll并手动获取内存转储文件。 这使你可以控制何时创建内存转储。 为此，请按照下列步骤进行操作：

  1. 启动调试诊断工具 1.1。
  2. 单击“ 进程 ”选项卡。
  3. 右键单击 Btsntsvc.exe 进程，然后单击“ 监视泄漏”。
  4. 在 “调试诊断工具 ”对话框中，单击“ 是”，然后单击“ 确定”。

创建崩溃规则以监视相同的Btsntsvc.exe进程，以防进程停止，然后才能创建内存转储：

  1. 启动调试诊断工具 1.1。
  2. 选择 “崩溃”，然后单击“ 下一步”。
  3. 选择特定进程，然后单击“ 下一步”。
  4. 选择相同的 Btsntsvc.exe 进程，然后单击“ 下一步”。
  5. 在 “高级配置”页上 ，单击“ 下一步”。
  6. 在 “选择转储位置和规则名称（可选） ”对话框中，单击“ 下一步”。
  7. 选择“立即激活规则”，然后单击“完成”。

当进程达到 60% 到 80% 的 RAM 时，右键单击 Btsntsvc.exe 进程，然后单击“ 创建完整用户dump”。 如果 BizTalk 进程在创建用户转储之前停止，崩溃规则应生效并创建内存转储。

停止性能监视器日志记录

如果要捕获内存转储和性能监视器数据，请在创建内存转储大约两分钟后停止性能监视器的日志记录。

分析转储文件

为了帮助确定内存泄漏的原因，可以使用调试诊断工具来分析转储文件。 为此，请按照下列步骤进行操作：

  1. 单击“ 高级分析 ”选项卡。
  2. 单击“ 添加数据文件”，然后找到.dmp文件。
  3. 选择 “内存压力分析 ”脚本，然后单击“ 开始分析”。

默认情况下，分析报告文件（.mht 文件）将在分析完成后在 C:\Program Files\DebugDiag\Reports 文件夹中创建。 报表文件也会显示在浏览器中。 报告文件包含分析的结果。 此外，报告文件可能包含有关如何解决内存泄漏的建议。

如果使用自定义 DLL，可以添加自定义 .pdb 文件的符号路径进行分析。 为此，请按照下列步骤进行操作：

  1. 打开调试诊断工具。
  2. 在 “工具” 菜单上，单击“ 选项”和“设置”。
  3. 在“ 用于调试的符号搜索路径 ”框中，键入符号路径。

如果想要有关分析转储文件的帮助，请联系Microsoft客户支持服务。 有关客户支持服务电话号码的完整列表以及有关支持成本的信息，请访问 “联系支持人员”。

联系客户支持服务之前，请压缩转储文件、性能监视器日志、分析报告文件和更新的事件日志（.evt 文件）。 可能需要将这些文件发送到 BizTalk Server 支持工程师。