Mit den Tags LHAN und YHAN Speicherleck finden

546
ner0

Ich habe vor kurzem Probleme mit einem System mit Windows Server 2012 R2 und scheint einen Speicherverlust zu haben. Der nicht ausgelagerte Speicher erreicht innerhalb von 12 Stunden 8,9 GB von insgesamt 10 GB.

Dies ist etwas, woran ich noch nie gedacht habe, aber ich schien ziemlich unkompliziert zu sein, bis ich die Tags identifiziert habe, die meiner Meinung nach hinter dem Leck stecken. Das Problem ist, dass ich die Tags nicht mit irgendetwas verknüpfen kann, das ich kenne oder von Google angezeigt wird. Daher bin ich nicht sicher, welche Schritte von hier aus zu unternehmen sind.

Da die Probleme erst vor kurzem angefangen haben, denke ich an einige Schuldige:

  1. Das Gastbetriebssystem ist eine VM, die auf einem ESXi-Host ausgeführt wird. Der Host wurde vor etwa einer Woche auf ESXi v6.7 aktualisiert (VMware-Tools wurden ebenfalls aktualisiert), auch wenn das Problem erst vor zwei Tagen begann.
  2. Auf dem Betriebssystem ist Panda Adaptive Defense 360 ​​installiert. Diese wurde vor zwei oder drei Wochen installiert. Möglicherweise ist jedoch ein Update installiert worden, das möglicherweise zu Problemen führt.
  3. Das letzte Windows-Update wurde vor 3 Tagen installiert. Dies ist das, von dem ich glaube, dass es am wenigsten zu glauben scheint, aber wir wissen es nie.

Ich werde weiter schleifen, aber in der Zwischenzeit wäre jede Hilfe dankbar.

Übrigens, hier ein paar Screenshots:

UPDATE1: Nach dem Neustart des Tags verschwand YHAN, während der LHAN-Tag nur noch 259 KB belegt. Ich werde ein Auge auf Poolmon und vielleicht Windows Performance Recorder werfen. Dennoch ist jede Theorie willkommen.

UPDATE2: Mit dem hilfreichen Vorschlag aus HelpingHands Kommentar versuchte ich, nach den Zeichenfolgen "LHAN" und "YHAN" in allen Dateien im Ordner " System32 \ drivers " zu suchen . Zu meiner Überraschung enthielt eine Datei beide Zeichenfolgen: NNSNAHSL.sys:

File description: Network Activity Hook Server LWF File version: 6.0.0.68 Product name: Nano Network Security Product version: 4.2.0.404 Legal copyright: © Panda 2017 Original filename: NNSNAHSL.SYS

Der einzige Grund, warum ich den Vorschlag von HelpingHand nicht (noch) als Antwort stelle, ist, dass ich immer noch nicht sicher bin, wie mein Leck gelaufen ist, und daher vorerst keine weiteren Tests durchführen kann. LHAN ist immer noch das einzige der beiden Tags, das in der Poolüberwachung angezeigt wird, und behält die Zuweisungsgröße bei 259 KB.

ANTWORT: Da diese Frage als Duplikat markiert wurde und die Besonderheiten der Frage und Antwort ignoriert wurde, lasse ich die Antwort hier im Hauptteil der Frage:

** Nach dem Aufspüren des potenziellen Treibers (NNSNAHSL.SYS) habe ich versucht herauszufinden, wann das Leck ausgelöst wurde und warum, um die Situation zu analysieren und zu beheben, anstatt einfach davon auszugehen, dass es sich um diesen oder diesen Treiber handeln muss, aber nicht sicher ist, ob es der Fall ist war und wie es leckte. Es stellte sich heraus, dass das Durchsickern bei jeder Netzwerkkommunikation begann und viel auffälliger war. Das Kopieren einer großen Datei (~ 3 GB) über das Netzwerk würde die nicht ausgelagerte Speicherzuordnung sofort in die Höhe treiben. Nach einigem Ausprobieren stellte ich fest, dass das Problem durch einen Konflikt zwischen dem WinPcap- Treiber und dem PAK- Netzwerkaktivitäts-Hook-Server LWF verursacht wurdeTreiber. Das Problem trat gelegentlich auf, da ich XArp verwendete, das kontinuierlich Daten mit WinPcap sammelt. Wenn Sie eine der beiden Funktionen deaktivieren, wird das Problem vollständig gelöst. Der Grund, warum ich denke, dass diese Frage und Antwort als einzigartig gelten, liegt in der Besonderheit des Problems und der Tags. Obwohl ich damit einverstanden bin, dass die verknüpfte Windows 10- Frage / Antwort mit hohem Speicherverbrauch (unbekannter Grund) generell viel aussagekräftiger ist. **

Poolmon

RamMap

