CBS.Log

[Pfefferstreuer]

"Du bist zu faul!"

Hallo,

ein scannow erzeugte eine fast genau 160.000 Kb große "txt" Fehlerprotokoll-Datei "CBS.Log".

Als Anlage ein Screenshot, die nur Art und Darstellung der Fehler-Meldungen zeigt. Meine Firewall od. Virenscanner von "G Data" hat eigene Protokoll-Dateien.

Ich kann dieses Fehler-Protokoll händisch unmöglich analysieren.

Nun frage ich auch hier, ob jemand ein Tool kennt, welches - ähnlich eine "Bluescreen"-Fehler-Datei, die scannow-"CBS.log" übersichtlicher macht.

Es wird/kann doch nicht so sein, dass die "CBS.log" von Microsoft-User weltweit händisch durchgearbeitet wird?!
Als ich gleiche Frage in einem artverwandten Forum stellte war die Antwort: "Du bist zu faul!"

Ich bin nicht zu faul. Ich will nur nicht blöd im Kopf werden.

Die Hoffnung stirbt zuletzt.
Gruß
Pfefferstreuer

 

[ryan_blackdrago]

Datei in Excel ziehen > Text in Spalten > entsprechenden Trenner setzen > Events mit bedingter Formatierung hervorheben

 

[Serana]

Vor allem solltest du dir das Leben nicht unnötig schwer machen und nur die Logdaten untersuchen die dich überhaupt interessieren. Soll heißen

- Du kopierst die CBS.log meinetwegen auf den Desktop und holst dir somit eine Arbeitskopie.
- Öffne das Teil in einem Texteditor deiner Wahl (für den Zweck sollte auch der Windows Editor reichen) und suche nach dem ersten Vorkommen des Datums welches dich interessiert. Im Fall des heutigen Datums wäre das die Zeichenfolge "2018-06-12". Jetzt gehst du wieder ganz nach oben und fängst an danach zu suchen.
- Du solltest jetzt an der Stelle der Datei sein an der die heutigen Einträge anfangen. Alle Einträge darüber, welche ein älteres Datum als das gesuchte aufweisen, löscht du.

Jetzt mußt du dich nur noch entscheiden, ob du die verbleibenden Daten von Hand untersuchst oder das ganze, wie von ryan_blackdrago vorgeschlagen in Excel oder ein anderes derartiges Programm lädst und dort weiter bearbeitest.

 

[areiland]

In die Cbs.log schreiben zig Windows Dienste und Tools Logdaten, Sfc ist also nur eine Systemkomponente, die dieses Log beschreibt. Dazu kommt, dass die Cbs.log über Wochen, manchmal sogar Monate beschrieben wird, bevor Windows sie archiviert und eine neue Version beginnt.

 

[Pfefferstreuer]

Hallo,

das Wichtigste: Euch allen herzlichen Dank!

Meine Idee:
Ich ging davon aus, dass das System neue Log-File anlegt, wenn die alten weg sind. Seht in Anlage "CBS_div-LOG", grünen "Kiste". Ich habe alle log-Files umbenannt (-ALT), somit sind diese für das System nicht mehr existent.

Das System neu gestartet: Meine Vermutung stimmte. Mit dem System-Start wurde die CBS.log neu angelegt.

Aber, seht in der Anlage die rote "Kiste" die vom System neu angelegte CBS.log. Den Inhalt der System neu erzeugten log-File steht in der Anlage "Neue_CBS.log".

Ich kann damit nichts anfangen.

Gruß
Pfefferstreuer

 

[can320]

Wie kommst du darauf, du müsstest dieses Logfile durcharbeiten? Normalerweise erstellt Microsoft solche Logs, damit ihr eigenes Personal so etwas im Fall der Fälle untersuchen kann. Ansonsten kannst du hier die Suchfunktion zum thema CBS.log verwenden. Oder hast du eine konkrete Frage?

 

[areiland]

@Pefferstreuer
Eine unnötige Aktion, denn die von Sfc /Scannow erzeugten Einträge stehen in Deiner aktuellen Cbs.log gar nicht mehr drin. Die stehen nach wie vor in der alten und zwar in den Zeilen mit der Spalte [SR].

 

[Serana]

Was ich mich gerade frage: Warum hast du denn überhaupt "sfc /SCANNOW" ablaufen lassen? Denn wenn das nicht irgendeinen handfesten Grund hatte sehe ich in dem ganzen Thread hier lediglich eine mehr oder auch weniger angenehme Art Zeit totzuschlagen.

