Hi Henrik,
System Process is just the placeholder of all the kernel-mode system
threads, such as threads created by various drivers or other kernel-mode
components. This process does not have user-mode code, and is not a normal
user-mode process.
In Windows NT achitecture, all the user-mode processes will have their own
user-mode 2GB process space, while all the processes will share the upper
2GB kernel-mode process space. The code that runs in kernel-mode space is
running under kernel-mode threads. However, kernel-mode threads do not
belong to any user-mode process, so, to collect and contain the
kernel-mode threads performance data, a system process is introduced to
hold all the kernel-mode threads.
Above is the background information. Let's back to your question.
Are you sure that it is your .Net winform application that caused System
Process to use high CPU? If you do not run the .Net winform, do you still
have such high CPU? It is likely the System Process high CPU is caused by
other processes or code. Another way to figure out the relation between
your winform application and the System Process is running your winform
application on other machines and exam the System process CPU utilization.
Additionally, some anti-virus software or spyware may cause such strange
issue as dogu pointed out. It is recommended to turn-off any anti-virus
softwares.
Finally, the best tools to examine the System process information are
kernel-mode debugger and Process Explorer. I highly recommend you download
and try "Process Explorer", it is almost a definite superset of Task
Manager:
http://www.sysinternals.com/Utilitie...sExplorer.html
By using "Process Explorer", you can find System Process, and view its
property through right click ContextMenu. In the "Threads" tabpage, it will
list all the threads in this process, in our scenario, they are all
kernel-mode threads created from kernel mode components/drivers. You can
also view the call stack information of each thread, which is the most
informative way of understanding what the thread is current doing. However,
kernel-mode achitecture information is needed to understand these kernel
call stack.
Note: you must setup the symbol server correct, or the call stack
information will not be correct. For more information, please refer to
windbg help document.
Kernel debugging is another approach to examine system process, however, it
is far complex and goes beyond of our scope.
Hope this helps.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.