HyperMemory frisst Speicher

Thomas Weller | 6. Juni 2010

Situation

Ein PC wurde aufgrund mehrerer speicherintensiver Anwendungen auf 4 GB aufgerüstet.

Problem

Windows 7 zeigt zwar 4 GB Gesamtspeicher an, gibt jedoch gleichzeitig an, dass nur 2,75 GB nutzbar sind.

Lösung

Die Ursache für das Problem war eine Grafikkarte mit Radeon 4350 Chipsatz und 512 MB RAM. Zusätzlich zu ihrem eigenen Speicher belegte sie noch 1151 MB “Shared Memory”. Dieses “Feature” nennt sich bei ATI HyperMemory. Eine Einstellmöglichkeit zum Deaktivieren gibt es leider nicht.

In diversen Foren wird das ATI Tray Tool (ATT) empfohlen. Dort gibt es eine Option namens “Enable ATT Shared Memory”. Leider brachte dies keine Änderung, auch nicht nach einem Neustart. Ebenfalls in den Foren wird diskutiert, dass bei einem 32-bit System ohnehin nicht mehr als 2 GB pro Programm genutzt werden können, womit 2,75 GB angeblich mehr als genug sind. Sofern man jedoch mehrere Programme gleichzeitig nutzt, können problemlos mehr als 2 GB belegt werden.

Ein letzter Hinweis ließ zu hoffen übrig: angeblich belegt die Grafikkarte den Speicher nur, wenn er nicht anderweitig benötigt wird. Dafür spricht, dass im ATI Tray Tool eine Zeit angegeben werden kann (Standard: 2 Sekunden). Unser Test ergab: selbst wenn Windows schon bemängelt, dass der Computer wenig Speicher zur Verfügung hat, wird das HyperMemory nicht freigegeben.

Überprüft haben wir dies mit 6 gleichzeitig laufenden Programmen, die jeweils 1700 MB Speicher anforderten. Beim Start des sechsten Programms meldete Windows “Low on memory”. Dass es überhaupt soweit kommt (belegt sind dann ja 10,2 GB) liegt daran, dass Windows die Auslagerungsdatei nutzt.

Außer dem Austausch der Grafikkarte sahen wir keine Möglichkeit, den vollen Speicher zur Verfügung zu bekommen.

Speicherverbrauch analysieren

Thomas Weller | 15. November 2009

Situation

In ihrem Blogeintrag Show me the memory beschreibt Tess Ferrandez, wie man an die Details des Speicherverbrauchs visuell darstellen kann. Dazu stellt sie ein Programm zum Download, welches die Visualisierung gleich vornimmt.

Problem

Ist der Speicherverbrauch jedoch sehr hoch (Prozessgröße > 1500 MB) oder stark fragmentiert, so versagt die beschriebene Methode, da die Ausgabe nicht mehr in das Ausgabefenster von WinDbg passt.

Lösung

In diesem Fall greift man auf eine Logdatei zurück. Das Log wird vor dem !address Befehl geöffnet und danach wieder geschlossen. Gleiches funktioniert natürlich für den Managed Heap.
.logopen c:\dump\address.log; !address; .logclose
.logopen c:\dump\eeheap.log; !eeheap -gc; .logclose

Links

Microsoft WinDbg Download (rev. 2009-11-15)

Blog von Tess Ferrandez (rev. 2009-11-15)

Symantec deaktivieren

Thomas Weller | 3. Oktober 2009

Situation

Der Kunde benutzt ein älteres System auf dem bereits viele Programme installiert sind. In letzter Zeit treten immer wieder seltsame Phänomene auf, die sich scheinbar nicht erklären lassen, dann aber auch wieder verschwinden.

Problem

Jetzt trat reproduzierbar Start ein Fehler mit dem Symantec Live-Update auf. Da das Live-Update (SESCLU.exe) immer wieder neu gestartet wurde, stürzte es genauso oft wieder ab. Das bremste das System dermaßen aus, dass ein Arbeiten nicht mehr möglich war. Lediglich auf der Kommandozeile konnten noch einige Befehle abgesetzt werden. So war ich also gefragt, die Symantec Dienste per Kommandozeile zu beenden und für den nächsten Start zu deaktivieren.

Lösung

Eine Liste der Services und deren Namen kann mit

sc query > servicenames.txt

in eine Textdatei geschrieben werden. Dort finden sich dann auch die Namen der Services von Symantec. Folgende Batch-Datei habe ich dann erstellt. Sie versucht, die laufenden Services zu beenden und dann den automatischen Start zu unterbinden.

sc stop ccEvtMgr
sc stop ccSetMgr
sc stop SmcService
sc stop "Symantec AntiVirus"
sc config ccEvtMgr start= disabled
sc config ccSetMgr start= disabled
sc config SmcService start= disabled
sc config "Symantec AntiVirus" start= disabled

Das brachte zumindest den Erfolg, dass der PC wieder bedienbar wurde. Allerdings stürzten auch andere Programme ab. Das war um so häufiger der Fall, je mehr Programme aktiv waren. Mit memtest86 war der Fehler dann im Arbeitsspeicher zu finden.

Links

Memtest86 (rev. 2009-10-03)