Continued 100% proc util from svchost.exe

K

kmcdowell

I continue to have a problem with one of my svchost.exe
processes running at 100% processor utilization, its
the "netsvcs" process. No virii that I can find, no
scvhost.exe file with the swapped c/v, no useful data that
I can find using tlist tool.

I have run "tlist <PID>" and get a list of threads active
in the process, but no way to devine which thread(s) are
the culprit, or how to end the rogue process. I compared
the dll files in the tlist output to another computer, and
found a group that are different, but none of them appear
to be third-party. Unplugging my LAN card does not fix it.

Someone suggested that I dump the svchost.exe file. How is
that done? Any other suggestions? This can't be rocket
science, can it? Paging a rocket scientist...

kmcdowell
 
J

Jason Hall [MSFT]

--------------------
Content-Class: urn:content-classes:message
From: "kmcdowell" <[email protected]>
Sender: "kmcdowell" <[email protected]>
Subject: Continued 100% proc util from svchost.exe
Date: Fri, 30 Apr 2004 11:04:31 -0700

I continue to have a problem with one of my svchost.exe
processes running at 100% processor utilization, its
the "netsvcs" process. No virii that I can find, no
scvhost.exe file with the swapped c/v, no useful data that
I can find using tlist tool.

I have run "tlist <PID>" and get a list of threads active
in the process, but no way to devine which thread(s) are
the culprit, or how to end the rogue process. I compared
the dll files in the tlist output to another computer, and
found a group that are different, but none of them appear
to be third-party. Unplugging my LAN card does not fix it.

Someone suggested that I dump the svchost.exe file. How is
that done? Any other suggestions? This can't be rocket
science, can it? Paging a rocket scientist...

kmcdowell
----------------------

Troubleshooting high CPU in a host process (services.exe, svchost.exe,
etc.) is done as follows:
1) In Performance Monitor, load the Thread object and select the "%
Processor Time", for instances, select all the the threads from the problem
host process
2) When you have noted the thread(s) that you would like to examine, add
the "Start Address" counter, choose the instance(s) as needed
3) Use calc.exe to convert the displayed start address from decimal to HEX
4) Run Pstat.exe
(http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/pstat-o
.asp)
5) At the bottom of the output, you will see the start address of all the
loaded modules:

ModuleName Load Addr Code Data Paged LinkDate
----------------------------------------------------------------------------
--
ntoskrnl.exe 80400000 450752 99840 739584 Tue Jun 10 17:42:11 2003

And bingo, there you will find culprit.
Cheers,

--
~~ JASON HALL ~~
~ Performance Support Specialist,
~ Microsoft Enterprise Platforms Support
~ This posting is provided "AS IS" with no warranties, and confers no
rights.
~ Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
~ Note: For the benefit of the community-at-large, all responses to this
message are best directed to the newsgroup/thread from which they
originated.
 
K

kmcdowell

-----Original Message-----
--------------------
----------------------

Troubleshooting high CPU in a host process (services.exe, svchost.exe,
etc.) is done as follows:
1) In Performance Monitor, load the Thread object and select the "%
Processor Time", for instances, select all the the threads from the problem
host process
2) When you have noted the thread(s) that you would like to examine, add
the "Start Address" counter, choose the instance(s) as needed
3) Use calc.exe to convert the displayed start address from decimal to HEX
4) Run Pstat.exe
(http://www.microsoft.com/windows2000/techinfo/reskit/tools
/existing/pstat-o
.asp)
5) At the bottom of the output, you will see the start address of all the
loaded modules:

ModuleName Load Addr Code Data Paged LinkDate
------------------
--
ntoskrnl.exe 80400000 450752 99840 739584 Tue Jun 10 17:42:11 2003

And bingo, there you will find culprit.
Cheers,


Thank you Jason,

Cool, I am right with you up to step 5. The hex number
does not show up in the list at the bottom. The hex column
there is headed "load address" and the hex number for the
process was in the middle of the output listed in a column
called "start address", in a section for the pid. The Hex
number was also in a lot of other pid sections, too. Here
it is, you can see the culprit:

pid:230 pri: 8 Hnd: 491 Pf: 3245 Ws: 10136K svchost.exe
tid pri Ctx Swtch StrtAddr User Time Kernel Time
State
22c 8 110 7C581AB4 0:00:00.010 0:00:00.020
Wait:Executive
23c 8 50 7C574333 0:00:00.010 0:00:00.010
Wait:UserRequest
30c 10 517 7C574333 0:00:00.020 0:00:00.030
Wait:UserRequest
370 10 131 7C574333 0:00:00.000 0:00:00.030
Wait:UserRequest
390 8 183 7C574333 0:00:00.000 0:00:00.000
Wait:DelayExecution
3a0 9 23 7C574333 0:00:00.010 0:00:00.020
Wait:UserRequest
3a4 8 3 7C574333 0:00:00.000 0:00:00.000
Wait:UserRequest
dc 8 123 7C574333 0:00:00.000 0:00:00.000
Wait:UserRequest
460 8 29 7C574333 0:00:00.000 0:00:00.010
Wait:UserRequest
464 9 177 7C574333 0:00:00.000 0:00:00.000
Wait:UserRequest
468 9 523 7C574333 0:00:00.030 0:00:00.020
Wait:EventPairLow
470 8 399 7C574333 0:00:00.030 0:00:00.060
Wait:EventPairLow
474 9 18 7C574333 0:00:00.000 0:00:00.000
Wait:UserRequest
478 10 169 7C574333 0:00:00.000 0:00:00.000
Wait:UserRequest
480 9 5 7C574333 0:00:00.000 0:00:00.000
Wait:UserRequest
484 10 51 7C574333 0:00:00.000 0:00:00.010
Wait:UserRequest
494 8 9 7C574333 0:00:00.000 0:00:00.000
Wait:EventPairLow
498 9 3 7C574333 0:00:00.000 0:00:00.000
Wait:EventPairLow
49c 9 3 7C574333 0:00:00.000 0:00:00.000
Wait:UserRequest
404 8 483 7C574333 0:00:00.000 0:00:00.120
Wait:UserRequest
228 8 3 7C574333 0:00:00.000 0:00:00.000
Wait:UserRequest
4b0 8 775643 7C574333 0:18:32.980 1:00:54.945 Ready
4b4 9 3 7C574333 0:00:00.000 0:00:00.000
Wait:UserRequest
4c4 15 2 7C574333 0:00:00.000 0:00:00.000
Wait:UserRequest
4d8 8 3 7C574333 0:00:00.000 0:00:00.000
Wait:UserRequest
4dc 9 12 7C574333 0:00:00.000 0:00:00.000
Wait:UserRequest
4a8 9 38 7C574333 0:00:00.000 0:00:00.020
Wait:UserRequest
540 9 1117 7C574333 0:00:00.050 0:00:00.030
Wait:LpcReceive
59c 8 54 7C574333 0:00:00.000 0:00:00.010
Wait:LpcReceive
608 8 56 7C574333 0:00:00.000 0:00:00.000
Wait:LpcReceive
 