Es wäre also gut wenn du zumindest verrätst was denn der Grund der ganzen Sache ist. Also über welchen geheimnisvollen Fehler du gestolpert bist oder welche Fehlermeldung dich aufgeschreckt hat. Oftmals kann man mit der Schilderung des eigentlichen Fehlers nämlich mehr anfangen als mit riesigen Logdateien die man zunächst einmal entschlüsseln muß. Außerdem wüßte man im Falle eines tatsächlichen Fehlers so wenigstens, wonach überhaupt gesucht wird.

 

[Pfefferstreuer]

@ThanRo, ich bin ein von Grund auf höflicher Mensch, darum bleibe ich höflich und werden nicht zynisch. Meine Frage #1 formulierte ich allgemein verständlich. Einen scannow starte ich von Zeit zu Zeit. Also unregelmäßig. Bisher immer mit einem "alles i. O."-Ergebnis.

Dieses Mal mit einem 160.000 Kb großen Fehlerprotokoll. Das ist ein "Hammer"! Die Ursache dafür kenne ich nicht - würde sie gerne finden. Wie beschrieben, starte ich von Zeit zu Zeit einen Scan - zumal er "heilende Wirkung hat" und mir einen "ruhigen Schlaf" beschert. Ähnlich einer Inspektion meines Autos.

Findet der Mechatroniker einen Fehler, liest er den Fehlerspeicher aus. Der hat es einfach. Denn der Fehlerspeicher meines Systems nennt sich "CBS.Log" und ist 160.000 Kb groß! Für den Fehlerspeicher auszulesen & auszuwerten hat der Mechatroniker ein Hilfsmittel, ein Diagnosegerät.

Ich fragte nur, ob es ein Tool ->Diagnosegerät<- gibt, welches die Daten in der "CBS.Log" ->Fehlerspeicher<- nicht auswertet, sondern nur übersichtlich darstellt. Es gibt kein Tool, aber ein "Diagnosegerät" - mich.

"...wonach überhaupt gesucht wird"? Nein. Das macht die Sache so spannend. Alles klar "Lieutenant"?

Gruß Pfefferstreuer

Ps.: Von der "CBS-Log" aufgeschreckt, habe ich mich im System genauer umgesehen und eine weitere Log-File gefunden. Die ist winzig, aber mit dem Inhalt komme ich auch nicht klar. Der "Film" läuft in einem anderen "Kino".

 

[Serana]

Der Unterschied ist nur, daß der zitierte Mechatroniker in diesem Fall wüßte, wie mit Logdateien umzugehen ist und warum sie die Tendenz haben sich zu riesigen Größen aufzublähen.

Vor allem wüßte ein Mechatroniker, daß es da eine Diagnosekonsole gibt die für den Alltagsgebrauch viel einfacher zu handhaben ist und sogar direkt mit zumeist menschenlesbaren Erklärungen daherkommt. Diese Konsole nennt sich Ereignisanzeige und steht seit langer Zeit unter Windows zur Verfügung. Microsoft weiß nämlich selbst, daß die "CBS.log" sich für das lesen durch Menschen nicht wirklich eignet, sie wurde auch nicht auf Lesbarkeit sondern auf Effizienz getrimmt. Im Notfall soll ein entsprechend vorgebildeter Mensch wenigstens dort einen Hinweis finden warum in seinem System gerade etwas schrecklich schief ging.

Vor diesem Hintergrund wird vielleicht auch klar warum ich wissen wollte worum es überhaupt geht, denn kein normaler (zumindest nach meiner Definition von Normalität, ich will mich da nicht zu weit aus dem Fenster hängen) Mensch würde auf die Idee kommen sich diese Logdatei ohne handfesten Grund vorzunehmen.

Wenn es also lediglich um deinen Seelenfrieden geht, dann würde ich vorschlagen, daß du entweder die Herausforderung "CBS.log" annimmst und lernst diese Datei händisch durchzuarbeiten, oder du machst es wie tausende Systemadministratoren auch und hältst dich normalerweise an die Ereignisanzeige. Die ist schon fertig nach Themengebieten aufgeschlüsselt und auch da werden noch genügend Sachen drinstehen die dir kryptisch erscheinen. Nur stehen dort eben meist Erklärungen mit denen ein lernwilliger Mensch, als den ich dich durchaus einschätze, etwas anfangen kann.

P.S.: Nichts gegen dich, es gibt schon genügend Ignoranten da draußen die gar nicht einsehen etwas dazulernen zu wollen, aber mit der CBS.log hast du dir nun einmal einen der schwersten verfügbaren Knochen ausgesucht.

 

[Darlis]

