问题标签 [windows-performance-analyzer]

我尝试使用显示的基本事件来记录事件以进行调试和分析。但是我有一个问题：当我注册我的提供者进行录制时，一切都很好，当在 WPA 中打开 .etl 文件时，我可以查看尽可能多的信息。但是，如果我在未注册提供者的情况下收集事件，当我在 WPA 中打开 .etl 文件时，一切都不是人性化的。那么，我必须在开始收集事件之前注册我的提供商吗？我希望不会，因为如果是这样，我必须冒险泄露我的 .man 文件，所以其他人也可以使用它来获取详细的跟踪日志。这是不可接受的！

我不希望我的 .man 文件打包在安装文件中，所以我不必担心泄漏它。当然我也不能注册我的提供商。

有没有办法尽可能好地查看 .etl（在没有我的提供商先注册的情况下收集）？

提前致谢。

下面的图片可能会使我所说的更容易理解。

未注册我的提供者的记录图像：

我的提供商注册的记录图像：

我正在捕获 ADO.Net 诊断 ETW，如SQL Server 2008 中的数据访问跟踪中所述。设置有效，生成了一个 ETL 文件，如果我使用tracerpt，我可以看到 ADO.Net 跟踪：

但是，如果我将相同的 ETL 加载到WPA中，我发现捕获的事件没有任何用处。来自此提供程序的所有事件都显示Event Name <Unknown>，Event Type Classic并且没有关于实际 ADO.Net 事件信息的信息（即 tracerpt CSV 输出中最右边的列）：

由于我捕获的所有其他数据都可以在 WPA 中进行分析，所以我想知道 ADO.Net 诊断提供程序有什么不同，即事件对 WPA 如此不透明？

我正在尝试使用 Windows 性能分析器来解决 WPF C# 应用程序中的一些性能问题。该应用程序是使用 .Net Framework 4.6.2 构建的。我让客户使用 UIForETW 来记录痕迹。

问题是，当我在 WPA 中加载符号时，我得到了所有 Microsoft 符号，但没有从我的应用程序中获取任何符号。在 WPA 的 Thread Stack 或 New Thread Stack 窗口中，我看到一个 ?!? 而不是我认为的！从我的应用程序。有趣的是，我没有看到后面跟着的 DLL 名称或类似的东西。只有 ？！？

我确实有一个符号服务器设置，并且我可以确认客户运行的版本具有存储在符号服务器中的符号。我在 WPA 中加载符号时没有收到任何错误，并且我可以看到我的应用程序和 DLL 的符号存在于本地符号目录和 WPA 符号缓存中。

似乎一切都是正确的，但符号没有出现。有人对为什么有任何想法吗？

谢谢！

操作系统：Windows Server 2012 R2（也尝试过 Windows 10）

WPRUI/WPA 版本：10.0.16299.91

Visual Studio Community 2017 版本：15.6.6

.NET 版本：4.7

对于我认为非常简单的场景，我无法在 WPA 中加载符号。

1. C# 控制台应用程序（称为 TestEtw - 二进制文件是 TestEtw.exe）
2. ETL 文件
3. NGENPDB 文件（由 WPRUI 输出）
4. testetw 的 Symcache 文件 ( TestEtw.exe-f5dfdbac20df4e29879d1c9abbd2cda61v2.symcache )
5. _NT_SYMBOL_PATH=c:\MySyms;srv*C:\Symbols*http://msdl.microsoft.com/download/symbols
   1. PDB 在项目的 bin 目录中，我在其中复制了一份c:\MySyms
6. 在 WPA 中加载 ETL 文件并单击加载符号。您会发现 wpa 不会为 TestEtw.exe（前面提到的 C# 控制台应用程序）加载符号

我尝试了很多事情：

1. 验证 symchk 可以通过运行找到符号： symchk c:\Users\Administrator\source\repos\TestEtw\TestEtw\bin\Debug\TestEtw.exe /v
   1. 它在 c:\MySyms\TestEtw.pdb 中找到符号
2. 已验证c:\symcache实际包含一个 testetw 文件，并且其名称与 PDB 签名匹配： TestEtw.exe-f5dfdbac20df4e29879d1c9abbd2cda61v2.symcache
3. 旧版本的 WPA（6.3.9600.16384 - 这是 winblue_rtm 版本）也不会加载这些符号
4. 通过 Process Monitor 确认 WPA 确实为 TestEtw 打开了 symcache 文件。

因此，似乎 symcheck 可以找到 pdb，wpa 正在填充 symcache 甚至加载 symcache 文件，但 WPA UI 没有在 TestEtw 中显示符号。

