What's the "System" process doing?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi

Is there any way to see what the System process is doing?

We have developed an application running at a production site to measure and
optimize the production. The application needs to be responsive at all times
during production.

I'm experiencing some problems with my application not responding or
responding slow. I suspeced the problem had to do with high CPU utilization
so I started logging the Processor Time for all running processes using
perfmon.exe

My process is running quite steady at about 50 - 70 %. However a process
called "System" is occationally using the CPU up to 90 % and this causes
problems in my application. Also a svchost process is running.

The system is a P3 3,0 GHz with 1 GB RAM and a 80 GB HDD running Win XP pro.

Is there any way I can get more specific information on what's happening and
What the System and svchost processes are doing? I understand the svchost
process is running services on the system and I would be interested in
knowing what service it's running and when to know if I could disable that
service?

Any tips on this would be apprechiated

Thank you
 
this may be a spam or virus. check for it. some times asp worker
process causes this problem potentially SQL Server trying to retrieve
huge data...
 
Thank for your answer but this system is a stand alone computer in a
production enviroment whitout internet connection or SQL server connections
and my WinForm application is the only application installed and running on
the computer...
 
The "System" process is your Operating System.

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

Orange you bland I stopped splaying bananas?
 
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/Utilities/ProcessExplorer.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/subscriptions/managednewsgroups/default.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/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Additionally, if you are curious with kernel achitecture and kernel
debugging, <Windows Internals> written by Mark Russinovich.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.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/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Hello, Henrik,

Re: "
The application needs to be responsive at all times
during production.
Click to expand...

It's probably a little late to mention it to your development team, but
Windows is NOT a real-time operating system. If responsiveness is a
critical requirement then you will have to re-build your application on
a more appropriate base.

Cheers,
Randy
 
Thank you for your reply

This is what I was looking for. I suspected the System process was the host
for other things going on but I need to know what's going on.

I hope to find that the things that are happening are not critical to my
application and maybe by ininstalling some driver or turning of some services
I can get rid of the high CPU load.

I will try the Process Exporer

Thank you

"Jeffrey Tan[MSFT]" said:
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/Utilities/ProcessExplorer.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/subscriptions/managednewsgroups/default.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/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Click to expand...
 
Hi Henrik,

Glad to see my reply can help you.

Note: setting up the symbol server for the Process Explorer is a critical
step of getting meaningful call stack for threads. Also, you'd better
change the dbghelp.dll path from C:\windows\system32 to windbg installation
folder, this is because windbg will take a dbghelp.dll which is higher
version than the one in system32 folder. You can change the dbghelp.dll
path in "Options" ->"Configure Symbols..." menu in Process Explorer.

Finally, kernel-debugging and analysis requires a lot of kernel-mode
achitecture knowledge. Besides <Windows Internals> book, some more specific
kernel-debugging questions can be posted to http://www.osronline.com/,
there are a lot of kernel/driver experts in that site.

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/subscriptions/managednewsgroups/default.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/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top