问题标签 [process-explorer]

我git clean -fdx在我的仓库中使用Git 2.8.2.windows.1. 我的理解是该-f标志应该强制移除。有时我 - 出乎意料地 - 得到这个链接问题（有一个解决方案）。

我的问题不是为什么会发生这种情况——我知道另一个进程可以处理 Git 试图操作的任何文件。

我的问题：当我查找git clean -fdx抱怨 using的路径时Process Explorer->Find，找不到句柄。怎么会这样？

可以使用哪些其他工具来确定哪个进程正在锁定？

在我们的应用程序中，我们以不同的方式（通过不同的库）编写多个日志文件。当刷新它的缓冲区时，其中一个文件会不时阻塞。当时的堆栈跟踪是：

我注意到在 Process Explorer（来自 Sysinternals Suites）中，阻塞文件总是有很多“引用”：

但是其他每个日志文件（总是很好）只有 1 个引用。

文件的“参考”是什么？是否有可能是文件在刷新时被阻止的原因？

我有一个可以帮助探索、生成和打开 Visual Studio 项目的应用程序。我正在使用 Activator 方法创建 Visual Studio 流程，如下所示：

它工作得很好，除了它创建的过程是隐藏的。如果我使用 Process Explorer 的“查找窗口的进程”功能，我会收到错误消息：

进程资源管理器错误

拥有进程是 devenv.exe（进程 ID 22196），当前在进程列表中不可见。

好的

有没有办法使用这种方法，但使过程可见？与手动打开它相比，它使使用生成的视觉工作室更加困难。

在 Windows 10 上使用空白 VCL 项目在 Delphi 中测试 ALSR。

在 VCL 项目文件中添加：

{$SETPEOPTFLAGS $140} //设置 ASLR 和 DEP

当“与运行时包链接”为假时，Process Explorer 将地址空间布局随机化列为“启用（永久）禁用”。当“与运行时包链接”为真时，Process Explorer 将地址空间布局随机化列为“自下而上”。

我将我的应用程序作为 32 位和 64 位以及 32 位和 64 位 Process Explorer 进行了测试。两个 Process Explorer 的答案相同。

“启用（永久）禁用”和“自下而上”之间有什么区别，为什么这会受到运行时包的影响？

当我运行 Sysinternal Process Explorer 时，我可以看到作弊引擎何时附加到另一个进程，而我无法使用 Handle.exe（同一公司命令行工具）做同样的事情。我已经尝试过 Handle.exe 的每个 32 位和 64 位版本。它不显示进程，它显示除进程之外的所有其他句柄。有人对这个问题有任何想法吗？我只需要查看一个进程是否像 Process Explorer 那样处理另一个进程。

我正在安装一个大型 C# 项目，有人告诉我首先将 nuget 从 3.3 升级到 3.4 或更高版本。

我下载了 nuget 扩展（VS 2015 VSIX v3.4.4）并尝试安装它，我得到了这个：

我尝试了另一种方式-从VS2015中，工具->扩展和更新，找到现有的nuget并尝试先将其卸载，我得到了：

我翻出“进程资源管理器”，发现两个进程使用了​​ nuget：chrome 和 devenv.exe。devenv 是一个带有 VS2015 实例的进程。无论如何，我退出了 VS2015，甚至退出了​​ chrome，没有帮助，与安装扩展时的错误消息相同。

我尝试过的其他事情：

我发现正在使用的 nuget 位于“C:\Program Files (x86)\NuGet”，我将现有的替换为新版本的 nuget.exe，以及 C:\Program Files (x86) 下的 nuget.tools \NuGet\Visual Studio 2015，然后我再次启动 VS 仍然得到相同的消息

我删除了项目下的 packages 文件夹以及 /.nuget 下的文件夹，但没有帮助。

我用谷歌搜索并找到了这个链接，但它也无助于解决问题。我承认我无计可施。

我正在努力诊断OutOfMemoryException我们的应用程序中的一系列问题。这是一个内部 32 位 (x86) OWIN 托管的 WebAPI，它在控制台应用程序中运行，并与一系列硬件组件并行通信。出于这个原因，它创建了大约 20 个库实例，并且在创建这些实例时，“虚拟大小”内存的急剧增加相匹配。

