Ich habe versucht, einige Auto-HotKey-Skripte mithilfe des Taskplaners automatisch zu starten, da die Skripte dadurch mit Administratorrechten und ohne UAC-Eingabeaufforderung ausgeführt werden können.
Normalerweise schlagen die Skripte nach mehreren Stunden fehl. Wenn sie über den Ordner UAC/explorer.exe/startup ausgeführt werden, laufen alle diese Skripte mehrere Tage lang. (Das einzige, das ich über den Taskplaner zuverlässig funktionieren sehe, ist ein einfaches Skript, das ein „Hallo Welt“-Nachrichtenfenster öffnet.)
Bei der Verwendung des Process Explorers stelle ich fest, dass die Größe der Arbeitssätze der untergeordneten Prozesse von taskeng.exe immer reduziert wurde (von ~3.000 KB auf etwa 512 KB), während die Größe der untergeordneten Prozesse von UAC/explorer.exe unverändert blieb.
Ich habe versucht, mithilfe von AHK-Code zu sehen, ob sich damit die Größe des Arbeitssatzes ändern lässt:
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 nicht zu funktionieren, daher bin ich nicht sicher, ob es eine Lösung für das Problem gibt.
Die Lösung bestand darin, die ausführbare Datei als 64-Bit statt als 32-Bit zu kompilieren. Ich hatte das vorher nicht versucht, da die 32-Bit-Version über den Startordner in den Monaten, in denen ich sie verwendet habe, einwandfrei funktionierte.
Ich glaube, das Problem rührte daher, dass der Tastatur-Hook in den Speicher geladen und dann während der Garbage Collection entladen wurde. Betroffen waren nur die dem Tastatur-Hook zugewiesenen Hotkeys, nicht die, die mit RegisterHotkey zugewiesen wurden.
Ich verwende die 64-Bit-Programme jetzt seit über einer Woche und keines ist ausgefallen, obwohl einige etwas langsam reagierten (das könnte mit Hintergrundprozessen oder Chromes Ressourcenverbrauch zu tun haben). Das Beenden oder Neustarten der übergeordneten Prozesse taskeng.exe und svchost könnte dieses Problem beheben, da dies die einzige Möglichkeit war, die Neuzuweisung des Arbeitssatzes zu stoppen (das 32-Bit-Problem wurde dadurch immer noch nicht behoben und das Beenden des übergeordneten svchost hat einige neue Probleme verursacht).
[Update vom 03.10.2018: Ich habe das Problem grundsätzlich gelöst.] Der Taskplaner kann Aufgaben so einstellen, dass sie mit unterschiedlichen Prioritäten ausgeführt werden, aber die Benutzeroberfläche zeigt dies nicht an.
So ändern Sie die Priorität:
- Exportieren Sie die Aufgabe als XML-Datei.
- Bearbeiten Sie die XML-Datei und ändern Sie das Priority-Tag. Siehediese Seitefür eine Prioritätenliste.
- Setzen Sie StopOnIdleEnd auf „false“. (Ich habe das nicht getestet, aber es könnte zu Verzögerungen bei der Maus/Eingabe geführt haben.)
- Importieren Sie die geänderte XML-Datei als Aufgabe und es sollte funktionieren.
Durch diese Erhöhung der Priorität wird auch die Speicher- und E/A-Priorität erhöht.
Das Kompilieren von AHK-Skripten als 64-Bit kann weiterhin erforderlich sein.