Скрипт vbs для v83.COMConnector падает: Прекращена работа программы script host #774801

В vbs выполняю следующее: Появляется окно с ошибкой "Прекращена работа программы microsoft windows based script host" Если оставить только первую строку - ошибок нет. Если выполнять на Windows XP - ошибок нет. В какую сторону копать?

предлагаю лог системы посмотреть для начала

какой именно лог и где его смотреть?

вот что написано в Журналы WindowsПриложения Путь сбойного приложения: C:WindowsSystem32WScript.exe Путь сбойного модуля: C:Program Files1cv88.3.5.1517infiledb.dll Подозреваю, что это связано со следующими событиями: 1) До этого создание COMConnector из скрипта вызывало ошибку "Невозможно создание объекта контейнером activex v83.comconnector". Хотя его создание из программного кода 1С выполнялось корректно. 2) Я установил 1CEnterprise 8 Server (x86-64).msi. После этого эта ошибка снялась, но появилась новая - см топик. Журнал Виндовс как раз показывает на каталог с 64 приложениями (Program Files), а конкретно на библиотеку filedb.dll Как эту информацию можно использовать?

Вероятно дело в том, что WScript 32-разрядный Если запускать явно C:WindowsSysWOW64WScript.exe то ошибки нет. Но что-то мне эта тема не нравится. Почему 1С создает 32x COMConnector, а у скрипта ошибка "Невозможно создание объекта контейнером activex"?

ну, глупо ожидать что 32х разрядная программа вдруг выдаст 64х разрядный скрипт.

как скрипт может быть 64разрядным? Вопрос такой на данный момент: Как сделать, чтобы операционка создавала COMConnector 32разрядный при запуске скрипта, также как это делает 1С если из ее програмного кода создавать COMConnector?

думал, может v83.Application использовать, а не v83.COMConnector, но там тоже засада - если уже открыт к.н. сеанс в файловой базе, то второй должен быть той же версии, иначе ошибка а v83.Application явно версию 1с задавать не позволяет

И чем тебе это не нравится? Хочешь универсальности, то сначала определи битность, а потом запусти нужный

не нравится тем, что это будет работать на удаленных точках и должно работать автономно надежно ничего слетать "само" не должно ну и настойки минимальные первоначальные

Так и не надо никаких настроек. Систему определил и нужный дергнул

Есть подозрение, что все это можно на том же 1с и написать

Так проблемы не будет скорее всего, неинтересно

нужно прозрачно для пользователя делать вот мои еще мои попытки

что значит прозрачно для пользователя? чем фоновое задание не устраивает?

окно не отображаемое, и будут пользователь комп выключать пока процесс не завершился

> что значит прозрачно для пользователя? нужно минимизировать раздражители для пользователя в виде окон > чем фоновое задание не устраивает? клиент-серверная база в клиентском контексте должна запустить ряд запусков файловой базы если использовать фоновые задания то они будут на сервере

файловые базы где лежат?

локально

пока что все больше склоняюсь к запуску командной строкой смущает здесь открытие заставки 1с и сложность с передачей результата запуска завершенного процесса 1с для последующего процесса Например, что РИБ пришел с обновлением конфигурации и нужно запустить кофигуратор с параметром UpdConfig

так заморачиваться для обновления риб?

а какие альтернативы? БСП? пока не рассматриваю

ты так часто РИБ обновляешь? не проще ли подключиться да щелкнуть мышкой. Ну или в БСП посмотреть как там сделана выдача сообщения и запуск обновления

да, пожалуй аналог БСП попробую - запускать файловую базу и полностью ей управление передавать: пришло обновление - 1с закрывается и при закрытии запускает скрипт, который обновит конфигурацию и опять 1с запустит для продолжения обмена если бы с ComConnector не было заморочек, было бы веселее, конечно

подключиться и мышкой точно не вариант конечных узлов большое количество

пользуйся планировщиком windows. Вещь. Подсовываешь ему расписание и bat-файл, он тебе всё обновляет в режиме полной скрытности от пользователя.

в бат-файле строчка "C:Program Files1cv828.2.19.106in1cv8.exe" DESIGNER /F"D:asesuh20" /N"адм" /P111 /UpdateDBCfg

нужна реализация с минимальным вмешательством администратора

вот здесь нашел ответ на мой вопрос "Почему 1С создает 32x COMConnector, а у скрипта ошибка "Невозможно создание объекта контейнером activex"?" ответ следующий: 2) Дальнейшее "гугленье" показало, что Windows Script Host, имеющийся в Win7 64 не создает 32-х разрядные COM объекты. 3) Скачиваем 32-х разрядный WSH с сайта от Win XP. (Возможно достаточно взять WScript.exe от 32-х битной Win7, но такой не нашлось поблизости) 4) Распаковываем (например WinRAR-ом) в определенную папку (у меня c:WScript32) 5) Запускаем скрипт п.1 C:WScript32WScript.exe c:scriptsCreate1C.vbs

А чем решение из плохо? В 64-битных системах есть 2 WScript32, в C:WindowsSysWOW64 хранятся компоненты системы для совместимости с 32-битными приложениями. Естественно, 64-битное приложение не может загрузить к себе в адресное пространство 32-битные DLL. Можно повесить в скриптик, который дождётся завершения предприятия и произведёт обновление. А его запуск может быть выполнен перед выходом из предприятия, когда надо обновиться.

> Естественно, 64-битное приложение не может загрузить к себе в адресное пространство 32-битные DLL. Ты считаешь, что это приложение 64-битное: C:WindowsSystem32wscript.exe ?

В C:WindowsSystem32 лежит 64х битное, если кто стороннее не положил, в C:WindowsSysWOW64 - 32х битное для совместимости. 32-приложения, автоматически перенаправляются в C:WindowsSysWOW64, если, конечно, они не вызывают специальные функции, чтобы отключить редирект.

весело

а где тут вмешательство администратора. У меня тут такой обмен уже 4 года крутится без никакого администратора. Даже все забыли, что он есть.

я имею введу предварительные настройки на конечных узлах единственное, если рулить планировщиком тоже скриптами

Платформу патчили unipatch-ем (backbas.dll)?