Sollte man Windows-Fehlerberichterstattungsdienst ausschalten?
 

Hallo Holzpferd,

wenn du aus "Datenschutzgründen" das Versenden computer- und nutzerspezifischer Daten wirklich abstellen möchtest, dann musst du dies an sehr vielen Orten tun:
Die entsprechenden Einstellungen in den Gruppenrichtlinien dürften selbst für einen erfahrenen Systemadministrator für einige Arbeit sorgen - und selbst dann ist der "Schutz" nicht zu 100% gegeben.....
Der Fehlerberichterstattungsdienst selbst ist da nur ein winziges Steinchen in einem riesigen Mosaik - und wie immer hat das Abschalten auch Nachteile: Wenn eine Anwendung nämlich im Hintergrund oder gar auf einem Server läuft, dann merkst du vermutlich überhaupt nicht mehr, wenn sie abgestürzt ist, falls der WER-Dienst deaktiviert ist.

Aktuell gibt es meiner Meinung nach nur die Möglichkeit, eine NG-Firewall zu verwenden ("new generation") um das unbemerkte Versenden von Daten in den Griff zu bekommen - allerdings sind die Kosten dann auch nicht von Pappe.....

Zusammenfassend muss ich erwähnen, dass es bezüglich des Datenschutzes kaum einen Unterschied macht, diesen einzelnen Dienst zu deaktivieren - und es kann zu Problemen kommen, da auch andere Anwendungen recht häufig von MS-Diensten fleißig Gebrauch machen oder gar von ihnen abhängig sind.

Fazit: Ich persönlich empfehle das Abschalten des Dienstes nicht - besser wäre eine entsprechend restriktive Einstellung der Gruppenrichtlinien.

Liebe Grüße, Alois

Meine Gründe betreffen den Datenschutz. Da ich aber nicht weiß, was da von Microsoft so alles gesammelt und auch weitergegeben wird - eventuell auch nach Abstellen der Berichterstattung noch - kann ich das Problem nicht so richtig abschätzen. Das geht ja offenbar auch dem von mir in #1 verlinkten MVP Michael Pietroforte so, wenn er unter Artikel 4 seiner Serie "Windows Error Reporting" unter der Überschrift "How to disable Windows Error Reporting" (https://4sysops.com/archives/how-to-disable-windows-error-reporting/) u.a. schreibt (von mir ins Deutsche übersetzt):

"Die 4 Optionen scheinen für sich selbst zu sprechen (siehe Screenshot), aber ich denke, zumindest 2 von ihnen sind ein wenig irreführend. Die Default-Einstellung ist "Automatisch nach Lösungen suchen" und die zweite Option ist "Automatisch nach Lösungen suchen und zusätzliche Berichtsdaten senden, wenn erforderlich". Ich vermute, die meisten glauben, dass mit der ersten Einstellung keine Fehlerberichte an Microsoft gesendet werden. Aber als ich meine Problemberichte nachprüfte, bemerkte ich, dass die Windows Fehlerberichterstattung Fehlerberichte an Microsoft gesendet hat. Es ist mir unklar, was "additional report data" in der zweiten Option bedeutet.
Ich denke, dass Microsoft transparenter sein sollte bezüglich der Informationen, die die Windows Fehlerberichterstattung nach Redmond sendet."

