タスク スケジューラを使用すると、UAC プロンプトなしで管理者権限でスクリプトを実行できるため、いくつかの Auto-HotKey スクリプトを自動起動しようとしています。
通常、スクリプトは数時間後に失敗します。UAC/explorer.exe/startup フォルダー経由で実行すると、これらのスクリプトはすべて数日間実行されます。(タスク スケジューラ経由で確実に動作するのを確認した唯一のスクリプトは、「Hello World」メッセージ ボックスをポップアップ表示する単純なスクリプトです。)
Process Explorer を使用すると、taskeng.exe 子プロセスのワーキング セットのサイズが常に縮小されている (約 3,000K から 512K 程度) 一方、UAC/explorer.exe 子プロセスは一定のままであることがわかります。
AHK コードを使用して、ワーキング セットのサイズを変更できるかどうかを確認してみました。
pid := DllCall("GetCurrentProcessId")
handle := DllCall("OpenProcess", "UInt", 0x001F0FFF, "Int", 0, "Int", pid)
DllCall("SetProcessWorkingSetSize", "UInt", handle, "Int", 10000000, "Int", 20000000)
DllCall("CloseHandle", "Int", handle)
うまくいかなかったようで、問題を解決できるかどうかはわかりません。
解決策は、実行ファイルを 32 ビットではなく 64 ビットとしてコンパイルすることでした。数か月使用した中で、スタートアップ フォルダー経由で 32 ビット バージョンが完全に正常に動作していたため、これまでこれを試したことはありませんでした。
この問題は、キーボード フックがメモリにロードされ、ガベージ コレクション中にアンロードされたことが原因であると考えられます。キーボード フックで割り当てられたホットキーのみが影響を受け、RegisterHotkey を使用して割り当てられたホットキーは影響を受けません。
64 ビット実行ファイルを 1 週間以上使用していますが、失敗は 1 つもありません。ただし、応答が少し遅いものもありました (バックグラウンド プロセスまたは Chrome がリソースを消費していることが原因かもしれません)。親の taskeng.exe プロセスと svchost プロセスを強制終了または再起動すると、この問題が解決する可能性があります。これが、ワーキング セットの再割り当てを停止する唯一の方法だからです (それでも 32 ビットの問題は解決せず、親の svchost を強制終了すると、いくつかの新しい問題が発生します)。
[2018-10-03 更新: 基本的に問題は解決しました。] タスク スケジューラでは、タスクを異なる優先順位で実行するように設定できますが、ユーザー インターフェイスにはそれが表示されません。
優先度を変更するには:
- タスクを XML ファイルとしてエクスポートします。
- XMLファイルを編集し、Priorityタグを変更します。このページ優先順位リスト用。
- StopOnIdleEnd を「false」に設定します。(テストしていませんが、マウス/入力の遅延を引き起こしていた可能性があります。)
- 変更した XML ファイルをタスクとしてインポートすると、動作するはずです。
この方法で優先度を上げると、メモリと I/O の優先度も上がります。
AHK スクリプトを 64 ビットとしてコンパイルする必要がある場合もあります。