任何帮助将不胜感激。谢谢！

我有一个应用程序，我想使用 Windows 性能分析器对其进行分析。一切正常，但我没有从我的应用程序中获得任何合理的堆栈跟踪。

有问题的应用程序是一个演示应用程序。如果所有检查都结束，这是为了给我一个很好的感觉。然后我想分析另一个应用程序。因为我可以完全控制我的演示应用程序，所以我包含了一些标记函数，它们应该会显示在堆栈跟踪中。

在 Windwos 7 ¹上运行应用程序时，Process Explorer 会显示我想要分析的部件的正确堆栈跟踪。这是第 7 - 9 行中带有标记函数的堆栈跟踪：

由于我在 Windows 10 VM ²中安装了所有性能分析工具，因此我开始在那里进行分析。首先要注意：Process Explorer 没有显示正确的堆栈跟踪。我实现的标记功能无处可寻。

尽管如此，我还是使用UIforETW和Windows Performance Recorder记录了性能跟踪。在 WPA 中打开它们并专注于目标应用程序时，这是堆栈跟踪：

我感兴趣的所有信息都丢失了。堆栈显示为<Application>.exe!<Missing ImageId event>

我做错什么了？

如果这给你一个提示，这里是安装的相关软件：

1：Windows 7 计算机已安装 Visual Studio (C#)。

2：Windows 10 VM 没有 Visual Studio，但安装了 WinDBG（预览版）和 Windows Performance Toolkit。

我标记了delphi，因为目标应用程序是用 Delphi 编写的。

我正在使用 WPA 和 PerfView 来捕获跟踪以诊断 IIS 服务器挂起的原因。我们有理由相信，当时其中一张磁盘已满。

有没有办法在这些工具（WPA、PerfView）中查看磁盘有多满？

我们从该工具中获得了许多有用且详细的信息，但我找不到这个简单的指标。

谢谢！

我正在使用 xperf 记录大量跟踪，我只查看特定进程（当然，当不查看每个内核的 CPU 使用率等时）。现在这些痕迹变得非常大，使用它们很乏味。

有没有办法从 etl 中删除进程以减小其大小？由于我没有检查跨进程问题，因此我永远不会查看它们，如果可以处理一次 etl 以减小它们的大小，以便打开和比较它们变得更容易，那就太好了。

我有 ASP.NET 应用程序（框架 4.8），它偶尔会在几毫秒的时间内达到 100% 的 CPU 使用率。重要的是要知道，在这样的 CPU 负载期间或之前，应用程序不会遇到客户端 RPS 爆发。它实际上只是在 CPU 使用率激增之前服务于几个客户端请求。

查看带有 WPA 图表的 perfview 转储CPU Usage (Sampled)，我看到 CPU 峰值的顶部以及峰值的幻灯片都充满了 CPU 样本Dequeue和TrySteal方法。系统指标还显示，在 CPU 负载期间，应用程序经历了使用的工作线程 ( ThreadPool.GetAvailableThreads - ThreadPool.GetMinThreads) 的爆发，我设置为ThreadPool.SetMinThreads. 机器有 16 个核心，所以我测试了应用程序，每个核心的值为 2048 和 512 个工人：每个核心分别有 128 和 32 个工人。

就目前而言，看起来 CPU 负载是由大量工作线程引起的，试图在没有可用的情况下接收任何工作请求。因此工作人员浪费 CPU 试图在他们的本地队列、全局线程池队列中查找工作请求，并试图从其他线程的本地队列中窃取工作。

什么可能导致工作线程数量激增？16 个 CPU 内核真的会因为 512 名工人试图找工作而饿死，还是只是其他任何问题的结果？

附件说明

1) CPU 样本在所有应用线程堆栈中的分布

2) CPU 样本在单个随机应用程序线程堆栈中的分布

我用 WPA 打开 .etl（由 xperf 生成）文件，我可以看到有关 Analysis 的信息：

我也想看看进程堆栈，我想我应该先加载符号。但是 Trace 中的 Load Symbols 是灰色的：

我想问一下如何加载符号来查看进程堆栈？

WPA 版本：10.0.19041.685(WinBuild.160101.0800)

操作系统版本：Windows Server 2019 数据中心

操作系统版本：17763.1637

Windows 中的哪些性能计数器可以帮助我检测发生内存碎片的情况？我的系统在高虚拟内存条件下运行。因此，我想评估它是否实际上缺少它所请求的内存，或者由于新分配失败而导致可用内存碎片化。