Windows 7: Task Scheduler / Engine reduziert das Working Set / Memory von Anwendungen. Gibt es überhaupt einen Stopp?

406
RedLetter

Ich habe versucht, einige Auto-HotKey-Skripts mithilfe des Task-Schedulers automatisch zu starten, da die Skripts mit Administratorrechten ohne UAC-Eingabeaufforderung ausgeführt werden können.

Normalerweise schlagen die Skripts nach einigen Stunden fehl. Bei Ausführung über den Ordner UAC / explorer.exe / startup werden alle diese Skripts mehrere Tage ausgeführt. (Die einzige, die ich über Task Scheduler zuverlässig gesehen habe, ist eine einfache, die ein Meldungsfeld "Hello World" anzeigt.)

Durch die Verwendung von Process Explorer stelle ich fest, dass die Arbeitssets der untergeordneten Prozesse von taskeng.exe immer reduziert wurden (von ~ 3.000 KB auf 512 KB oder so), während die untergeordneten Prozesse UAC / explorer.exe konstant blieben.

Ich habe versucht, AHK-Code zu verwenden, um zu sehen, ob er die Größe des Arbeitssatzes ändern kann:

pid := DllCall("GetCurrentProcessId") handle := DllCall("OpenProcess", "UInt", 0x001F0FFF, "Int", 0, "Int", pid) DllCall("SetProcessWorkingSetSize", "UInt", handle, "Int", 10000000, "Int", 20000000) DllCall("CloseHandle", "Int", handle)

Es schien keine Schlepparbeit zu geben, daher bin ich nicht sicher, ob das Problem behoben werden kann.

Die Lösung bestand darin, die ausführbare Datei als 64-Bit statt als 32-Bit zu kompilieren. Ich hatte das vorher nicht ausprobiert, da die 32-Bit-Version über die Startup-Ordner in den Monaten, in denen ich sie verwendet habe, einwandfrei funktioniert hat.

Ich glaube, das Problem rührte von dem Tastaturhaken her, der in den Speicher geladen und dann während der Speicherbereinigung entladen wurde. Es waren nur Hotkeys mit Tastaturhaken betroffen, nicht die mit RegisterHotkey zugewiesenen.

Ich verwende die 64-Bit-ausführbaren Dateien nun schon seit über einer Woche und keines ist ausgefallen, obwohl einige etwas zu langsam reagierten (dies hat möglicherweise etwas mit Hintergrundprozessen oder Chrome-Ressourcen zu tun). Das Beenden oder Neustarten der übergeordneten Prozesse taskeng.exe und svchost könnte dieses Problem beheben, da dies die einzige Möglichkeit war, die Neuzuordnung des Arbeitssatzes zu beenden (das 32-Bit-Problem wurde immer noch nicht behoben, und durch das Beenden des übergeordneten svchost wurden einige Probleme verursacht.) ).

[2018-10-03 Update: Ich habe das Problem grundsätzlich gelöst.] Task Scheduler kann festlegen, dass Aufgaben mit unterschiedlichen Prioritäten ausgeführt werden, die Benutzeroberfläche zeigt sie jedoch nicht an.

Um die Priorität zu ändern:

  1. Exportieren Sie die Aufgabe als XML-Datei.
  2. Bearbeiten Sie die XML-Datei und ändern Sie das Priority-Tag. Auf dieser Seite finden Sie eine Prioritätenliste.
  3. Setzen Sie das StopOnIdleEnd auf "false". (Habe das nicht getestet, aber es könnte zu Verzögerungen bei der Maus / Eingabe geführt haben.)
  4. Importieren Sie die geänderte XML-Datei als Task und es sollte funktionieren.

Durch das Erhöhen der Priorität werden auch die Speicher- und E / A-Priorität erhöht.

Das Kompilieren von AHK-Skripts als 64-Bit ist möglicherweise noch erforderlich.

