Яка подія планувальника завдань Windows 7 відповіла б на режим простою END?


8

Планувальник завдань Windows 7 дозволяє мені виконувати завдання, коли комп'ютер працює в режимі очікування, але, здається, не існує жодного очевидного способу виконання завдання, коли комп'ютер поновлюється з режиму очікування або більше не працює.

Напевно, якась подія, запущена у Windows (журнал подій?), Коли комп'ютер більше не працює? Або якимось чином зафіксувати той факт, що комп'ютер більше не працює, і відповісти на це плановим завданням?

Як би я це зробив?

Або, в гіршому випадку, чи є десь програма командного рядка, яка може викликати команди чи події, коли комп'ютер переходить у стан очікування?

[ОНОВЛЕННЯ:] Підхід у моїй відповіді на Діого Роша працює. Я створив нульовий виконуваний файл через py2exe з цього сценарію:

import sys
import time

#restart a pause every twenty seconds, with two functions that call each other.

def call_pause():
    pause()

def pause():
    time.sleep(20)
    call_pause()

call_pause()

--і встановіть заплановане завдання в Windows, для якого це експортований HTML:

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <Date>2012-04-27T17:40:46.8871631</Date>
    <Author>GENIUS-BREATH-COMPY</Author>
    <Description>This task runs ProgA when the computer enters an idle state, and terminates ProgA when the computer *leaves* an idle state. The is all for scheduled TaskB, which periodically runs a batch that tests whether ProgA is running. If ProgA is not running (because this task terminated it), ProgB runs (as the computer is NOT idle). If ProgA *is* running, TaskB's batch does not run ProgB.</Description>
  </RegistrationInfo>
  <Triggers>
    <IdleTrigger>
      <Enabled>true</Enabled>
    </IdleTrigger>
  </Triggers>
  <Principals>
    <Principal id="Author">
      <UserId>S-1-5-18</UserId>
      <RunLevel>HighestAvailable</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
    <AllowHardTerminate>true</AllowHardTerminate>
    <StartWhenAvailable>true</StartWhenAvailable>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <IdleSettings>
      <Duration>PT1M</Duration>
      <WaitTimeout>PT0S</WaitTimeout>
      <StopOnIdleEnd>true</StopOnIdleEnd>
      <RestartOnIdle>true</RestartOnIdle>
    </IdleSettings>
    <AllowStartOnDemand>true</AllowStartOnDemand>
    <Enabled>true</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>true</RunOnlyIfIdle>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>PT0S</ExecutionTimeLimit>
    <Priority>7</Priority>
    <RestartOnFailure>
      <Interval>PT1M</Interval>
      <Count>3</Count>
    </RestartOnFailure>
  </Settings>
  <Actions Context="Author">
    <Exec>
      <Command>C:\path_to\nullExecutable</Command>
    </Exec>
  </Actions>
</Task>

І залишив мій комп'ютер в режимі очікування на 15 хвилин. Диспетчер завдань показав запущений виконуваний файл. Як тільки я перемістив мишу, комп'ютер вийшов з режиму очікування, і нульовий виконуваний файл зник зі списку завдань.

Звідси мова йде про те, щоб створити завдання (або програму - яку я роблю з Python та py2exe), яка використовує pslist (з перемикачем -accepteula, щоб на комп'ютерах, які його розгортали, він фактично запускав програму) для перевірте, чи працює null exe. Якщо він працює, змінна середовища% ERRORLEVEL% встановлена ​​на 0, оскільки pslist запускався без помилок. Якщо ця змінна середовище дорівнює 1, вона запускалася з помилкою (вона не знайшла виконуваний файл). Я використовую цю змінну середовища в пакетному скрипті, щоб виконати інше завдання, якщо комп'ютер не працює.


Як визначити стан очікування Windows 7?
Der Hochstapler

Бажання я знав. Я бачив способи нібито зламати це; найкраща відповідь, яку я знайшов (і перевірив), - це те, що стан очікування спрацьовує за 15 хвилин без активності користувача (клавіатура, миша тощо) та невелике використання процесора.
r_alex_hall

Просто FYI, я вважаю, що ця подія Windows була дуже хиткою (вона не завжди відповідала на відновлену діяльність користувачів), і цілі, які я прагнув досягти цим питанням, були набагато краще виконані шляхом AutoHotkey, в програмі I розроблено: github.com/r-alex-hall/farmComm
r_alex_hall

Відповіді:


4

Я не думаю, що неможливо реалізувати будь-які методи виявлення "межі" тригера на холостих подіях (увійти або вийти з режиму очікування), однак є команда, яка змушує вашу Windows входити в стан очікування та виконувати запущені завдання :

Rundll32.exe advapi32.dll,ProcessIdleTasks

Ви можете поєднати іншу подію (з журналу подій), щоб запустити цю команду, що, в свою чергу, викликає ще одне завдання, яке потрібно запустити в режимі очікування. Наскільки ви знаєте, ви можете вільно комбінувати будь-які завдання, які вам можуть захотіти.


1
Хм. . . що приводить мене до думки. . . Я міг би підійти до цього так, без Rundll32.exe. Я міг налаштувати заплановану taskA для запуску ProgA на холостому ході комп'ютера - і потім створити TaskB, який запускає batchB.bat раз на хвилину. BatchB.bat використовує Pslist, щоб перевірити, чи працює ProgA (а якщо ні, запустіть ProgB). Це само по собі не буде працювати, оскільки ProgA продовжує працювати, навіть якщо комп'ютер не працює. . . АЛЕ . . (Я щойно зрозумів!) Є умова планувальника завдань "Зупинити [програму], якщо комп'ютер перестає працювати без роботи". Якщо це вбиває виконання ProgA, то batchB.bat запустив би ProgB!
r_alex_hall
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.