Find out why a process spends time in the kernel in win32
I am compiling a vc8 C ++ project in a WinXp VmWare session. It's a heck of a lot slower than gcc3.2 in a RedHat VmWare session, so I'm looking at the task manager. He says that a very large percentage of my compilation process is spent in the kernel. It doesn't seem right to me.
Is there a strace equivalent for Win32? At least that's what gives me an overview of what kernel functions are called. Maybe something that stands out as the culprit.
source to share
The Windows Resource Kit contains a tool called kernrate
. This is a sampling profiler. It can handle an entire system or a specific process. By default, its resolution is at the module level, but can be configured to multiple bytes. You should be fine with the default resolution as you will see which modules / drivers are consuming most of the time.
There is information on how to use it.
source to share
Not really hiding, but there is a way to get visibility in the kernel call stack, and by taking it during high CPU usage, you can usually estimate what to use all the time.
Install Process Explorer and make sure you've configured it with Symbol Server support. You can do it:
- Install WinDebug to get updated dbghelp.dll
- Install Process Explorer to use this version of dbghelp.dll by setting the path in Options | Customize the Symbols menu in the Process Explorer.
- Also in the same dialog, set the symbol path to include MS symbol server and local cache.
Here's a rough meaning for the symbol path:
SRV*C:\symbolcache*http://msdl.microsoft.com/download/symbols
(You can set the _NT_SYMBOL_PATH environment variables to the same value so that debugging tools use the same server symbol and cache path.) This path will lead to dbghelp.dll to load symbols to the local disk when requesting symbols for a module, has no local symbols ...
After setting up Process Explorer like this, you can get the properties of the process, go to the threads tab, and double click on the busiest thread. This will cause Process Explorer to temporarily attach to the process and view the thread's stack, then go and look for the symbols for the different return addresses on the stack. Return return addresses and module names (for third party third party drivers) should give you a clear idea of where your CPU time is being spent.
source to share
VmWare support should address this issue. This is probably somewhere in the VmWare implementation.
You can use IrpTracker , for example, which gives you an idea of what's going on in the kernel. Another option is to use the ie WinDbg kernel debugger . If the CPU load is very high, just randomly crashing in the debugger and looking at the call stack, you can imagine who the CPU load driver is. But as I said, I guess it will be some kind of VmWare component. It is worth checking if the problem persists on one machine on WinXP without emulation.
source to share