Bisher immer mit einem "alles i. O."-Ergebnis.

Und das ist jetzt nicht mehr der Fall? Oder warum willst du die Logdatei durchsuchen?
ThanRo hat ja schon die Ereignisanzeige angemerkt. Wenn es Fehler gibt, werden die i.d.R. dort gemeldet. Unabhängig von sfc.

 

[Pfefferstreuer]

@Darlis, "Und das ist jetzt nicht mehr der Fall? Oder warum willst du die Logdatei durchsuchen?" was veranlasst dich zu dieser Frage?

S-e-l-b-s-t-v-e-r-s-t-ä-n-d-l-i-c-h spiegeln sich sfc-Ergebnisse NICHT in "Ereignisanzeige"!

Einträge in "Ereignisanzeige" werden Ereignisse erfasst, richtig. Aber die Ereignisse in allen Bereichen, die älter als 7 Tage sind, werden überschrieben oder gelöscht. Aha.

Irgend wo habe ich geschrieben, dass es für mich kein Anlass bedarf, einen "sfc /scannow" zu starten.

@Darlis, ich glaube, dass du einer der Sorte Forenmitglied bist, die gerne Ratschläge geben - die aber sinnlos sind - weil "von gestern". Sorry.

Um das zu vermeiden, solltest du dir die Zeit nehmen die Fehler-Historie zu lesen; weil: Dank dem Engagement anderer im Problem involvierte Spezis, die Lösung des Problem am Horizont aufblitzt. *das schöngeistig, war Poesie! Meldet mich jemand als Kandidat für den Pulitzer-Preis an? Hä!

Also @Darlis, den Fehlerhistoriegnoranten muss ich antworten, aufgrund dessen man mich in einem anderen Fachforum final beschuldigte: Ich auf diese oder jene Antwort auf Methusalem-Niveau nicht reagiert habe, so Desinteresse an einer Problemlösung demonstrierte. Darum das Problem nicht gelöst werden konnte. Peng! Ich war es schuld.

Diese Antwort kostete ein paar Minuten Zeit; die machten aber Sinn in so weit, dass, wenn mir wieder fehlende Motivation unterstellt wird, auf diese, meine hoch vergeistigte Antwort verweisen kann. Das nenne ich Recycling.

Lieber @Darlis, wenn du das Gefühl hast ich habe dich irgendwie, irgendwo gekränkt, geschah das ohne Absicht und entschuldige mich bei dir.

Gruß
Pfefferstreuer

Post Skriptum: Allgemein: Die Angst vor langen Wörtern heißt Hippopotomonstrosesquippedaliophobie

 

[Darlis]

was veranlasst dich zu dieser Frage?

Weil mir immer noch nicht klar ist, ob du jetzt einem Fehler auf die Schliche kommen willst oder nur ein weiteres Tool haben willst, das dir sagt "Alles OK". So wie ich dass bis jetzt verstanden habe, gehst von einem Fehler aus, weil die "Fehlerprotokoll-Datei "CBS.Log" " 160MB groß ist. Es handelt sich aber um kein reines Fehlerprotokoll und wenn es Fehler geben würde, würden sfc dies auch anzeigen.

Dass die von sfc gemeldeten Fehler nicht in der Ereignisanzeige stehen ist mir klar, dass habe ich auch so nicht geschrieben. Es kann aber sein, dass Fehler, die u.A. von sfc gefunden/repariert werden können, in anderer Form dort auftauchen, also von anderen Programmen gemeldet wurden.
Wenn sfc aktuell keine Fehler meldet, sehe ich kein Bedarf in einer Historie zu gucken ob es früher mal Fehler gegeben hat (lt. deiner Aussage gab es diese auch nicht).

Dass du anlasslos sfc ausführst habe ich auch nicht mokiert. Ich mache das auch regelmäßig. Wenn das Tool aber sagt, dass alles OK ist, ist die Sache für mich erledigt.

Du kannst übrigens mit jedem Textverarbeitungstool in die Datei gucken und nach "error", "failed" und "can not" oder "could not" suchen. Das sind Wörter die erfahrungsgemäß bei Fehlern drin stehen.

 

[sedot]

Hey,
ich hab dir mal einige Links herausgesucht die dir weiterhelfen könnten, möglicherweise sind diese dir auch bekannt.

1 https://en.m.wikipedia.org/wiki/System_File_Checker
2 https://support.microsoft.com/en-us...le-entries-that-the-microsoft-windows-resourc
3 https://web.archive.org/web/2016103...com:80/system-file-checker-tool-windows-11822

