wmiprvse.exe - hohe CPu Auslastung. Sicherheits/Wartungscenter verantwortlich?

[Holzkopf Joe]

Hallo,

ich hab seit neuestem ein Problem mit dem Windowsprozess wmiprvse.exe (OS: Win7 HP 64 Bit)
(ja, ich weiß, da bin ich nicht der erste und es gibt wohl auch genügend dazu im Internet zu finden, nur hilft mir davon nichts weiter )
Vorhin fiel mir auf, dass meine CPU die ganze zeit im Turbo-Mode läuft, was ja im Leerlauf nicht so sein sollte. Habe dann mal mit dem Windows Taskmanager und dem ProcessExplorer nachgeschaut, welcher Prozess dafür verantwortlich sein könnte. Es stellte sich heraus, dass die Wmiprvse.exe eine CPU-Auslastung von etwa 10% erzeugte (meiner Ansicht nach etwas zu viel). Also hab ich mal google dazu befragt. Google spuckt zwar einen haufen an Lösungen aus, allerdings behebt keine davon mein Problem.

Vorgeschlagen wird ja meistens, den Dienst "Windows-Verwaltungsinstrumentation" zu beenden oder von "automatisch" auf "manuell" zu setzen. Das wollte ich zuerst auch machen, beim Beenden des Dienst fiel mir aber durch ein Dialogfenster, das aufkam, auf, dass ich damit auch Intel Rapid Storage und das Sicherheitscenter deaktiviere (und noch einen anderen Prozess).
Zum testen habe ich den Dienst aber mal deaktiviert. Die CPU taktete dann sofort wieder herunter. Soweit so gut, allerdings kann das ja keine Lösung sein. Hab also den Dienst wieder aktiviert. Danach wurde der Dienst nur vom Windows Sicherheitscenter genutzt. Die CPu-Asulastung war wieder bei 10%. Ich gehe deshalb einmal davon aus, dass das Problem etwas mit dem Sicherheitscenter zu tun haben könnte.

Nun weiß ich allerdings nicht mehr weiter, wie ich dennn das Problem lösen könnte.
Wenn jemand Rat hätte, wäre ich sehr dankbar.

 

[Sieben]

Eventuell irgendwelche Zeitplaner im Sicherheitscenter aktiviert? Ist das eigentlich ein exklusiver 64-Bit Dienst? Hab den garnicht bei mir drin und ich nutze den Defender eigentlich rund um die Uhr (ja hab die 32-Bit Version von Windows, war damals zu euphorisch beim Kauf )

 

[Holzkopf Joe]

zeitplaner habe ich keine aktiv, auch ist der Defender deaktiviert.

Im process Explorer habe ich aber etwas interessantes entdeckt:
Wenn ich mir die Threads der wmiprvse.exe anschaue, sehe ich dort eine ntdll.dll die eine Cpu Last von etwa 10% verursacht. Als Startadresse steht dort: ntdll.dll!rtlValidateHeap+0x170
Beende ich diese .dll läuft die wmiprvse.exe normal.
Jetzt müsste ich also nur noch wissen, was denn die ntdll.dll dazu bringt, soviel Leistung zu ziehen.

 

[Sieben]

Hmm, also hab bissl nachgeschaut und anscheinend hat dein Problem mit mehreren Internetverbindungen zu tun(?). Hast du eventuell ein/en Laptop oder Netbook und gehst des öfteren über verschiedene Anbieter rein(?) (z.B. per Kabel, Wlan, Handy).

Oder hast du einen Desktoprechner, der nur an einem einzigen Anschluss hängt?

Edit:
Wmiprvse.exe is a component of the Microsoft® Windows® operating system and is the executable for the Windows® Management Instrumentation that controls management information. By using industry standards, managers can call WMI to query and set default information on desktop systems, applications, networks and other enterprise components. Software developers use WMI to create event monitoring applications that can alert users when important actions have occured.
NOTE: Wmiprvse.exe file is located by default in the “C:\Windows\System32\Wbem” folder.
However, there is also a known worm that uses the same process name called “W32/Sonebot-B” and drops a copy of itself in the “C:\Windows\System32″ folder with the filename WMIPRVSE.EXE and can set Windows registry entries to run the copy whenever your reboot your computer:


http://windows-exe-errors.com/wmiprvse-exe-application-error-help/

 

[Holzkopf Joe]

Desktoprechner, der an einem Router hängt,der wiederrum an einem Router hängt und dann per Kabelmodem ins Internet gelangt. Ergo ist der Anbieter immer der gleiche

Virenscan hab ich sicherheitshalber mal duchgeführt (Avast und Malwarebytes Antimalware). beide keine Funde. Auch liegt die wmiprvse.exe dort wo sie liegen soll.
Ich hab mal versucht etwas über "ntdll.dll!rtlValidateHeap+0x170" herauszufinden, allerdings gibt es kaum Einträge bei google, die davon handeln. Einen Eintrag fand ich. Dort wurde gesagt, dass die hohe Auslastung an einem PnP-Gerät liegen könne. Habe allerdings in letzter zeit kein neues PnP-gerät angeschlossen. Zur überprüfung habe ich auch mal alle Geräte vom PC (im laufenden Betrieb) abgezogen --> keine Änderung.

 

[Sieben]

Ok, ich werd einfach mal rumgucken, ob ich was finde. Kann aber etwas dauern Hoffe es melden sich noch Andere mit weiteren Ideen.

 

[Holzkopf Joe]

öhm, hab die Lösung...

Als ich gerade anfing systematisch Prozesse zu killen und zu schauen, ob sich an der wmiprvse.exe was tut, fiel mir auf, dass sie beim beenden des Prozesses "sidebar.exe" alles wieder normal lief. Nach erneutem starten der Minianwendungen, ging die Last wieder auf 10% hoch. Nachdem ich nacheinander die Minianwendungen deaktiviert hatte, fand ich den Übeltäter: Drives Meter (ein Programm zum Anzeigen der Festplattenfüllstände). Lief eigentlich immer problemlos, keine Ahnung warum es anfing zu hängen.

trotzdem danke für deine Bemühungen mir zu helfen. War ja gar nicht so einfach das Problem zu lokalisieren, wie man an den vielen verschiedenen Lösungsansätzen sehen kann.

 

[Sieben]

Immerhin, also liegt es sozusagen an den Programmen, die darauf zugreifen. Was mir selber aufgefallen ist: Hab die .Exe doch im Win\WBEM-Ordner und nach dem Starten der Datei lief sie bei 0% Last und hat sich anschließend selbst beendet.

Hier ein Link den ich mit folgenden Begriffen bei Google gefunden hab:

Begriff: "wmiprvse.exe nicht gestartet"

C/C++ Forum :: WMI und wmiprvse.exe

Ergo: Solange es kein Programm gibt (oder auch Dienst) der die WmiPrvSE.exe nicht nutzt, startet das Ding auch nicht bzw. schaltet sich sogar selber ab

EDIT: Schön, dass du dein Problem selber lösen konntest So lernt man doch im Leben und Lernen mit Erfolgsereignissen macht doch am meisten Spaß

Abgesehen davon ist es ein Prozess und kein Dienst, macht aber nichts.