13
C-WINDOWS-System32-Wbem-Repository - wofür?
Moin Kollegen.
Ich bin einem Problem auf der Spur, das vermutlich mit Datei-Korruption in diesem Verzeichn zu tun hat.
Diese Frage dient der Recherche, bitte keine allgemeinen Weisheiten mitteilen.
Ich habe mir einen Überblick verschafft, wie groß dieser Ordner ist, und auf 60 PCs variiert das von 100 MB bis zu 4 GB, wobei kein Zusammenhang zur Menge installierter Software, dem Alter des Rechners oder Nutzungsverhalten zu bestehen scheint.
Warum sind die Größen dieses Ordners so grundverschieden?
Hat sich jemand schonmal mit den Mechanismen auseinandergesetzt?
Ja, ich habe mich informiert, was das für ein Ordner ist
Ich bin einem Problem auf der Spur, das vermutlich mit Datei-Korruption in diesem Verzeichn zu tun hat.
Diese Frage dient der Recherche, bitte keine allgemeinen Weisheiten mitteilen.
Ich habe mir einen Überblick verschafft, wie groß dieser Ordner ist, und auf 60 PCs variiert das von 100 MB bis zu 4 GB, wobei kein Zusammenhang zur Menge installierter Software, dem Alter des Rechners oder Nutzungsverhalten zu bestehen scheint.
Warum sind die Größen dieses Ordners so grundverschieden?
Hat sich jemand schonmal mit den Mechanismen auseinandergesetzt?
Ja, ich habe mich informiert, was das für ein Ordner ist
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 3789524030
Url: https://administrator.de/contentid/3789524030
Printed on: April 18, 2024 at 10:04 o'clock
13 Comments
Latest comment
https://docs.ukfast.co.uk/operatingsystems/windows/commonissues/wbem.htm ....
If the directory has grown to an unreasonable size (5GB+), this can be due to a backup of the repository being taken every time the WMI repository is repaired or recreated. You will be able identify if this is the case as several folders called Repository.xxx will be present where the .xxx is the number of the backup.
If there are a number of Repository.xxx files, it is likely that there was a consistency issue detected when the repository was rebuilt, so the backup copy was not removed.
If there are a number of Repository.xxx files, it is likely that there was a consistency issue detected when the repository was rebuilt, so the backup copy was not removed.
1
Moin.
Das zu googlen gelingt mir, aber es sieht nicht so aus, als wäre das der Fall.
Nehme ich mir einen Rechner und mache so einen WBEM Repository Rebuild, so kommt man immer bei 50 MB raus, ganz gleich, welcher PC. Sprich: wenn korrupt, sollte der Rebuild nicht so unterschiedliche Auswirkungen haben
Das zu googlen gelingt mir, aber es sieht nicht so aus, als wäre das der Fall.
Nehme ich mir einen Rechner und mache so einen WBEM Repository Rebuild, so kommt man immer bei 50 MB raus, ganz gleich, welcher PC. Sprich: wenn korrupt, sollte der Rebuild nicht so unterschiedliche Auswirkungen haben
Was ist den bei dem einen Rechner so groß? Zeig doch mal (welche Dateien).
Jeder Rechner hat andere Voraussetzungen und installierte Software, Wenn da eine Software drauf installiert ist die jede Menge WMI Objekte im Repo speichert (z.B. irgendwelche Logs) oder amok läuft dann ist klar das es hier Unterschiede gibt, weil darin ja sämtliche WMI Objekte abgelegt werden.
Jeder Rechner hat andere Voraussetzungen und installierte Software, Wenn da eine Software drauf installiert ist die jede Menge WMI Objekte im Repo speichert (z.B. irgendwelche Logs) oder amok läuft dann ist klar das es hier Unterschiede gibt, weil darin ja sämtliche WMI Objekte abgelegt werden.
Hallo,
beim Rebuild passiert eigentlich auch nichts, wenn alles "glatt" durchläuft, aber wenn es zu Problemen kommt
wird die Backupkopie eben auch nicht gelöscht und dann sammelt sich da wohl mehr oder weniger so richtig
viel an Daten an.
Dobby
Edit: Cleaning the WBEM Repository wäre wohl das richtige in diesem Fall um den Speicherplatz
wieder zurückzubekommen oder die nicht benötigten Backupkopien loszuwerden.
beim Rebuild passiert eigentlich auch nichts, wenn alles "glatt" durchläuft, aber wenn es zu Problemen kommt
wird die Backupkopie eben auch nicht gelöscht und dann sammelt sich da wohl mehr oder weniger so richtig
viel an Daten an.
Dobby
Edit: Cleaning the WBEM Repository wäre wohl das richtige in diesem Fall um den Speicherplatz
wieder zurückzubekommen oder die nicht benötigten Backupkopien loszuwerden.
Was ist den bei dem einen Rechner so groß? Zeig doch mal (welche Dateien).
Bei ca. 50% der PCs sind das mehr als 3 GB, aber das spielt keine Rolle.Frage siehe oben: wer kennt sich mit den Mechanismen aus? Googlen kann ich und habe ich zur Genüge getan.
Wenn hier ein Rechner ist, der keine Software hat außert Windows selbst (benutzt nur gelegentlich den Browser) und auch nur ein Benutzer drauf, wie kann es sein, dass da mehr als 3 GB zu Stande kommen (nein, keine Repository.xxx dabei)? Deshalb frage ich nach den Mechanismen.
Aber gut, hier ein Beispiel:
dir C:\Windows\System32\wbem\Repository
Volume in Laufwerk C: hat keine Bezeichnung.
Volumeseriennummer: 2ACD-2DD9
Verzeichnis von C:\Windows\System32\wbem\Repository
15.08.2022 16:56 <DIR> .
15.08.2022 16:56 <DIR> ..
30.08.2022 11:06 1.223.802.880 INDEX.BTR
30.08.2022 10:18 11.473.084 MAPPING1.MAP
30.08.2022 10:19 11.473.084 MAPPING2.MAP
30.08.2022 11:06 11.473.084 MAPPING3.MAP
30.08.2022 11:06 2.698.870.784 OBJECTS.DATA
5 Datei(en), 3.957.092.916 Bytes
Kannst du selbst rausfinden was da bei dir so viel Speicher belegt >= wbemtest aufrufen und die Objekte in den Klassen zählen.
Ok, long story:
Alle Jubeljahre werden hier Rechner hart ausgeschaltet. Danach kommt es manchmal zu bis zu 15 MInuten Wartezeit beim nächsten Start (hängt bei "Gruppenrichtlinie wird verarbeitet", aber das spielt keine Geige, auch ohne jegliche GPOs hängt er da). Laut Leidensgenossen im Internet ist die Ursache ein langwieriger WBEM-repository Rebuild.
Ich versuche nun rauszufinden, was da so lang dauern kann, da, wie gesagt, diverse Rechner ein riesiges Repository haben, ohne überhaupt was zu machen (keine Software installiert, nix, Gastrechner für Belegdruck via Browser). Objekte zu zählen ist ja schön, aber sagt hier nichts aus, was der Lösung dient.
Alle Jubeljahre werden hier Rechner hart ausgeschaltet. Danach kommt es manchmal zu bis zu 15 MInuten Wartezeit beim nächsten Start (hängt bei "Gruppenrichtlinie wird verarbeitet", aber das spielt keine Geige, auch ohne jegliche GPOs hängt er da). Laut Leidensgenossen im Internet ist die Ursache ein langwieriger WBEM-repository Rebuild.
Ich versuche nun rauszufinden, was da so lang dauern kann, da, wie gesagt, diverse Rechner ein riesiges Repository haben, ohne überhaupt was zu machen (keine Software installiert, nix, Gastrechner für Belegdruck via Browser). Objekte zu zählen ist ja schön, aber sagt hier nichts aus, was der Lösung dient.
Moin,
hänge null komma gar nicht im dem Prozess drin, aber vielleicht hilft es dir trotzdem.
Auffallend ist ja, dass die Objects.data ziemlich groß ist.
Sucht man danach, landet man immer wieder auf Hinweise, die mit dem RSOP-Logging ud/ oder einer Vielzahl an angewandten GPOs zusammen hängen.
https://social.technet.microsoft.com/Forums/en-US/7480bb9e-808c-4529-900 ...
https://social.technet.microsoft.com/Forums/en-US/89c62043-6885-4325-9e0 ...
Auch liest man gelegentlich was im Zusammenspiel mit dem SCCM
https://www.reddit.com/r/SCCM/comments/56y7mu/comment/d8nehix/
Hoffe, das hilft dir ein wenig...
hänge null komma gar nicht im dem Prozess drin, aber vielleicht hilft es dir trotzdem.
Auffallend ist ja, dass die Objects.data ziemlich groß ist.
Sucht man danach, landet man immer wieder auf Hinweise, die mit dem RSOP-Logging ud/ oder einer Vielzahl an angewandten GPOs zusammen hängen.
https://social.technet.microsoft.com/Forums/en-US/7480bb9e-808c-4529-900 ...
https://social.technet.microsoft.com/Forums/en-US/89c62043-6885-4325-9e0 ...
Auch liest man gelegentlich was im Zusammenspiel mit dem SCCM
https://www.reddit.com/r/SCCM/comments/56y7mu/comment/d8nehix/
Hoffe, das hilft dir ein wenig...
Nein, hilft leider nicht. Wie beschrieben, auch wenn keine GPOs aktiv sind, kommt es gelegentlich zu diesem Problem.
Wenn keiner bislang in diese Materie einsteigen musste, auch gut. Ich werde es auch nicht krampfhft weiter tun - PCs werden nun wirklich selten hart ausgeschaltet.
Wenn keiner bislang in diese Materie einsteigen musste, auch gut. Ich werde es auch nicht krampfhft weiter tun - PCs werden nun wirklich selten hart ausgeschaltet.
1
Nja, wenn man die Teile hart ausschaltet wird das eher das geringste Problem sein, von defekten Dateisystemen, etc. wollen wir da ja gar nicht erst anfangen 
.
.
Ja, es ist ein Luxusproblem. hier kam nur ein Aufschrei, da sich ein Präsentationsrechner vor versammelter Mannschaft aufgehängt hatte, resettet wurde, und dann 20 Leute 15 Minuten lang zuschauen durften bei "Gruppenrichtlinie wird verarbeitet" (dabei lag es definitiv nicht an GPOs).
1
Problem bleibt bestehen.
Ausgiebige Analyse netzwerkweit ergab nichts Neues, sondern bestätigte nur:
passiert tatsächlich immer nur nach Reset/hartem Ausschalten.
Und die Dauer des Starts danach hängt wirklich von der Größe dieses Ordners ab. Spitzenwerte: etwas mehr als 4 GB und 24 Minuten Startzeit!
Zu dumm, dass man da nichts dran ändern kann.
Ausgiebige Analyse netzwerkweit ergab nichts Neues, sondern bestätigte nur:
passiert tatsächlich immer nur nach Reset/hartem Ausschalten.
Und die Dauer des Starts danach hängt wirklich von der Größe dieses Ordners ab. Spitzenwerte: etwas mehr als 4 GB und 24 Minuten Startzeit!
Zu dumm, dass man da nichts dran ändern kann.
Es wird immer besser...
Gestern hatten wir einen Stromausfall und somit sind alle Clients abgek...
Das nachfolgende Hochfahren hat bei sehr vielen 10 Minuten oder mehr gedauert wegen dieser Grütze - bei der Hälfte der PCs über 30 Minuten!
Die Dateien sind weiter gewachsen, Spitzenwert jetzt schon >7GB. Bei eben diesem PC dauerte das Hochfahren schon 1 Stunde, und das ist weiß Gott ein schneller PC.
Wir werden nächsten Monat umsteigen auf Win11, ich hoffe inständig, dass dieses Problem dann Geschichte ist.
Gestern hatten wir einen Stromausfall und somit sind alle Clients abgek...
Das nachfolgende Hochfahren hat bei sehr vielen 10 Minuten oder mehr gedauert wegen dieser Grütze - bei der Hälfte der PCs über 30 Minuten!
Die Dateien sind weiter gewachsen, Spitzenwert jetzt schon >7GB. Bei eben diesem PC dauerte das Hochfahren schon 1 Stunde, und das ist weiß Gott ein schneller PC.
Wir werden nächsten Monat umsteigen auf Win11, ich hoffe inständig, dass dieses Problem dann Geschichte ist.
