Скрипт пришлось родить для запуска баз по именам с помощью стартера платформы 1С 8.3.
Известная проблема состоит в том, что стартер (1cestart.exe) завершается раньше запущенного им дочернего процесса, что делает использование команды Start бессмысленым. Данный скрипт опрашивает список процессов по идентификатору родительского процесса PID средствами WMI с указанным интервалом, и завершается, когда ссылок на PID не остается.
Теперь можно забыть о прописывании версий и прочих индивидуальных настроек баз в скрипты, а указывать только файл списка баз (или сослаться на него из 1cv82\common\1CESCmn.cfg) и имя базы - все остальное стартер найдет в списке баз.
Область применения - пакетный запуск конфигуратора (тестирование, архивация, выгрузка/загрузка исходников для трехстороннего сравнения и прочей обработки).
Разумеется, применение этого скрипта не ограничивается запуском 1С, единственное ограничение - дочерние процессы 2 и следующих уровней не просматриваюся. Допилить на этот случай не так просто, выйдет динамический WMI-запрос неопределенной длины, и наверняка будут проблемы с его исполнением.
Запуск нужно производить при помощи "cscript //nologo ...", чтобы избежать появления диалоговых окон.
Толком не тестил (отладчика под рукой нет, а наколенная разработка уже не радует), но у клиентов работает без нареканий...
*****
Версия 1.0.4, 2015-06-02.
Добавлен контроль времени создания дочерних процессов.
Вероятность попадания процессов с идентичным PID родителя в список ожидания завершения сведена почти к нулю (почти - потому что в некоторых случаях не удается точно определить время запуска и/или завершения корневого процесса).
Версия 1.0.5, 2016-01-01.
Реализованы отладочные сообщения для процедуры разбора параметров.
Мелкие исправления во встроенной справке скрипта.
Версия 1.0.6, 2021-06-10.
Добавлен параметр TimeToStart=5сек, определяющий время ожидания запуска дочерних процессов после завершения родительского, для громоздких процессов и тормознутых систем.
Добавлен вывод справки при запуске без параметров.
Исправелны сообщения, содержащии время начала и завершения дочернего процесса - была путаница с UTC.