Gedächtniserschöpfung mit scheinbar keinem Prozess, der es erschöpft

574
Áxel Costas Pena

Ich leide fast alle drei Tage unter einem Windows 10-Computer, ohne dass ein Muster reproduziert werden muss (manchmal, nachdem der PC tagelang eingeschaltet wurde, manchmal kurz nach dem Einschalten, manchmal unter normalem Gebrauch, manchmal unter starker Last, manchmal ruhig. ..). Die Symptome sind unverkennbar: Der Videotreiber stürzt ab und die Auflösung wird auf ein Minimum reduziert. Dann werden manchmal Prozesse wie Firefox oder Chrom geschlossen ...

In diesem Fall scheint der RAM-Verbrauch der Prozesse unter Task admin normal zu sein. Unter Systemereignissen kann ich immer ein Memory Exhaustion DetectorEreignis sehen, das den Absturz nicht zu erklären scheint, da die Auslagerungsdatei immer sehr groß ist und explodiert, aber es zeigt auch keinen Prozess, der diesen Speicher belegt.

Gibt es eine vernünftige Erklärung? Kann ich den Protokolleintrag nicht interpretieren?

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Microsoft-Windows-Resource-Exhaustion-Detector" Guid=""/> <EventID>2004</EventID> <Version>0</Version> <Level>3</Level> <Task>3</Task> <Opcode>33</Opcode> <Keywords>0x8000000020000000</Keywords> <TimeCreated SystemTime="2018-07-27T05:52:49.650494000Z"/> <EventRecordID>4397</EventRecordID> <Correlation ActivityID=""/> <Execution ProcessID="8852" ThreadID="2772"/> <Channel>System</Channel> <Computer>DESKTOP-2VIMT0M</Computer> <Security UserID="S-1-5-18"/> </System> <UserData> <MemoryExhaustionInfo xmlns="http://www.microsoft.com/Windows/Resource/Exhaustion/Detector/Events"> <SystemInfo> <SystemCommitLimit>25643593728</SystemCommitLimit> <SystemCommitCharge>25574793216</SystemCommitCharge> <ProcessCommitCharge>1946886144</ProcessCommitCharge> <PagedPoolUsage>334127104</PagedPoolUsage> <PhysicalMemorySize>6316240896</PhysicalMemorySize> <PhysicalMemoryUsage>2814005248</PhysicalMemoryUsage> <NonPagedPoolUsage>381517824</NonPagedPoolUsage> <Processes>146</Processes> </SystemInfo> <PagedPoolInfo> <Tag_1> <Name>MmSt</Name> <PoolUsed>91655968</PoolUsed> </Tag_1> <Tag_2> <Name>Sect</Name> <PoolUsed>42178128</PoolUsed> </Tag_2> <Tag_3> <Name>MmRe</Name> <PoolUsed>29752368</PoolUsed> </Tag_3> </PagedPoolInfo> <NonPagedPoolInfo> <Tag_1> <Name>smCB</Name> <PoolUsed>66957312</PoolUsed> </Tag_1> <Tag_2> <Name>MmCa</Name> <PoolUsed>65829520</PoolUsed> </Tag_2> <Tag_3> <Name>smNp</Name> <PoolUsed>55021568</PoolUsed> </Tag_3> </NonPagedPoolInfo> <ProcessInfo> <Process_1> <Name>MsMpEng.exe</Name> <ID>3776</ID> <CreationTime>2018-07-26T06:02:05.521842000Z</CreationTime> <CommitCharge>152260608</CommitCharge> <HandleCount>789</HandleCount> <Version>0.0.0.0</Version> <TypeInfo>65</TypeInfo> </Process_1> <Process_2> <Name>chrome.exe</Name> <ID>3204</ID> <CreationTime>2018-07-26T14:04:58.020386800Z</CreationTime> <CommitCharge>138813440</CommitCharge> <HandleCount>1600</HandleCount> <Version>67.0.3396.99</Version> <TypeInfo>202</TypeInfo> </Process_2> <Process_3> <Name>chrome.exe</Name> <ID>4440</ID> <CreationTime>2018-07-26T14:04:58.202091700Z</CreationTime> <CommitCharge>108515328</CommitCharge> <HandleCount>460</HandleCount> <Version>67.0.3396.99</Version> <TypeInfo>211</TypeInfo> </Process_3> <Process_4> <Name>architect.exe</Name> <ID>6304</ID> <CreationTime>2018-07-26T07:55:20.567701400Z</CreationTime> <CommitCharge>102588416</CommitCharge> <HandleCount>768</HandleCount> <Version>5.0.28.34044</Version> <TypeInfo>152</TypeInfo> </Process_4> <Process_5> <Name/> <ID>0</ID> <CreationTime>1601-01-01T00:00:00.000000000Z</CreationTime> <CommitCharge>0</CommitCharge> <HandleCount>0</HandleCount> <Version>0.0.0.0</Version> <TypeInfo>0</TypeInfo> </Process_5> <Process_6> <Name/> <ID>0</ID> <CreationTime>1601-01-01T00:00:00.000000000Z</CreationTime> <CommitCharge>0</CommitCharge> <HandleCount>0</HandleCount> <Version>0.0.0.0</Version> <TypeInfo>0</TypeInfo> </Process_6> </ProcessInfo> <ExhaustionEventInfo> <Time>2018-07-27T05:52:48.613055400Z</Time> </ExhaustionEventInfo> </MemoryExhaustionInfo> </UserData> </Event> 
0
Wir stehen vor ähnlichen Problemen. Haben Sie eine Lösung für Ihr Problem gefunden? Das Problem bei diesem Bericht ist, dass er eine Liste mit Prozessen enthält, die Speicher benötigen, jedoch nicht die anderen Teile des Betriebssystems, die Speicher verwenden. -> ProcessCommitCharge ist viel kleiner als SystemCommitCharge. Sie können einen Versuch mit Rammap (https://docs.microsoft.com/de-de/sysinternals/downloads/rammap) versuchen, um den Täter zu identifizieren. Auch mit diesem Tool haben wir noch keine Erklärung gefunden, warum wir mit diesem Problem konfrontiert sind Bre vor 6 Jahren 0
Noch nicht, es ist schwer, da es manchmal täglich passiert und dann für Wochen nicht mehr passiert. Ich habe die Mitarbeiter angewiesen, den Prozess-Explorer von Sysinternal zu öffnen, sobald das Problem auftritt, nach PF- und PF-Delta zu sortieren und Fotos zu machen, da jeder Prozess, der dies verursacht, eine sehr hohe PF-Rate haben muss. Áxel Costas Pena vor 6 Jahren 0

0 Antworten auf die Frage