找出进程在 win32 内核中花费时间的原因
我正在 WinXp VmWare 会话中编译 vc8 C++ 项目。 在 RedHat VmWare 会话中，它比 gcc3.2 慢得多，所以我正在查看任务管理器。 这意味着我的编译过程的很大一部分都花在了内核上。 这对我来说听起来不对。
Win32 是否有等效的 strace ？ 至少能让我大致了解正在调用哪些内核函数。 可能有一些东西是罪魁祸首。
I'm compiling a vc8 C++ project in a WinXp VmWare session. It's a hell of a lot slower than gcc3.2 in a RedHat VmWare session, so I'm looking at Task Manager. It's saying a very large percentage of my compile process is spent in the kernel. That doesn't sounds right to me.
Is there an equivalent of strace for Win32? At least something which will give me an overview of which kernel functions are being called. There might be something that stands out as being the culprit.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Windows 资源工具包包含一个名为
kernrate的工具。 这是一个采样分析器。 它可以分析整个系统或特定过程。 默认情况下，其分辨率位于模块级别，但可以调整至几个字节。 您应该可以使用默认分辨率，因为您将看到哪些模块/驱动程序消耗了大部分时间。这里是有关其使用的一些信息。
Windows Resource Kit contains a tool called
kernrate. It's a sampling profiler. It can profile entire system or a particular process. By default, its resolution is on a module level, but can be tuned down to several bytes. You should be fine with default resolution as you'll see which modules/drivers are consuming most of the time.Here is some info regarding its use.
不完全是 strace，但有一种方法可以了解内核调用堆栈，并且通过在 CPU 使用率高时对其进行采样，您通常可以估计一直在使用的内容。
安装 Process Explorer 并确保为其配置符号服务器支持。 您可以通过以下方式执行此操作：
以下是符号路径的示例值：（
您可以将 _NT_SYMBOL_PATH 环境变量设置为相同的值，以使调试工具使用相同的符号服务器和缓存路径。）此路径将导致 dbghelp.dll 在被询问时将符号下载到本地磁盘对于本地没有符号的模块的符号。
像这样设置 Process Explorer 后，您可以获取进程的属性，转到线程选项卡，然后双击最繁忙的线程。 这将导致 Process Explorer 暂时挂接到进程并扫描线程的堆栈，然后查找堆栈上各个返回地址的符号。 返回地址的符号和模块名称（对于非 MS 第三方驱动程序）应该可以为您提供有关 CPU 时间花在哪里的有力线索。
Not exactly strace, but there is a way of getting visibility into the kernel call stack, and by sampling it at times of high CPU usage, you can usually estimate what's using up all the time.
Install Process Explorer and make sure you configure it with symbol server support. You can do this by:
Here's an example value for the symbol path:
(You can set _NT_SYMBOL_PATH environment variable to the same value to have the debugging tools use the same symbol server and cache path.) This path will cause dbghelp.dll to download symbols to local disk when asked for symbols for a module that doesn't have symbols locally.
After having set up Process Explorer like this, you can then get a process's properties, go to the threads tab, and double-click on the busiest thread. This will cause Process Explorer to temporarily hook into the process and scan the thread's stack, and then go and look up the symbols for the various return addresses on the stack. The return addresses's symbols, and the module names (for non-MS third-party drivers) should give you a strong clue as to where your CPU time is being spent.
VmWare 支持应该可以解决这个问题。 它可能位于 VmWare 实现中的某个位置。
例如，您可以使用 IrpTracker 来了解正在发生的情况内核。
另一种选择是使用内核调试器，即 WinDbg。 如果 cpu 负载非常高，只需随机中断调试器并查看调用堆栈即可让您了解谁是 cpu 负载背后的驱动程序。 但正如我所说，我猜测这将是一些 VmWare 组件。 值得检查问题是否在同一台计算机上运行 WinXP（无需仿真）时仍然存在。
VmWare support should be address that question. It's probably somewhere in the VmWare implementation.
You can use for example IrpTracker that give you an idea what is going on in the kernel.
Another option is using kernel debugger i.e WinDbg. If the cpu load very high just randomly breaking in the debugger and looking on the call stack can give you an idea who is the driver behind the cpu load. But as i stated i will guess that it will be some VmWare component. It worth to check if the problem persist on same computer on WinXP without emulation.