从 Process Explorer 和 dotMemory 的输出来看，我们似乎并未在此应用程序中分配那么多实际内存：

通过阅读许多 SO 答案，我想我明白我们的问题是来自 G0、G1、G2 和 LOH 堆中的碎片，或者我们可能遇到了在 Windows 上运行的 32 位进程的 2GB 可寻址内存限制7. 此应用程序分批工作，它从硬件设备收集一堆数据，在内存中创建集合以将这些数据聚合到单个对象中，然后将其保存以供客户端应用程序检索。此活动是 dotMemory 视觉效果出现峰值的原因，但这些数据结构并不庞大，我认为 dotMemory 图表显示了这一点。

查看堆显示它们的大小很少超过 10-15MB，而且我没有看到太多证据表明 LOH 变得太大或严重分散。我真的很挣扎如何继续更好地了解这里发生的事情。

所以我的问题有两个：

1. 是否可以想象我们可能会达到 2GB 的虚拟内存限制，而这是导致这些内存异常的原因？

2. 如果这是一个可能的原因，那么我认为 64 位构建可以解决这个问题是否正确？

我们正在探索转向 64 位构建，但这需要将我们使用的一些低级库更新为 64 位。这当然是我们最终会探索的一个选项（如果不是更早的话），但我们会在投入所需时间之前尝试更好地了解这种情况。

设置 LARGEADDRESSFLAG 后更新

根据建议，我在二进制文件上设置了该标志，有趣的是，虚拟大小立即跃升至近 3GB。我不知道我是否应该对此感到震惊？！

在接下来的几个小时内，我将使用此配置监视应用程序。

Process Explorer 非常好，但它没有显示 .net 核心进程的指标。是否有工具可以连接到任意 .net 核心进程并获取指标#GC 集合、GC 堆大小、GC 时间等。

Sysinternals 的 Process Explorer 显示进程持有的所有句柄，包括对象名称、类型、地址和句柄值等字段。例如：

ETW 的NT Kernel Logger跟踪会话具有用于句柄操作的事件，语法如下：

我的问题是：ETW 中的 ObjectType 是一个 16 位整数。如何将整型 ObjectType 值映射到对应的对象类型名称（如 Process Explorer 中所示）？

如果我使用 Process Explorer 在我的 64 位 Windows 10 系统上查看 32 位进程的调用堆栈，Process Explorer 只显示调用堆栈的 64 位（上）部分，而不是更有趣（下）的 32-位部分。例如，一个 32 位 wmplayer.exe 进程的主线程的调用堆栈显示：

而 64 位 wmplayer.exe 进程 (C:\Program Files\Windows Media Player\wmplayer.exe) 的调用堆栈是完整的，并且还包含应用程序代码中的调用：

如果我不得不猜测，我会说是第一个堆栈中的 0x0000000000000000 地址阻止了 Process Explorer 进一步深入 32 位部分，但我不能 100% 确定这一点。如何让 Process Explorer 显示 32 位进程的 32 位堆栈？

有关我的设置的更多信息：

更新：当使用 Process Hacker 而不是 Process Explorer 查看 32 位进程的调用堆栈时，会显示预期的 32 位堆栈。对于 32 位 wmplayer.exe 的主线程，Process Hacker 显示：

更新 2：问题仅在 64 位进程资源管理器 (procexp64.exe) 中表现出来。当强制 Process Explorer 以 32 位运行时，它会显示 32 位堆栈：

更新 3：与此同时，我已经能够确认在全新安装 Windows 10 x64 时会出现同样的问题。这排除了与我系统上现有驱动程序或软件的冲突，并且使这种理论成为 Process Explorer 中的错误的可能性越来越大。但是，似乎没有任何迹象表明这将很快得到解决。由于我确实需要能够查看 32 位调用堆栈并且 Process Hacker 仍然可以正确执行此操作，因此我没有其他选择，只能停止使用 Process Explorer 来支持 Process Hacker。