Systemanalysen machen Spass 
Heute hatte ich einen Laptop mit Windows Vista und sollte diesen “ein wenig schneller machen”.
Nach dem üblichen ausmisten stieß ich auf einen Prozess der eine Menge CPU Leistung beanspruchte (50 -60 %, zeitweise fast 100%) wermgr.exe
Eigentlich gehört dieses Prozess zur Fehlberichterstattung (die so sinnvoll ist wie ein Krebsgeschwür) – also den Prozess aus den Diensten entfernt und die Fehlberichterstattung deaktiviert.
Nach einem Neustart startet der Prozess komischerweise wieder.
Ein check bei VirusTotal – sieht nicht verdächtig aus.
Die Datei einfach zu löschen könnte Probleme verursachen, wenn andere Programme diese Anwendung starten – Fehler etc.
Ich überlegte mir die wermgr.exe einfach durch eine .exe zu ersetzen die nichts macht.
Es besteht zwar nach wie vor das Risiko, dass andere Anwendungen einen Rückgabewert von wermgr.exe erwarten und es so zu Fehlern kommt, da ich den Kunden aber gut kenne bin ich bereit das Risiko für ihn einzugehen 
Die “leere .exe” ist schnell erstellt und damit mir Vista nicht einen Strich durch die Rechnung macht, entschließe ich mich über eine Sidux Live CD die Files auszutauschen.
Pustekuchen – Sidux verweigert mir jeden Zugriff auf die Datei.
Slitaz zeigt sich hier schon williger.
In der cmd – (root) – chmod 777 auf wermgr.exe – danach rm (direkt geht nicht).
Neue Datei rein und siehe da – die CPU zeigt sich künftig sehr entspannt.
Update:
Nun nach einem halben Jahr kann ich mit ruhigem Gewissen sagen, dass man die wermgr.exe problemlos austauschen kann, wenn CPU Probleme bestehen.
Da ich vor kurzem gefragt wurde, wo man denn eine leere .exe her bekommt, hier machte ich mal eine:
wohl kein einzelfall
http://forum.chip.de/windows-vista/wermgr-exe-treibt-mich-wahnsinn-1261203.html
hast du fein gemacht
*hinterm ohrläppchen kraul*
Kann eigentlich nicht sein das sidux dir das nicht erlaubt und Slitaz schon.
Liegt warscheinlich eher daran das Slitaz automatisch den ntfs-3g treiber nimmt und dir schreiben auf ntfs partitionen erlaubt.
Um sidux zu verteidigen behaupte ich mal ein “mount -t ntfs-3g /dev/sdaX /mnt” hätte es unter sidux auch getan.
ich hätte erstmal gecheckt auf welche files, mem usw. der prozess zugreift
man muss das problem an der wurzel packen, nicht überbügeln
hoohead: Natürlich hast Du recht und natürlich ist das ganze im Support auch eine Kostenfrage. Da fragt man sich, was ist günstiger für den Kunden – neu installieren, oder mal eben ein Prozess fixen, das Risiko abwägen und den Kunden auf die Vorgehensweise hinweisen.
So bezahlte er für die ganze Sache 20 Euro – richtig wäre es gewesen, dem Kunden zu sagen: “da ist was faul” – entweder setze ich das System neu auf – für 69 Euro – oder investiere vielleicht 2 – 3 Stunden um auch wirklich sicher zu sein, wo die Probleme herführen – für 100 Euro.
Der Kunde war übrigens mit meiner Entscheidung durchaus zufrieden und wird mich in den nächsten Tagen mit weiteren Feedbacks füttern.
Ich stimme skskill zu.
Sidux mountet das NTFS Dateisysteme nur ro (read-only), man kann es als rw remounten
kling interessant
@ bitchiller
die “Wurzel” ist hier eher die initialisierung
[quote]Sidux mountet das NTFS Dateisysteme nur ro (read-only), man kann es als rw remounten[/quote]
naja, das ist Treiber-Sache und “mountparameter” abhängig.
Ich hatte mich hier gerade schon bezüglich des “Trojaner” geäussert, doch scheinbar wurde das nicht übernommen.
Meine Vermutung war, dass die wermgr.exe durch schadcode/bugs/whatever so eine hohe auslastung aufweist und evtl. durch die “Ereignisanzeige” (oder ähnliches) initialisiert wird. bin auf windows rechnern nicht so fitt und vista eh nicht XD
hoohead: “Ich hatte mich hier gerade schon bezüglich des “Trojaner” geäussert, doch scheinbar wurde das nicht übernommen.”
Vielleicht ein falsches Captcha eingetragen – weder in der Warteschlange noch im Spamordner war ein Kommentar