Posted By: GamlerHart | Jan 13th, 2008 @ 8:49 AM
page 1 of 1
Comments: 9 | Views: 1592

Hi

A service on my Windows Vista (SP1 RC) is regularly running mad. If it is using 50% of the Dual-Core-CPU and never stops. If it is doing this, I can't open the windows-taskmanager and some other applications. Somehow it is locked up. Even the UAC has problems to show up, if I launch the Sysinternals Process Explorer as admin-user.

With the Process Explorer I can see that on Thread of the "wevtsvc.dll" seems to do somehow a busy-wait on "ntkrnlpa.exe!KeWaitForMultipleObjects" =(.

Now I've no idea what I should do. Just re-install windows or troubleshoot further. My question is if you guy know a strategy for exploring such problems or know a excellent forum to ask?

thx gamlor

GoddersUK
GoddersUK
I CAN has cheezburger and you CAN'T has stop me!
Any idea what programme wevsvc.ddl is to do with?

Neither google nor live search turn up anything (except this thread) for that DLL.

But it's def worth trying to troubleshoot further before nuking your current install.

GoddersUK
GoddersUK
I CAN has cheezburger and you CAN'T has stop me!
Perhaps the event loggers logged the cause of it's own failure. I don't know whether it's the same in Vista, but in XP it can be accesed via administrative tools in control panel.

Look for the red xs, likely under Application or System.
RichardRudek
RichardRudek
So what do you expect for nothin'... :P
I'm pretty sure the event logger is an important service...

Anyway, to make troubleshooting easier, make sure you have Process Explorer setup with both symbols and the latest debugging engine.

You can download and install the latest [Debugging Tools], then configure ProcessExplorer to use it's debugging engine:




This gives you 'friendlier' stack traces. Notice the Names - Yes, I realise that you may already have the symbols setup, so this advise is not just for you...





Anyway, the item at the top of the stack trace is usually not the problem - it's simply the point at which ProcessExplorer was able to attach itself to the thread, and take a snapshot of the stack.

So you will typically need to trawl back down the stack trace to find the culprit of the CPU usage.

EDIT:

Note that when using the entry as shown in the image (SRV*c:\symbols*http://msdl.microsoft.com/download/symbols), you need to make sure the symbols cache folder (in this case c:\symbols) actually exists. You can change it to something else, if you like.

vesuvius
vesuvius
Das Glasperlenspiel
When did this problem begin? Was it before SPI or after? Remove SP1 and try the new SP1 refresh available as of Friday, or boot into safe mode and do a restore.
page 1 of 1
Comments: 9 | Views: 1592
Microsoft Communities