Solltest du manuell per Suche in der .log Datei, wie in Beitrag #13 beschrieben, einen Eintrag mit dem Attribut „Cannot repair“ oder ähnlich finden, wäre da ein Ansatzpunkt - ein Lösungsvorschlag wird in Link 3 aufgezeigt.

Laut dieser Quelle
https://superuser.com/questions/466...le-generated-by-the-sfc-command-to-detect-cor
gab/gibt es auch ein Programm zur einfachereren cbs.log Analyse, ich konnte es nicht finden, vielleicht hast du mehr Glück.

 

[Pfefferstreuer]

@Darlis, @SE, @ThanRo, ich möchte hier keinen auf überheblichen Klugschei*er machen. Ich befürchte manchmal, dass man aneinander vorbei redet. Verzeih, wenn ich Umstände veranschauliche, die längst bekannt sind.

sfc /scannow schließt den Prüflauf mit einer "Ergebnisanzeige" ab. Siehe Anlage.

Der Scan findet defekte Dateien und listet diese in eine "CBS.Log"-File. Ob man die "CBS.Log" als "Fehlerprotokoll" oder anders bezeichnet ist prinzipiell sekundär; Statusbericht währe vielleicht treffender. Ist im Endeffekt "schnurzpiepegal".

Du schreibst: "Es ("CBS.Log") handelt sich aber um kein reines Fehlerprotokoll und wenn es Fehler geben würde, würden sfc dies auch anzeigen." Stopp! Das verstehe ich nicht; scannow erzeugt doch ein Protokoll. 160 Kilobyte groß - und weist darauf hin-> "Details finden Sie in der Datei ´CBS.Log´ (windir\Logs\CBS\CBS.log); z. B. ´C:\Windows\Logs\CBS\CBS.log´". Auf die C:\Windows\Logs\CBS\CBS.log beziehe ich mich.

Weil ein 160 Kilobyte langes Protokoll hammerartig groß - implizit alte + neue Einträge - für mich nicht analysierbar ist, kam ich auf auf die nobelpreiswürdige Idee, die man auf #5 nachlesen kann.

