Wenn der Speicherplatz auf Laufwerk C: langsam zur Neige geht und die Datenträgerbereinigung keine Abhilfe leistet, lohnt ein Blick auf das .Net-Framework.
Genauergesagt geht es um temporäre Dateien die die Laufzeitumgebung angelegt. Bei einem Kunden gab es nach der monatlichen “Windows-Update-Kur” eines Windows Server 2012 R2 Foundation (Terra Miniserver) eine Speicherplatzwarnung. Nach einem eher ernüchternen Ergebnis nach div. Aufräumarbeiten fiel nach einem Durchlauf von TreeSize Free auf, das diverse Ordner unterhalb von “C:\Windows\assembly” relativ umfangreich sind. Hauptsächlich betraf dies
C:\Windows\assembly\NativeImages_v2.0.50727_32\Temp C:\Windows\assembly\NativeImages_v2.0.50727_64\Temp
Allen voran der “32-er” Ordner hat es insich. Nach dem Zeitstempel der dort enthaltenen Dateien zu urteilen, wurden bzw. werden Dateien bei jedem Neustart des Servers erstellt. Alleine beim letzten Neustart umfasste dies gut 3 GB, alte Dateien werden offensichtlich nicht entfernt. So sammelte sich im Laufe der Zeit einiges an.
Das Problem scheint nicht unbekannt zu sein, eine genaue Ursache konnte zumindest zeitnah nicht ermittelt werden. Um wieder Platz zu schaffen, wurden alle älteren Dateien zunächst ausgelagert, bislang viel durch diese Massnahme keine Einschränkung auf. An manchen Stellen im Netz kann man Nachlesen, dass das Löschen des gesamten Ordnerinhalts unproblematisch sei, ob dies wirklich so ist, haben wir bislang nicht getestet.
Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.
Artikel (RSS)
XING
Hi Andy,
wir haben das hier auch bei einigen PCs. Beide besagten Temp-Ordner laufen voll. Ich hatte Fälle da war einer der Ordner 40 GB groß.
Leider kann nur Treesize das zuverlässig anzeigen, im Explorer wird der Ordner irgendwie ins Gesamtkunstwerk integriert und man erhält keine “angständige” Anzeige.
Bisher haben wir die temp-Ordner immer gnadenlos gelöscht und erhielten keine Beschwerden!
Aber woher das Ganze kommt, dazu kann ich nichts finden, bzw. lässt sich kein Zusammenhang bei den Rechnern feststellen.
Wenn Du dahingehend weiter kommst, wäre es Klasse, wenn Du hier was dazu postest!
Danke und
Gruß
matt
Hi Andy, hi Matt,
mittlerweile tritt dieser Fehler auch auf Windows7 (x64)-Clients auf, nicht nur auf SBS2011-Servern.
Und zwar (fast) jedes Mal nach Installation von MS-Updates (egal, ob manuell oder automatisch), nach dem darauffolgenden Windows-Neustart.
Im Eventlog “Anwendung” finden sich dann zahlreiche Fehler 1101 (“.NET Runtime Optimization Service (clr_optimization_v4.0.30319_64) – Failed to compile: System.Workflow.ComponentModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 . Error code = 0x80070020”), die jeweils in direkter zeitlicher Verbindung mit der letzten Update-Installation stehen.
Ich habe eine Gemeinsamkeit ausmachen können: Auf jeder der betroffenen Maschinen ist G Data Antivirus Business installiert – bei Euch auch?
Auf anderen Rechner ohne G Data tritt dieses Problem nicht auf!
Viele Grüße,
Max
@ matt:
> Leider kann nur Treesize das zuverlässig anzeigen, im Explorer wird der Ordner irgendwie ins Gesamtkunstwerk integriert und man erhält keine „angständige“ Anzeige.
–> Im Netz gefunden, getestet: Ok, klappt. 🙂
c:windowsassembly
attrib -s -h -r desktop.ini
ren desktop.ini desktop.bak
–> Ordnerinhalte sind daraufhin auch im Windows-Explorer anzeigbar.
Viele Grüße,
Max
Hallo Max,
ich sehe das mittlerweile auch auf Windows 7-Computern, aber nicht auf jeder Maschine.
Das mit G Data kann ich nicht bestätigen, aber auch nicht völlig ausschließen, auch auf Systemen ohne Virenschutz oder anderen Scannern tritt es auf (soweit meine Beobachtung). Die Events habe ich bislang seltsamerweise nicht gesehen, aber guter Hinweis, muss ich mal drauf achten.
Danke für den Tipp mit der “desktop.ini”.
Hi Max,
interessant ist für mich ist die Aussage, das Ihr auch G-Data Business einsetzt, das ist bei uns auch der Fall. Allerdings haben wir hier (auf Nachfrage, wegen eines anderen aber ähnlichen Problems) jetzt eine angepasste Client-Version (14.0.1.124) bekommen.
Diese Version soll Probleme mit der nicht-interaktiven Registrierung von DLLs im GAC (Global Assembly Cache = C:Windwosassembly) beheben.
Ich erhoffe mir dadurch Verbesserung.
BTW: Bei uns sind sowohl Win10-, als auch Win7-Maschinen betroffen!
Gruß aus Oberfranken
matt
Hi matt,
ja, für mich umgekehrt auch. 🙂
Danke für Deinen guten Hinweis bezüglich G Data.
Die Vorgehensweise, eine “angepaßte” Client-Version zu erhalten, kenne ich von G Data noch aus dem Jahr 2005, als es monatelang Probleme unter (SBS-)Servern gegeben hatte. Seither lief aber alles relativ gut/ruhig.
Ich habe nachgesehen: Bei den Kunden ist logischerweise aktuell (noch) der Standard-Client installiert (Version 14.0.1.122).
Ich werde den G Data-Support gleich mal anfragen.
Deine Schilderung des Fixes klingt vielversprechend. Ich wäre sehr erleichtert, dieses lästige Problem endlich los zu sein.
Unsere Kunden sind alle noch auf Windows 7, daher habe ich mit Windows 10 in dieser Hinsicht leider keine Erfahrungswerte.
Grüße aus der Nähe von Heidelberg,
Max
Hi nochmal,
ich konnte jetzt ziemlich sicher eingrenzen, daß
a) die Probleme begonnen hatten, seitdem die Aktualisierung des G Data Business Clients von Version 13.2 auf Version 14.x erfolgt war
und
b) die massenhaft erstellten temporären Ordner (“ZAPXXXX.tmp”) unterhalb von C:WindowsassemblyNativeImages_v2.0.50727_64Temp sowei C:WindowsassemblyNativeImages_v2.0.50727_32Temp
nicht nach jedem (Server-)Neustart, sondern nur nach dem Einspielen von MS-Patches auftreten, *sofern .NET-Updates enthalten waren*
Ich warte jetzt mal die Rückmeldung von G Data ab und melde mich nochmal.
Viele Grüße,
Max
Hi zusammen,
vielen Dank für eure Schilderungen! Ich suche schon seit Langem nach der Ursache für dieses Problem.
@Max: ich kann deine Eingrenzung bestätigen, selbe Beobachtung hier. Insbesondere auf dem SBS2011 mit gravierendem Ausmaß. Ich bin gespannt, was du vom G Data Support hörst.
Viele Grüße
Dennis
Hi Dennis,
danke für Deine Rückmeldung!
Hast Du auch feststellen können, daß das Auftreten zeitlich in Verbindung mit der Client-Aktualisierung (13.x –> 14.x) stand?
Ich melde mich, sobald G Data sich rührt.
Viele Grüße,
Max
Hi Max,
ja, mir ist das nur bisher nicht aufgefallen. Aber nachdem ich deinen Kommentar gelesen hatte, wurde mir auch klar, dass das erst seit dem Update passiert.
Viele Grüße
Dennis
Hi Dennis,
cool, danke für Deine Bestätigung. 🙂
Viele Grüße,
Max
Hallo zusammen,
vor etwas mehr als einem Jahr habe ich mir eine SSD (Toshiba Q300; 120 GB) gekauft und meine HDD durch diese ersetzt.
Es fiel mir anfangs nicht so auf, aber nach und nach wurde mein Speicherplatz belegt, ohne dass ich etwas dazu beigetragen habe.
Über JDiskReport habe ich mir mal anzeigen lassen, wie mein Speicher mit was belegt ist.
Windows nimmt 87,5 GB ein, darunter assembly mit 63,3 GB, winSXS mit 13,2 GB und System32 mit 4,6 GB.
Unter assembly nehmen die NativeImages_v2.0.50727_64 46,8 GB und die NativeImages_v2.0.50727_32 16,0 GB ein.
Diese beiden Ordner enthalten wiederum fast nur Temp-Dateien.
Ich habe in den Kommentaren hier gelesen, dass auch andere dieses Problem haben.
Es wäre nett, wenn mir jemand ganz genau (für einen Laien) beschreiben könnte, was ich nun machen muss, um wieder Speicherplatz freigeben zu können (aktuell nur noch 5,8 GB), ohne Schaden anzurichten.
Vieleicht sollte ich noch erwähnen, dass ich mit Windows 7 Home Premium SP1 (64 Bit) arbeite und aktuell .NET Framework 4.6.2 (Deutsch) und 4.7 installiert habe.
Hallo Sascha,
die temporären Dateien unter den Pfaden “C:WindowsassemblyNativeImages_v2.0.50727_32Temp” und “C:WindowsassemblyNativeImages_v2.0.50727_64Temp” können, soweit bekannt ist, bedenkenlos gelöscht werden.
Interessant zu erfahren wäre noch, welcher Virenscanner eingesetzt wird? Es scheint so, als ob es unter anderem aber nicht ausschließlich mit G Data zusammenhängt.
Ich persönlich gehe davon aus, das noch andere .Net-Anwendungen (wnen nicht sogar das Framework selbst) für dieses “Vollschreiben” verantwortlich sind.
Hi,
zur Löschung der temporären Dateien: Bei den Servern hatte ich mich bisher nicht daran gewagt, da ich meinte, gelesen zu haben, daß das Probleme bergen könnte.
Bei den Clients hingegen hatte ich testweise alle temporären Ordner in einen zuvor selbst erstellten Unterordner verschoben –> bislang (bereits einige Wochen her) keine Probleme.
Der G Data-Support hingegen ist der Auffassung, man könne die temp-Ordner gefahrlos löschen.
Zu G Data:
Ich habe mittlerweile (entpackte Größe = ca. 200 MB) vom G Data-Support einen Ordner “current” erhalten. Den vorhandenen Ordner “current” auf dem (Management-)Server soll ich durch den neuen ersetzen, den Man.-Server-Dienst neu starten sowie ein Programmupdate der Clients durchführen.
Ich bin mal gespannt.
Falls es klappt, wäre ich erleichtert, aber auch verärgert, weil mich dieses Problem (unnötigerweise) viel Zeit und Nerven – sowie meine Kunden Geld – gekostet hat.
Viele Grüße,
Max
Bei den Servern hab’ ich es bislang auch so gemacht, erstmal wegkopiert und erst später (nach Tagen bzw. Wochen) gelöscht, bislang ohne Probleme. So wie sich das hier darstellt könnte zumindest G Data ein Kandidat für diese Dateien sein. Ich frage mich allerdings in Hinblick auf die Systeme, wo kein G Data drauf ist, woher dort die Dateien kommen.
Hallo Andy,
vielen Dank für Deine Hilfe.
Ja, auch ich nutze GData-Antivirus (als Bezahlversion), und das wäre wirklich ein Ding, wenn es mit dieser Software zusammenhängen würde.
Werde GData mal anschreiben und denen darüber berichten.
Bin gespannt, was sie dazu sagen.
Im Dezember 2017 läuft meine Lizenz ab.
Werde danach mal eine andere Virenschutzsoftware nutzen.
Danke nochmal:-)
Hallo Andy,
komisch ist, dass ich unter C:Windowsassembly bei mir keine NativeImages-Ordner finde.
Habe alle Dateien und Ordner einblenden lassen, und auch über die Suchfunktion
Aber JDiskReport zeigt diese beiden Ordner an.
Was mache ich nun?
Hi Sascha,
die Antwort findest Du im dritten Kommentar von oben. 🙂
Viele Grüße,
Max
Hallo Max,
tut mir leid, wenn ich rückfragen muss, aber ist der Pfad den Du da angegeben hast, individuell bei Dir oder allgemein bei Windows so?
Auch unter diesem Pfad finde ich bei mir nach assembly nichts mehr.
Oder muss ich Treesize bei mir installieren, damit die Software meinen individuellen Pfad zu diesen Verzeichnissen zeigt?
Grüße, Sascha
Hi Sascha,
sofern ich Dich richtig verstehe, werden Dir unter c:windowsassembly keine Ordner angezeigt gar keine, oder?). Das ist offenbar normal so. Um diese dennoch anzeigen zu können, kannst Du entweder so vorgehen, wie oben beschrieben (“DOS-Shell/cmd-Fenster”):
c:windowsassembly
attrib -s -h -r desktop.ini
ren desktop.ini desktop.bak
–> Ordnerinhalte sind daraufhin auch im Windows-Explorer anzeigbar.
Oder Du nutzt z. B. Windirstat portable. Nach dem Durchlauf von C: kannst Du dann per rechter Maustaste direkt in die betroffenen Ordner gelangen (“Ordner öffnen” o. ä.).
Viele Grüße,
Max
Hallo Max,
verstehe ich das also richtig, dass c:windows…… .bak ein Kommandobefehl ist und ich diesen hintereinander ohne Leerzeichen eingeben und dann abschicken muss?
Oder sind es drei Zeilen, die ich immer einzeln als Befehl eingeben und nach jeder abschicken muss.
Ich frage deshalb, weil Du von c: bis .bak nicht durchgängig geschrieben, sondern das auf drei Zeilen gelegt hast.
Als Laie brauche ich wirklich nur eindeutige Hinweise, weil ich das, was für andere vielleicht selbstverständlich ist, selbst nicht deuten kann.
Grüße, Sascha
Hi Sascha,
Du schriebst oben:
“Es wäre nett, wenn mir jemand ganz genau (für einen Laien) beschreiben könnte, was ich nun machen muss, um wieder Speicherplatz freigeben zu können (aktuell nur noch 5,8 GB), ohne Schaden anzurichten”
Da die Ursache bei Dir bisher noch gar nicht klar ist, ist es mit der Löschung der temporären Dateien (ggf. nicht völlig ungefährlich) ja noch nicht getan.
Ich würde Dir (aufgrund Deines von Dir angegebenen Kenntnistandes) daher gerne empfehlen, am besten mal einen Profi drüber schauen zu lassen, also den IT-Service-Dienstleister Deines Vertrauens. 🙂
Ich muß mich an dieser Stelle leider ausklinken.
Viele Grüße,
Max
PS: Ich bin hier – wie Du – nur “Gastkommentator”. 🙂
Oha.. ich klinke mich hier mal ein..
server 2012 R2 auch gdata auch 14.0.1.122 drauf.
Auch ein riesiges assembly verzeichnis (50GB).
Ich bekomme aber den 124 als update nicht?
@Sascha, das mit der desktop.ini macht nur folgendes.
Die Datei steuert was du im explorer siehst. Sie selbst ist aber vesteckt und schreibgeschützt. Das musst du mit dem attrib Befehl aufheben (sozusagen ins blinde hinein).
Dann benennst du die Datei um damit sie nicht mehr die Blockade reinhaut wenn du mit dem Explorerer in das Verzeichnis reinbrowst.
Das hat mit dem eigendlichen Problem nichts zu tun und ist ungefährlich.
Gruß
Manuel
@Manuel:
Hallo Manuel,
vielen Dank für Deinen Hinweis hier, aber leider weiß ich immer noch nicht, wie genau ich diese Befehle als Kommandos eingeben muss.
Davon mal abgesehen, sehe ich die relevanten Ordner bei JDiskReport, nachdem der Suchlauf abgeschlossen ist.
Unter assembly sehe ich im Baum die beiden Ordner, deren Namen fett geschrieben sind.
Klicke ich einen Ordner an, öffnet sich ein Ordner-Baum nach unten, mit Temp (fett geschrieben) als Unterordner ganz oben.
Klicke ich auf Temp, öffnet sich wieder ein Ordner-Baum nach unten mit sehr vielen Temp-Ordnern.
Wenn ich jetzt Temp mit links anklicke und markiere, dann zeigt mir ein Diagramm 48,4 GB an, klicke ich Temp dann mit rechts an und wähle “Open Explorer”, dann habe ich ganz oben den Ordner “Benutzerdefinierte Office-Vorlagen” und darunter ganz viele Registrierungseinträge (?).
Leider gibt es hier keinen einfachen Löschbefehl, der alles mit einmal sofort löscht.
Ich vermute mal, ich muss qasi jeden einzelnen Unterordner von Temp mit “Open Explorer” öffnen und alles manuell löschen.
Kürzlich habe ich als Windows-Aktualisierung die Vorschau auf das Qualitätsrollup für .NET Framework …. herunterladen und installieren lassen, und schwuppdiwupp waren wieder 2 GB passé.
Dieser ganze Scheiß kotzt mich regelrecht an, was man da wieder an Zeit und Arbeit aufbringen muss.
Hast Du für Dich schon eine Lösung gefunden?
Grüße, Sascha
Hi Sascha, ich versuche nochmal alle Schritte zusammenzufassen die du durchführen musst
1. Start -> ausführen -> cmd (oder einfach eine “Eingabeaufforderung” öffnen. Das findest du auf jeden Fall in deinem Startmenü. Also eine Dos Box.
2. Du stehst wahrscheinlich im ORdner C:usersdeinusername
Dann jetzt diese Befehle nacheinander ausführen.
cd
cd windows
cd assembly
attrib -s -h -r desktop.ini
ren desktop.ini desktop.bak
Danach mit dem Explorer in das Verzichnis C:windowsassembly browsen (nicht der internet explorer, sonder der Datei browser.. 🙂 ).
Bei mir war es dann das Verzeichnis:
C:WindowsassemblyNativeImages_v2.0.50727_32Temp
das ganz viele .zap dateien enthielt. Die kann man löschen!
Btw. ich habe vom GData Support jetzt bestätigt bekommen, dass das am client liegt und auch die .124 zum download bekommen (wir sind Firmenkunde).
Gruß
Manuel
Hi Manuel,
super, vielen Dank für diese detaillierte Aufführung.
Ich werde das gleich morgen ausprobieren; bin heute geschafft von der Arbeit.
Also ist doch GData bzw. deren Client schuld.
Das scheint sich mit dieser Software aber nur auf SSD’s so auszuwirken. Oder?
Auf meiner HDD (500 GB) lief auch GData Antivirus, und es gab da keine solchen Probleme.
Kannst Du mir bitte noch kurz erläutern, was die .124 ist?
Behebt dieses Update den Fehler?
Bekommt man das nicht automatisch mit den Programmupdates?
Kann ich irgendwo sehen, ob ich dieses .124-Update habe oder ist das ein spezielles Update, was es nur auf Anfrage gibt?
Grüße, Sascha
Hi Sascha, gdata rückt das client Update mit der version .124 nur auf Anfrage raus, und verteilt es nicht an alle Kunden.
Wenn gdata bei dir die Ursache ist, dann sollte es das Problem lösen.
Gruß Manuel
Hi Manuel,
kannst Du mir bitte noch mitteilen, wie ich herausfinden kann, ob mein GData Antivirus (Version 25.3.0.1) diese Probleme verursacht.
Wie bist Du bei Dir drauf gekommen?
Falls ich mich dafür an GData wenden muss:
Was teile ich denen mit (z.B. Stichworte wie assembly, SSD o.ä.)?
Grüße, Sascha
Hi zusammen,
kleiner Zwischenbericht nach ca. 3 Wochen. Hier läuft nun G Data 14.0.1.124 (23.03.2017) und das Problem ist nicht erneut aufgetreten.
Das kann jetzt heißen, das keine großen Windows-Updates mehr herausgekommen sind seitdem, oder das es wirklich der G Data war.
Hoffe das hilft so manchem Suchenden¿
Gruß
matt
@Matt:
Hi Matt,
kannst Du mir vielleicht kurz schildern, wie man GData als Übeltäter feststellt?
Habe GData Antivirus (Version 25.3.0.1).
Muss ich mich an deren Support wenden?
Wenn ja, was dann schreiben?
Grüße, Sascha
Hi,
habe mich mit dem G-Data Support in verbindung gesetzt und habe das Update bekommen. Ich habe es auch schon auf allen Server Inklusive Clients aktuallisiert. der Server (wo es am Wichtigstens ist) wurde auch schon mal neugestartet. Leider hat sich der Speicherplatz nicht verändert. Habe ich etwas vergessen?
Gruß Sebastian
P.s. @Sascha
Ich habe einfach beim G-Data Bussines Support angerufen und habe ihnen geschildert das der assambly Ordner sehr groß ist. Die wussten gleich bescheid und habe mir das Update zukommen lassen.
G Data alleine scheint nicht die Ursache zu sein oder zumindest nicht immer.
Ich war vorhin bei einem Kunden und habe zur Sicherheit die “assemply”-Ordner geprüft, dort sind alle nur um die 1-2 GB groß (trotz G Data).
Hallo Andy,
laut G-Data kommt es auf die Konstallation von G-Data, Betriebssystem und dot Net Version an. Es hat auch nicht jeder Server von uns das Problem.
@Sebastian, die zap* Ordner im Temp Verzeichnis musst du von Hand löschen.
Also unter
C Windows Assembly nativeimages Temp.
Siehe ein paar Posts weiter oben.
Das passiert nicht automatisch.
Gruß Manuel
@Sebastian
Bleibt die Frage, was die Ursache auf den Systemen (ganz gleich ob Client oder Server) ist, wo kein G Data installiert ist.
Hi Sascha,
das es sich um GData als Übeltäter handelt, war zunächst geraten, nachdem hier einige meinten, das Sie das gleiche Problem haben und auch GData einsetzen.
Ich ließ mir vom GData Premium Support ein Update zukommen lassen, nachdem wir ein ähnliches Problem hatten, das sich 100%ig auf GData zurückführen ließ. (Konkret ging es darum, das sich DLLs nicht mehr automatisch registrieren ließen, was ein Update unserer Software-Verteilung verhindert hat).
Die Diskussion um den Assembly-Cache (C:Windowsassemly) hier, ist älter und in unserem Netzwerk trat das Problem nun seit dem Update von GData nicht mehr auf.
Die Version, die Du erwähnst lässt mich aber darauf schließen, daß Du nicht das Business Produkt von GData verwendest, sondern die Home Version.
Blöd: Die Antwort hab’ ich heute Morgen angefangen und jetzt grad gemerkt, das ich nicht auf abschicken geklickt hab 😉
Mittlerweile gibt es wohl schon mehrere neue Antworten. Sorry dafür!
@Sebastian
Wenn ein System die gleichen Symptome zeigt, obwohl kein GData installiert ist, würde ich drauf tippen, das auch ein Mechanismus (AV-Software, GroupPolicy, Berechtigung auf den Ordner, …… ) verhindert, das DLLs bei der Installation eines Patches ordentlich registriert werden.
@Sebastian
> laut G-Data kommt es auf die Konstallation
> von G-Data, Betriebssystem und dot Net Version an.
Interessante Aussage, danke.
Bei uns sind momentan tatsächlich weiterhin nur Kundenserver und -PCs betroffen, auf denen G Data Business installiert ist.
@ matt:
> Das kann jetzt heißen, das keine großen
> Windows-Updates mehr herausgekommen
> sind seitdem, oder das es wirklich der G Data war.
Möglicherweise (hoffentlich) beides. 😉
Auch auf den bisher betroffenen Geräten mit – noch –
“altem” G Data 14-Client war es durch die letzten MS-Updates nicht zu erneuter Speicherplatzbelegung durch ZAPXXXX.tmp-Dateien gekommen.
> Wenn ein System die gleichen Symptome zeigt,
> obwohl kein GData installiert ist, würde ich drauf
> tippen, das auch ein Mechanismus (AV-Software,
G Data nutzt ja unter der Haube u. a. “Bitdefender”, könnte also u. U. mit deren Engine/Signaturen zusammenhängen. Ich meine mich zu erinnern, daß auch andere AV-Produkte (Bullguard?) die selbe Engine nutzen.
Viele Grüße,
Max
Hallo miteinander,
ich habe die Diskussion aufmerksam verfolgt, da ich auch betroffen bin.
Wir setzen in unserem Netz GData Business ein; der Client hat die Version 14.0.1.122.
Wir haben festgestellt, dass nur auf Rechner mit Windows 7 der Ordner assembly aufgebläht wird; Maschinen mit 8.1 / Server 2012 sind davon nicht betroffen.
Ich habe den GData Support angeschrieben und um Überlassung des Patches gebeten. Sobald ich ihn habe und er ist eingespielt, gebe ich eine Rückmeldung.
Schöne Grüße
Habe bei einem unserer Kunden die gleichen Symptome mit den angewachsenen Temp-Verzeichnisse unter C:WindowsAssemblyNativeImages_2.0.50727_32 und _64. Es kommt bei Kunden auf die GData Total Security zum Einsatz. Laut GData Support sollte es bei der aktuellen Consumer Versionen die Problematik nicht mehr geben. Sie räumten jedoch ein, dass ältere Versionen diese durchaus haben verursachen können.
Heißt wir müssen die Temp-Daten händisch löschen und stichprobenartig den Zuwachs beobachtem.
LG
Hallo miteinander,
sorry, ich wollte mich früher melden.
Der GData Support hat sich noch am gleichen Tag telefonisch gemeldet. Die nette Dame bestätigte, was mein Vorredner schriebt: die Dateien in den betroffenen Ordner müssen händisch gelöscht werden. Aber nur die Dateien im Unterordner “Temp”!
Auch habe ich einen Link zum Download der Version 14.0.1.124 erhalten (es handelt sich lediglich um ein Archiv, dessen Inhalt – ein Ordner namens “Current” – bei ausgeschaltetem Dienst “G DATA ManagementServer” in den Ordner “C:ProgramDataG DataAntiVirus ManagementServerUpdatesCLIENT” kopiert werden muss. Der Rest erledigt sich von allein.
Schöne Grüße
Leute………..ich hatte das selbe Problem wie Ihr. Kann aber zumindest jetzt die Vermüllung der assembly verhindern und bereinigen. Funktioniert so:
Mit dem kostenlosen CCEnhancer erweitern Ihr den Funktionsumfang des beliebten Cleaning-Tools CCleaner.
Aktiviere dann nach der Installation im CCLeaner unter Anwendungen – Windows – das Kästchen “.Net FRAMEWORK Temps*
Dann bereinigt der ccleaner bei jedem Arbeitsgang die „C:Windowsassembly“ automatisch und die Vermüllung der assembly. Das hift zwar nicht gegen das Problem selbst, hält aber den Rechner sauber. Ich denke, immerhin besser als nix.
So long
@Soundpatrol:
Danke für Deinen super Hinweis.
Das ist wirklich sehr einfach und wesentlich komfortabler, als die anderen Vorschläge hier, zumindest für einen Laien.
Was mache ich mit der Datei „cc_config.ini“, die ich noch auf dem Desktop habe.
Diese Datei ist bestimmt wichtig.
G, Sascha
ganz ehrlich…………ich habe keine Ahnung. Habe hierzu nur das hier gefunden
https://helpdeskgeek.com/windows-xp-tips/add-support-for-hundreds-of-new-programs-in-ccleaner/
Ich habe mich mit “Try and error” an das Problem ran gefummelt und mich sehr geärgert das mein System vollläuft. Dabei habe ich euren Blog entdeckt und gesehen, das ihr die einzigen wart die sich ernsthaft mit dem Problem auseinander gesetzt haben. Daher habe ich mir erlaubt euch mein Ergebnis mit zu teilen. Aber das ungefragt meine SSD Platte voll läuft ärgert mich immer noch.
Liebe Grüße
Zumindest ich würde von einem Einsatz des ccleaner auf einem Server eher abraten, zumal es ja eben keine Problemlösung ist.
Ich hab mir unsere NativeImagestemp Ordner mal angesehen. Mich deucht es betrifft nicht alle MS-Updates sondern nur die des .NET Framework. Sieht so aus als würde er immer und immer wieder das gleiche halbe Dutzend Dateien erstellen.
Zum Problem des Löschens der Temp – Dateien. Keine großen Kunstgriffe notwendig:
Taste WIN + R -> Pfad eingeben
C:windowsassemblyNativeImages_v2.0.50727_32Temp
bzw. ….. _64Temp
und dann den ganzen Datenmüll einfach mit ENTF in den “Papierkorb”, der das natürlich nicht aufnehmen wird.
Das hat bei mir funktioniert und ich bin 75 sinnlose GB los.
Ich hoffe, etwas geholfen zu haben.
Thomas
Hallo zusammen,
bin heute auf diesen Beitrag gestossen. Mein Kunde hat auch G-Data im Einsatz und die aktuelle Version 25.X ist drauf. Das Problem mit dem assembly Ordner ist immer noch da. Habe bei G-Data angerufen, Support hat gemeint, dass das Problem seit langem nicht mehr besteht. Was ich nicht annehmen kann. Auf einer Windows 7 x64bit Machine hat es fast 230GB an TEMP-Dateien geschrieben. Ist nicht so aufgefallen, da der Kunde 1 TB Festplatte hat. Sein Kollege allerdings 2 Partitionen, C war ca. 250 GB und es wurde fast mit 170GB von G-Data zugemüllt.
Die Dateien konnte ich ganz einfach aus dem TreeSize rauslöschen und musste keinen CCleaner installieren.
Herzliche Grüße
Julia
Hallo Julia,
ich vermute ebenfalls das dieses Problem noch nicht ganz ausgemerzt ist, da es uns immer mal wieder unter die Augen kommt. Da wir bei unseren Geschäftskunden i.d.R. die Systeme im Monitoring haben, bekommen wir mit, wenn’s auf der Platte eng wird. Man könnte zudem gezielt auf die Größe der entsprechenden Ordner prüfen und autom. Gegenmaßnahmen einleiten.
Ob G Data alleine und/oder ggf. andere Konstellationen mitmischen konnte ich bislang nicht klären.
Zumindest bei den Kunden die von G Data weg sind kam es dazu nicht mehr.
Hallo Andy,
ich habe es mit den Windows 7 Installationen verglichen, welche keine G-Data als Antivirus haben und dort war das Verzeichnis ganz normal. Habe am letzten Freitag mit einem Partner gesprochen, er hatte viele Jahre mit G-Data gearbeitet und das Problem auch bestätigt.
Naja, es ist immer gut, wenn man weiß, wie man sich helfen kann.
Vielen Dank für den ausführlichen Beitrag. Hat mir sehr geholfen. Das liebe ich an den IT Leuten, dass es viel mehr kooperiert statt konkurriert wird.