Die 4 Optionen in dem Screenshot scheinen ja wirklich sehr einfach zu sein, aber eben mit den erwähnten datenschutzmäßigen Unsicherheiten. In demselben oben angegebenen Link verweist MVP Michael Pietroforte unter der Überschrift "Disable Windows Error Reporting through Group Policy" auf einen ausführlichen Technet Artikel (hxxp://technet.microsoft.com/en-us/library/ee126091(WS.10).aspx), der mir wirklich zu kompliziert ist und damit deine Ausführungen bestätigt.

Aus den genannten Gründen, und da ich lizenzmäßig nichts zu befürchten habe, werde ich deinem Rat folgen und den Dienst wieder erlauben.

Danke für deine Hilfe soweit. Ich weiß nicht, ob du (oder jemand anders) zur Lösung von runonce-Problemen noch etwas sagen willst. Wenn nicht. wäre dieser Thread für meinen Geschmack beendet.

Hi, wenn's danach geht kannste MS als US-Unternehmen nicht vertrauen und müsstest konsequenterweise Windows offlne betreiben oder ein quelloffenen System wie zB Debian einsetzen.

Hallo Holzpferd,

um welchen "Runonce" - Fehler geht es denn? ; ich persönlich verstehe darunter nämlich einen Registrierungsschlüssel, wo es um den Autostart von Programmen geht - vielleicht steht dort noch ein Programm, das du inzwischen deinstalliert hast? :confused:

Liebe Grüße, Alois

Vielen Dank Alois, dass du mir weiterhelfen willst. Ich weiß nicht so recht, womit ich bei der Fehlerbeschreibung beginnen soll.

Die Listen, die mir z.B.

• Sysinternals Autoruns
• System Explorer Autostarts
• DiamondCS Autostart Viewer

liefern, sind mir zu umfangreich und komplex, um darin nach dem runonce-Fehler zu suchen. Da sehe ich den Wald vor lauter Bäumen nicht. Aber wenn du daraus etwas entnehmen könntest, würde ich sie auf Anforderung posten.

Dazu möchte ich anmerken, dass ich gelegentlich schon mal in den Sysinternals Autoruns bei einzelnen Items Häkchen entfernt habe. Vielleicht war ich dabei nicht ganz konsistent. Mein Grundsatz war es dabei immer, bei sämtlichen Items, die zusammenzugehören schienen, das Häcken wegzumachen. Ob ich dabei irgendwelche Abhängigkeiten übersehen habe, weiß ich nicht.

-------------------------------------------------

Heute habe ich mir noch einmal die Sysinternals Autoruns vorgenommen und eine ganze Reihe von Items mit dem Eintrag "File not found" in der Spalte "Image Path" gelöscht oder korrigiert – leider ohne Erfolg, was den runonce-Fehler betrifft.

Folgende zwei dieser "File not found"-Einträge geben mir allerdings Rätsel auf, nämlich

HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components
Internet Explorer File not found: start

HKLM\SOFTWARE\Wow6432Node\Microsoft\Active Setup\Installed Components
Internet Explorer File not found: start

Der Kontextmenü-Eintrag "Jump to¼" führt mich u.a. zu dem Unterschlüssel "StubPath" mit folgenden Wert: "C:\Windows\system32\cmd.exe /D /C start C:\Windows\system32\ie4uinit.exe –ClearIconCache".. Da muss wohl mal etwas falsch geschrieben worden sein. Vielleicht liegt ja da der Hund begraben und ich sollte z.B.

• beide Einträge löschen?
• vor start einen Schrägstrich setzen? (Entschuldigung, wenn das Blödsinn sein sollte. Mit diesen Befehlszeilen-Parametern kenne ich mich nicht aus.)

Hallo Holzpferd,

den 1. dieser Einträge (den mit ":start") kannst du tatsächlich löschen - er wird nicht benötigt;

wegen dem 2., der eigentlich vorhanden sein sollte, empfehle ich einen Start von "cmd" als Administrator und einen Lauf des Systemfilecheckers mittels "sfc /scannow" - je nachdem, ob das Ding dann vorhanden ist oder nicht, sehen wir dann weiter.....

Liebe Grüße, Alois

Mir scheint, du spielst hier auf das Vorhandensein von C:\Windows\system32\ie4uinit.exe an. Dann läge hier ein Missverständnis vor. Diese Datei ist auf meinem Rechner tatsächlich vorhanden. Aber diese Datei ist es ja nicht, die von Sysinternals Autoruns als unauffindbar gemeldet wird, sondern es ist die Datei "start". Da liegt doch wahrscheinlich nur ein Syntax-Fehler vor, oder?

Übrigens ist der StubPath (der in roter Schrift) bei beiden Schlüsseln identisch. Es würde mich auch mal interessieren, warum der 2. Schlüssel systemrelevant sein soll und der 1. nicht.

Hi,

ja, die Einträge mit "start:" kannst du unbesorgt löschen; allerdings sind das gar keine Dateien sondern geben nur einen Pfad vor (wenn der zufälligerweise nicht stimmt, kommt es eben zu diesem Fehler);
langer Rede kurzer Sinn: Weg damit!

Liebe Grüße, Alois

Hi,

zur Syntax willst du dich offenbar nicht äußern. Trotzdem mal vielen Dank soweit.

Ich habe inzwischen einen weiteren, zunächst übersehenen "File not found" in den Sysinternals Autoruns entdeckt:

Auto Update Property Sheet Extension - - File not found: C:\Windows\system32\wuaucpl.cpl

Meine Windows Updates haben aber eigentlich bis zuletzt immer gut gefunzt. Kannst du dazu etwas sagen? Googeln hat hier nicht viel gebracht. Von einem Download der Datei wird abgeraten. Am runonce-Fehler wird das Fehlen dieser Datei wohl eher nicht beteiligt sein, da die Windows Updates ja trotzdem funzen.

Hallo Holzpferd,

1) Man sollte alle diese Einträge prinzipiell entfernen, um im Falle einer erneuten Installation doppelte Registryeinträge zu vermeiden

2) Es gibt viele Programme und Tools, die diese Einträge zwar nur temporär, aber immer wieder einmal aufrufen, so dass man immer wieder löschen "darf"