2
Ich benutze auch den Taskplaner, um AutoHotkey beim Start zu starten und vor demselben Problem zu stehen. Ich habe auch bemerkt, dass es passiert, wenn ich es auch manuell starte. Nicht sicher warum. Zur Problemumgehung habe ich im Startmenü die Option Run als Admin-Verknüpfung hinzugefügt und von dort aus ausführen, wann immer es abstürzt VarunAgw vor 6 Jahren 0
Seltsam ist, dass ich viele Monate ohne Probleme ein großes / komplexes Many-Key-Skript ausgeführt habe (über das Startmenü ohne Erhöhung auf admin). Es hat perfekt funktioniert, aber jetzt gibt es Probleme bei der Beibehaltung der Tastenkombinationen. Entweder führe ich zu viele Skripte aus, das Hochfahren auf Admin verursacht Probleme oder das Sperren meines Kontos verursacht es. RedLetter vor 6 Jahren 0
Ich habe vergessen zu erwähnen, dass ich auch über eine Admin-Verknüpfung starte (mit einem Skript-Starter, um Klicks zu reduzieren), und ich habe immer noch die genannten Probleme. Ich denke, das Sperren von Bildschirmsignalen ist möglicherweise ein Problem, aber ich teste immer noch Dinge (es war kein Problem, als ich über den Startordner lief). RedLetter vor 6 Jahren 0
Das Sperren von Bildschirmen ist kein Problem (zumindest bei mir geschieht dies zufällig während der Arbeit). Mein AHK-Skript ist 2K lang. Das Problem darin zu finden, ist wie das Auffinden einer Nadel in einem Heuhaufen, da es sehr selten vorkommt. Wenn Sie wirklich wollen, können Sie es in kleine Skripte aufteilen und sehen, welcher Teil abstürzt VarunAgw vor 6 Jahren 0
Siehe auch [this] (https://autohotkey.com/boards/viewtopic.php?f=14&t=44268&p=200646#p200646). Vielleicht hilft es dir. VarunAgw vor 6 Jahren 0
Ich denke, ich habe herausgefunden, dass ich in meinen Skripten die Direktive #Persistent brauche. Wenn Sie es jetzt testen, wird der Arbeitssatzsprung in der Größe angezeigt, wenn Sie einen Hotkey drücken. Ich sollte morgen wissen, wann meine Skripte viele Stunden laufen. RedLetter vor 6 Jahren 0
Zu früh gesprochen Es versagte innerhalb einer Stunde oder so. RedLetter vor 6 Jahren 0
Okay, ich habe herausgefunden, dass mein Skript nicht fehlgeschlagen ist, die Hotkeys waren. Aus irgendeinem Grund schlagen Hotkeys fehl, die die Standard-Hotkeys des Systems überschreiben, wenn sie unter Taskplaner ausgeführt werden. (Deshalb schienen einige meiner Skripte zu funktionieren, sie haben keinen anderen Hotkey überschrieben.) Das Aufteilen des Skripts in zwei Teile und die Verwendung von WinWait für die Kommunikation bedeutet keinen Fehler. Aber es verbraucht 4-8% der CPU, also werde ich noch ein wenig experimentieren und andere Wege ausprobieren, um das zu umgehen. RedLetter vor 6 Jahren 0
Warum machst du das alles? Ich dachte du Autohotkey stürzt sich für dich ab. Wenn Sie Win + X-Tasten drehen und ahk als Administrator ausführen, wird das Problem wahrscheinlich für Sie gelöst. Https://www.askvg.com/tip-how-to-disable-all-win-keyboard-shortcuts-hotkeys-in-windows/ VarunAgw vor 6 Jahren 0
Ich fand heraus, dass ich die ausführbare Datei als 64-Bit kompilieren musste. Ich habe nicht gedacht, das vorher zu versuchen, weil die ausführbare 32-Bit-Datei einwandfrei funktioniert, wenn sie vom Startordner aus ausgeführt wird. Möglicherweise müssen Sie noch herausfinden, wie Sie die Priorität des Speichers für eine bessere Reaktionsfähigkeit optimieren können. RedLetter vor 5 Jahren 0

0 Antworten auf die Frage

Verwandte Probleme