问题标签 [wpr]

收集堆快照时出现以下错误：

我仅在 Windows Server 2016 操作系统上收到此错误。尝试了 2 台不同的机器，但得到了相同的错误。我在 Windows 10 RS5 机器（具有相同的可执行文件）上尝试了这个并且它有效。有谁知道这个错误的原因？

谢谢。

我一直在试图理解为什么我们会在 Citrix - Windows 10 下获得 OOM，尽管它没有发生在“普通”机器上。我们的应用程序混合了原生 C++、C# 和 Web 浏览器插件。容器是.net。

详细信息：Windows 10 版本 18363 MP（2 个过程）免费 x86 兼容产品：WinNt，套件：SingleUserTS 18362.1.wow64fre.19h1_release.190318-1202

WinDbg 的异常

OOM 出现在 .Net 上，有时应用程序继续工作！其他时候，我在 taskmanager 上的内存使用量约为 700MB 时就遇到了异常，这真的很奇怪。

收到异常后，我设法在 taskmanager 上运行 PerfView 并强制执行 GC，将其从 > 750MB 降至 350MB。不知何故，我觉得 GC 在 Citrix 下没有按预期工作。

与开始相比，PerfView 实际上显示了非常少量的遗留对象。

Vmap 还在堆上显示了许多 ~75MB 块 - 我猜这是来自 .Net，但是“？！？” 打扰我。我的猜测是基于我在 PerfView 上强制执行 GC 并且这些块已经消失的事实。此外，我在 WPA 中看到的 WPF 块的线大小与此相同？！？堵塞。这不可能是巧合。

堆上几乎没有碎片：

我什至尝试使用 wpr 找出导致错误的原因，我可以看到 .net 上的 WPF 正在分配 ~75MB 块，这很奇怪？！？以及 - 我想这是 jitted 代码。我几乎有所有可用的符号，但仍然没有运气 - ？1？留在那里。也许 wpr 没有保存 .Net 信息 - 我需要尝试使用配置文件，但我无法一直访问计算机。

这是 WPA 的观点：

这是 Windbg 告诉我的关于内存的内容：

如您所见，.net 仅使用了大约 147MB 的部分，其余 200MB 我不确定。虚拟分配？我以为他们会进入堆部分。

保留的 200MB 也是一个大问题，我会试着找出它为什么会在那里。

dll 无法减少 - 我们都需要它们，特别是当用户同时打开许多插件时。

我想知道这是否是一个已知的 Citrix 问题。尽管我们仍然有 175 MB 可用空间，但我还能做些什么来检查为什么我们会得到这个 OOM？我想不出为什么我们的应用程序一次需要更多。我们没有显示大图片或视频。

我检查了 GDI/Handles/User 对象，一切似乎都还好。他们并不高。

我有但尚未尝试的一个想法是将 GC 设置更改为 Workstation - Concurrent 以查看会发生什么。不确定这是否会有所帮助。

这是堆栈：

和线程：

********** 编辑 ********** 所以，我搜索了位图：

我得到OOM的地方不一定是造成高内存使用的地方，但无论如何：

谢谢，马可

在数据库中，我们习惯于阅读等待时间分析，但 Microsoft Windows 提供了一个类似的工具（Windows Performance Recorder / Xperf）来了解我们系统的瓶颈是什么。

WPR 是一个复杂但非常有趣的工具，在监控构建时我发现了一些我没想到的东西：

• devenv.exe占用了大部分CPU 时间（为什么？我本来希望是 msbuild.exe）
• vbcscompiler.exe 也占用大量 CPU 时间（与之前的注释相同）
• devenv.exe 使用的大部分 CPU 时间似乎都在与消息队列处理相关的上下文切换 (?!?!?!?!) 中

我有带有 Resharper 2021.1.1 的 Visual Studio 2019 v16.9.2 有人可以帮我解释这种类似的行为吗？

我正在使用 wpr 工具来跟踪“电源”。由于 etl 文件非常大，我正在创建自定义 wpr 配置文件以过滤掉感兴趣的事件。

在 WPR 图表“电源”下，我们有某些图表，如 CPU 空闲状态、处理器实用程序、处理器性能、处理器频率等）

可以说我只需要一个图表“处理器频率”，我正在为它创建自定义配置文件。

谁能帮助如何仅为“处理器频率”图创建配置文件以及找到“处理器频率”图使用的事件的任何方法

我正在做一个以毫秒计的计时器，当毫秒到达终点时，它会停止脚本。为什么我不会重复代码直到完成它，因为 Windows 性能记录器正在幕后工作，而 wpr 正在与时间一起工作，我们必须手动停止 wpr。问题是我的计时器在远程启动时不会停止 WPR。计时器在本地工作得很好。

这里是下面的代码：

你有更好的方法来解决我的问题吗？

嗨，我想调试登录延迟，我可以看到 eventvwr 事件，如下所示，大约需要 50-60 秒才能完成。

无法确定哪个是订阅此事件的进程/exe，因此我可以专注于 wpr 跟踪中的特定进程活动。

如果我可以使用某些工具或 cokmmand 检查一些 cmd，哪些订阅者注册了 winlogon，这肯定会有所帮助