J

Jason Hall [MSFT]

--------------------
Content-Class: urn:content-classes:message
From: "kmcdowell" <[email protected]>
Subject: RE: Continued 100% proc util from svchost.exe
Date: Fri, 30 Apr 2004 14:19:31 -0700

Thank you Jason,

Cool, I am right with you up to step 5. The hex number
does not show up in the list at the bottom. The hex column
there is headed "load address" and the hex number for the
process was in the middle of the output listed in a column
called "start address", in a section for the pid. The Hex
number was also in a lot of other pid sections, too. Here
it is, you can see the culprit:

pid:230 pri: 8 Hnd: 491 Pf: 3245 Ws: 10136K svchost.exe
tid pri Ctx Swtch StrtAddr User Time Kernel Time
State
22c 8 110 7C581AB4 0:00:00.010 0:00:00.020
Wait:Executive
23c 8 50 7C574333 0:00:00.010 0:00:00.010
Wait:UserRequest
30c 10 517 7C574333 0:00:00.020 0:00:00.030
Wait:UserRequest
370 10 131 7C574333 0:00:00.000 0:00:00.030
Wait:UserRequest
390 8 183 7C574333 0:00:00.000 0:00:00.000
Wait:DelayExecution
3a0 9 23 7C574333 0:00:00.010 0:00:00.020
Wait:UserRequest
3a4 8 3 7C574333 0:00:00.000 0:00:00.000
Wait:UserRequest
dc 8 123 7C574333 0:00:00.000 0:00:00.000
Wait:UserRequest
460 8 29 7C574333 0:00:00.000 0:00:00.010
Wait:UserRequest
464 9 177 7C574333 0:00:00.000 0:00:00.000
Wait:UserRequest
468 9 523 7C574333 0:00:00.030 0:00:00.020
Wait:EventPairLow
470 8 399 7C574333 0:00:00.030 0:00:00.060
Wait:EventPairLow
474 9 18 7C574333 0:00:00.000 0:00:00.000
Wait:UserRequest
478 10 169 7C574333 0:00:00.000 0:00:00.000
Wait:UserRequest
480 9 5 7C574333 0:00:00.000 0:00:00.000
Wait:UserRequest
484 10 51 7C574333 0:00:00.000 0:00:00.010
Wait:UserRequest
494 8 9 7C574333 0:00:00.000 0:00:00.000
Wait:EventPairLow
498 9 3 7C574333 0:00:00.000 0:00:00.000
Wait:EventPairLow
49c 9 3 7C574333 0:00:00.000 0:00:00.000
Wait:UserRequest
404 8 483 7C574333 0:00:00.000 0:00:00.120
Wait:UserRequest
228 8 3 7C574333 0:00:00.000 0:00:00.000
Wait:UserRequest
4b0 8 775643 7C574333 0:18:32.980 1:00:54.945 Ready
4b4 9 3 7C574333 0:00:00.000 0:00:00.000
Wait:UserRequest
4c4 15 2 7C574333 0:00:00.000 0:00:00.000
Wait:UserRequest
4d8 8 3 7C574333 0:00:00.000 0:00:00.000
Wait:UserRequest
4dc 9 12 7C574333 0:00:00.000 0:00:00.000
Wait:UserRequest
4a8 9 38 7C574333 0:00:00.000 0:00:00.020
Wait:UserRequest
540 9 1117 7C574333 0:00:00.050 0:00:00.030
Wait:LpcReceive
59c 8 54 7C574333 0:00:00.000 0:00:00.010
Wait:LpcReceive
608 8 56 7C574333 0:00:00.000 0:00:00.000
Wait:LpcReceive
-----------------------

It looks like the most CPU time is in this thread:
4b0 8 775643 7C574333 0:18:32.980 1:00:54.945 Ready
....now, are you saying that 7C574333 is not listed at all in the PSTAT?


--
~~ JASON HALL ~~
~ Performance Support Specialist,
~ Microsoft Enterprise Platforms Support
~ This posting is provided "AS IS" with no warranties, and confers no
rights.
~ Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
~ Note: For the benefit of the community-at-large, all responses to this
message are best directed to the newsgroup/thread from which they
originated.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top