areiland´s Antwort (#7) verwirrte mich. Ihr seit bessere Mic-W7-Spezis. Lest bitte #5, beachtet dabei auch die im Zusammenhang stehenden Anhänge(!). Dann lest bitte areiland´s Antwort #7 und erklärt mir bitte den Zusammenhang und den logischen Bezug auf das von mir in #5 geschilderte.

Euch (außer Düsseldorf) wünsche ich ein phantastischer Wetter!

Dir Darlis - Euch allen herzlichen Dank für die Unterstützung!

Gruß Pfefferstreuer

@ThanRo, in weiten Teilen stimme ich dir zu. Danke. Aber.....

Bevor der Grund für unseren erbaulichen Meinungsaustausch in Vergessenheit gerät: Ich möchte die Ursachen für die von scannow hinterlegten Fehler ergründen.

 

[Darlis]

Das verstehe ich nicht; scannow erzeugt doch ein Protokoll.

Genau, dieses Schnurzpiepegal-Protokoll, das angelegt wird, egal ob Fehler jedweder Art aufgetreten/vorhanden sind oder eben nicht.

und weist darauf hin

Genau, aber nur dann, wenn tatsächlich Fehler gefunden wurden (Danke für die Bestätigung!). Bisher bin (nicht nur) ich davon ausgegangen, du möchtest die Datei nur aus Spaß an der Freude analysieren.

Was du jetzt machen solltest ist die Log-Datei zu löschen und nach einem Neustart wieder sfc/scannow auszuführen. Dann stehen dort nur relevante Einträge zur Fehlersuche drin.
Dann sucht du mit den von mir angegeben Stichworten nach Fehlern und fütterst Google mit den gefundenen Sätzen.

 

[Pfefferstreuer]

@SE.

Ich kenne: https://superuser.com/questions/466...le-generated-by-the-sfc-command-to-detect-cor

vor allem den: findstr /c:"[SR]" %windir%\Logs\CBS\CBS.log >"%userprofile%\Desktop\sfcdetails.txt"

Nur: Die hier als Anlage beigefügten "Details" beziehen sich nicht nur auf den sannow, den ich heute zum Zweck der Demo erstellt habe. Mitnichten: Darin steht auch älterer Krempel. Damit du aber ein Gefühl für Microsoft-"Details" bekommst..siehe Anlage.

Danke.

Ergänzung (17. Juni 2018)

@Daris,

auf meinem System befinden sich einige Fehler, die nicht "eben mal so" gefixt werden können. Nix mit "Spaß an der Freude" und "aus Jux".

Was du jetzt machen solltest ist die Log-Datei zu löschen und nach einem Neustart wieder sfc/scannow auszuführen. Dann stehen dort nur relevante Einträge zur Fehlersuche drin.

Hab ich, hab ich, hab ich:

Weil ein 160 Kilobyte langes Protokoll hammerartig groß - implizit alte + neue Einträge - für mich nicht analysierbar ist, kam ich auf auf die nobelpreiswürdige Idee, die man auf #5 nachlesen kann.

So, nun muss ich in mein Rübenfeld Blattläuse zählen.

Schönen Sonntag noch mal.

Dank & Gruß
vom alten Esel

 

[Darlis]

Der Befehl ist mir bekannt und dient dazu, das Schnurzpiepegalprotokoll auf relevantere Einträge einzustampfen.

In #15 dachte ich, die deine Intention wäre jetzt endlich enthüllt, also das Finden der sfc gemeldeten Fehler. Jetzt kommst du mit "älteren Krempel"... Für dich mag es klar wie Kloßbrühe sein, aber ich verstehe nicht, was du jetzt von mir/uns willst. Ein Anhang sehe ich in #17 nicht.

 

[sedot]

Hey,
ich beziehe mich erstmal auf Beitrag #15 bzw. konkret deinen Anhang ebenda.
Genau diese Meldung ist im Mircosoft-Helpcenter beschrieben. Hier entlang bitte:
https://support.microsoft.com/en-us...er-tool-to-repair-missing-or-corrupted-system
Zitat:

• Windows Resource Protection found corrupt files but was unable to fix some of them. Details are included in the CBS.Log %WinDir%\Logs\CBS\CBS.log.
  
  To repair the corrupted files manually, view details of the System File Checker process to find the corrupted file, and then manually replace the corrupted file with a known good copy of the file.

weiter unten auf selbiger Seite ist beschrieben wie du „manually replace a corrupted system file“ aber nur, falls du eine „known good copy of the file“ hast.

Ich würde, falls mein System irgendwelche gravierende Ausfallerscheinungen zeigt, die mich bei der Nutzung beeinträchtigen vermutlich einfach Win7 neu installieren. Die Fehlersuche und Analyse, mit unbekanntem Ergebnis, steht meiner Meinung nach in keinem sinnvollem Zeit/Aufwand-Verhältnis. Aber gut, ich bin da recht pragmatisch und kein Windows-Systemadministrator. Ob und in welcher Form du nun Was genau machst musst du selbst abwägen.

 

[Serana]

Zunächst einmal gilt, daß ausschließlich aktuelle Ergebnisse von sfc von Interesse sind. In dem Zusammenhang sind alte Ergebnisse weitgehend uninteressant.

Nun hat sfc aber offensichtlich tatsächlich ein Problem entdeckt und hier beginnen die wirklichen Probleme. Denn wenn dieses Tool einen Fehler entdeckt und nicht selbst korrigieren kann, kann man nur hoffen eine "saubere" Version der fraglichen Datei/Dateien zu haben.

Falls keine einwandfreien Dateien zur Verfügung stehen hat man mehrere Möglichkeiten:

1. Man ignoriert den Fehler und hofft, daß das ganze keine ernsthaften Folgen hat. Mit etwas Glück kommt in einem Systemupdate eine saubere Version und löst das Problem.
2. Man füttert die Windows eigene Suche (oder ein anderes Suchprogramm) mit dem gesuchten Dateinamen und hofft, daß man irgendwo im System fündig wird. Mit viel Glück (eher unglaublich viel Glück) wird eine saubere und aktuelle Version gefunden und man kann die kaputte Datei ersetzen.
3. Man könnte auch im Internet auf die Suche nach einer sauberen und aktuellen Version der fraglichen Datei gehen und hoffen bei der Geschichte nicht Opfer von gut getarnter Schadsoftware zu werden. Man sollte sich also schon sehr sicher sein, daß die Quelle seriös ist.
4. Man installiert die Kiste komplett neu.

In deinem Fall würde ich vermutlich neu installieren und dabei, wenn die Hardware mitspielt (ich weiß ja nicht wie alt deine Hardware ist), gleich auf Windows 10 upgraden. Das sollte immer noch funktionieren. Falls du bis jetzt das System noch nicht auf SSD hast würde ich dann nach Möglichkeit auch gleich eine min. 128 GB SSD anschaffen (Kostenpunkt zwischen 30 und 40 Euro). Das wäre auf jeden Fall auch für eine reine Bürokiste ein lohnendes Upgrade.