3) Mit "Autoruns" kann man auch relativ viel kaputtmachen, insbesondere dann, wenn man nicht wirklich ganz genau weiß, was man tut

4) Den "Systemfilechecker" würde ich jedenfalls sicherheitshalber einmal laufen lassen.....

Aufgrund meiner Erfahrung rate ich generell von der Benutzung der "Autoruns" ab: Ist man nicht wirklich ein Spezialist - dann kann es das BS sicher besser und man kann keinerlei Verbesserungen erreichen - im Gegenteil! :nono:

Liebe Grüße, Alois

Hallo Alois,

ich denke auch, dass ich die Versuche, über die Autoruns die runonce.exe-Fehler zu finden, jetzt aufgebe. Mir wäre es sowieso lieber, den Fehler über die Ereignisanzeige zu finden. Bevor ich damit weitermache, will ich aber noch kurz auf den von dir vorgeschlagenen Systemfilecheck eingehen.

Ich füge hier mal einen Screenshot von meinen Ergebnissen ein.


http://up.picr.de/19684240rc.jpg


Der Satz "Der Windows-Ressourcenschutz hat beschädigte Dateien gefunden und konnte einige der Dateien nicht reparieren." ist mir unverständlich, wenn ich mir die Ergebnisse der Datei "sfcdetails.txt", die ich mir aus der CBS.log-Datei erstellt habe, anschaue. Da wurde nichts repariert, und es findet sich auch keinerlei Hinweis darauf, was nicht repariert werden konnte.

Ich habe dieses Ergebnis im Laufe der Zeit wieder und wieder erhalten und will das jetzt nicht weiter verfolgen, wenn du nicht eine einfache Patentlösung dafür parat hast.

Nun zu meinem eigentlichen Anliegen, dem runonce-Fehler. Ich füge hier mal eine Zusammenstellung dieses Fehlers aus der Win7-Zuverlässigkeitsanzeige von 2 aufeinanderfolgenden Tagen ein, die ja die Daten der Ereignisanzeige wiedergibt. Kannst du daraus eine Spur für das weitere Vorgehen erkennen?


http://up.picr.de/19684382ap.jpg

Hi,

wenn du über eine "richtige" Installations-Dvd verfügst, dann lege bitte diese ins Laufwerk und führe danach 2-3X den Systemfilecheck als Administrator aus - nur dann nämlich können die Dateien auch repariert werden.....

Liebe Grüße, Alois

Post © Alois 2014 – Alle Rechte vorbehalten – kein Teil darf in irgendeiner Form ohne schriftliche Genehmigung des Autors kritisiert werden! :aufsmaul:

Hi,
meine Antwort hat wieder mal lange auf sich warten lassen, weil ich erst mal die richtige Bezeichnung meiner Volumes im Recovery Environment durch Trial and Error klären musste.

Ich hatte auf mehreren Websites die Befehlszeile

X:\Sources>sfc /scannow /offbootdir=d:\ /offwindir=d:\windows

entdeckt, konnte aber damit und auch mit einigen anderen Kombinationen der Ortsbezeichnungen den Systemfilecheck nicht zum Laufen kriegen (die Beschreibungen für offbootdir und offwindir, die ich mit Google finden konnte, waren mir alle nicht eindeutig genug). Erst als ich von X:\Sources> nach C:\> wechselte und statt d:\ an beiden Stellen ebenfalls c:\ einsetzte, startete der Systemfilecheck und brachte nach ca. einer Viertelstunde als Ergebnis

"Der Windows-Ressourcenschutz hat keine Integritätsverletzungen gefunden."

Ich füge mal als Anlage meine Suche nach den vorhandenen Volumes und ihren Bezeichnungen sowie schließlich die richtige Befehlszeile mit Ergebnis bei.

http://up.picr.de/19768654sq.jpg


http://up.picr.de/19768655aw.jpg



Nachdem also nun sowohl die Suche in den Autoruns als auch der Systemfilecheck keine Anhaltspunkte für die Ursache des runonce-Fehler geliefert haben, komme ich auf den letzten Screenshot meines Postings #12 (Zusammenstellung des runonce-Fehlers aus der Win7-Zuverlässigkeitsanzeige von 2 aufeinanderfolgenden Tagen) zurück. Lässt sich da etwas herauslesen? Sollte ich diese Spur vielleicht in einem anderen Forum weiterverfolgen? In welchem wäre das am erfolgversprechendsten?

Hi,

aus deinen Logs geht eindeutig hervor, dass es sich hier um nicht mehr vorhandene Dateien handelt ("Pfad unbekannt, Modul unbekannt usw.");
sie sind nicht von Bedeutung und die Einträge können gefahrlos gelöscht werden - doch wie gesagt, sie kommen wieder (warum, habe ich ja bereits ausgeführt). :heilig:

Liebe Grüße, Alois