0
Ich würde vorschlagen, nach allen Dateien in% SystemRoot% \ System32 \ drivers für die Zeichenfolgen zu suchen. ZB würde ich Strings herunterladen - https://docs.microsoft.com/en-us/sysinternals/downloads/strings und vielleicht den Pfad hinzufügen. Führen Sie dann Folgendes aus: `strings.exe * | findstr LHAN` und `strings.exe * | findstr YHAN` Running Process Explorer und der Systemprozess nach geladenen Modulen zeigt Ihnen alle Treiber und Pfade, in denen gesucht werden soll. Dies hilft auch: https://channel9.msdn.com/Shows/Defrag-Tools/ Defragmentools-48-WPT-Speicheranalyse-Pool HelpingHand vor 6 Jahren 1
Was genau ist deine Frage? Wenn Sie Ihr Problem gelöst haben, sollten Sie eine Antwort übermitteln, anstatt Ihre Frage zu bearbeiten, und die Frage auf ihre vorherige Version zurücksetzen. Ramhound vor 6 Jahren 0
@Ramhound Die Frage steht noch immer: Wie finde ich den Ursprung der unbekannten Tags, um einen Speicherverlust zu stoppen? Bei der Überarbeitung meiner Frage handelt es sich lediglich um ein Update des Status der Tags im Pool nach einem Neustart. Ich musste den Server heute morgen und am späten Nachmittag erneut zwangsweise neu starten, vermutlich wegen des gleichen Problems (ich gehe davon aus, dass er im Moring fast nicht reagiert hat). Daher habe ich das Problem nicht gelöst. ner0 vor 6 Jahren 0
Es scheint, dass Ihr Speicherverlust in Ihrer Sicherheitssoftware enthalten war (Panda AV, nehme ich an) Ramhound vor 6 Jahren 0
@ ner0, Glückwunsch zum Lösen dieses Problems. Nach meiner Lektüre der doppelten Situation ist Ihr Fall ein konkretes Beispiel für etwas, das allgemein in einer Antwort auf die andere Frage behandelt wird. Es gibt Unmengen von Treibern, die auslaufen könnten oder bekannt waren. Der effektivste Ansatz, um Lesern zu helfen, ist ein allgemeiner Rat, wie das auf dem Computer eines Lesers zu lösen ist. Ähnlich wie die Website mit Malware-Fragen umgeht (zu viele Beispiele und begrenzte, ähnliche Lösungen). Ich stimme dafür, dass dies ein Duplikat bleibt, aber ich bin gerne bereit, es erneut zu überdenken, wenn Sie den Fall für die Wiedereröffnung klären können. fixer1234 vor 6 Jahren 0
@ fixer1234 Ehrlich gesagt stimme ich der Entscheidung, diese Frage als Duplikat zu klassifizieren, voll und ganz zu. Es ist viel zu spezifisch und die Realität ist, dass es nicht Menschen hilft, die keinen sehr ähnlichen Konflikt haben. Es ist schön, dass Sie jetzt das Netz nach _LHAN_ oder _YHAN_ durchsuchen können und nicht auf Ergebnisse beschränkt sein müssen, die nichts mit der IT zu tun haben. ner0 vor 6 Jahren 0
Hierbei handelt es sich um ein Duplikat, bei dem beide Fragen betreffen, wie eine zu hohe (nicht) ausgelagerte Poolnutzung analysiert werden kann. magicandre1981 vor 6 Jahren 0
Ja, dies ist ein Duplikat, aber ich bin mir nicht sicher, warum wir weiter im Kreis darüber reden müssen. ner0 vor 6 Jahren 0
@ magicandre1981 Ich kann Ihre Antwort aufgrund einer geringen Wiederholungsrate nicht kommentieren, aber ich werde dies hier ablegen: Ich bin nicht sicher, ob das gelegentliche Problem mit `findstr / s __ *. * 'nur den übereinstimmenden Inhalt zurückgibt, aber nicht das Dateiname hängt mit dem Betriebssystem oder einer bestimmten Befehlszeilenkonfiguration zusammen, trat jedoch beim Versuch auf. Es funktionierte beim Hinzufügen eines Flags, um die Zeilennummer "findstr / s / n __ *. *" Auszugeben, oder es wurde ein Flag verwendet, um nur den Dateinamen "findstr / s / m __ *. *" Auszugeben ner0 vor 6 Jahren 0
"Das grundlegende Ziel, doppelte Fragen zu schließen, besteht darin, Menschen dabei zu helfen, die richtige Antwort zu finden, indem sie alle diese Antworten an einem Ort erhalten **, so dass die Regeln hier sind. magicandre1981 vor 6 Jahren 0
Trotzdem bestreitet niemand, dass dies ein Duplikat ist. Was sollte ich tun oder sagen, um dies klarer zu machen, als zu sagen: "Ich stimme der Entscheidung, dass diese Frage als Duplikat eingestuft wird, voll und ganz zu." ner0 vor 6 Jahren 0

0 Antworten auf die Frage

Verwandte Probleme