При разработке в среде 1С:Предприятие программисты часто сталкиваются с ситуацией, когда необходимо вызвать внешнюю системную утилиту Windows, например, msg.exe для отправки сообщений пользователям или powershell.exe для выполнения сложных сценариев. Однако, если вы используете 32-битный клиент 1С на 64-битной операционной системе, обычный вызов через ЗапуститьПриложение может завершиться ошибкой "Файл не найден" или "Имя не распознано", даже если вы точно знаете, что файл существует в папке System32. В этой статье мы подробно разберем, почему это происходит и как правильно организовать запуск 64-битных приложений.
Для начала проанализируем ситуацию с точки зрения архитектуры Windows. В 64-битных версиях ОС реализован механизм под названием File System Redirector (перенаправитель файловой системы). Его задача — обеспечить совместимость старых 32-битных приложений. Когда 32-битный процесс (каким является клиент 1С 1cv8.exe) пытается обратиться к каталогу C:\Windows\System32, операционная система прозрачно для приложения перенаправляет запрос в папку C:\Windows\SysWOW64.
Проблема заключается в том, что многие системные утилиты (такие как msg.exe) существуют только в 64-битной версии и находятся исключительно в настоящем System32. В папке SysWOW64 их просто нет. Поэтому, когда 1С пытается запустить msg.exe, Windows ищет его в "подмененной" папке для 32-битных файлов, не находит и выдает ошибку.
Рассмотрим самый правильный и надежный способ решения задачи. Разработчики Microsoft предусмотрели специальный псевдоним (alias) для доступа к реальной 64-битной системной папке из 32-битных приложений. Этот псевдоним называется Sysnative.
Важно понимать: папки C:\Windows\Sysnative физически не существует на диске. Это виртуальный путь, который виден только 32-битным процессам. Если вы попробуете открыть его через обычный 64-битный Проводник, вы получите ошибку доступа.
Давайте посмотрим на пример кода для запуска утилиты отправки сообщений:
// Правильный запуск 64-битной утилиты msg из 32-битной 1С
ПутьКПриложению = "C:\Windows\Sysnative\msg.exe";
ПараметрыЗапуска = "* /server:ИмяСервера ""Привет, мир!""";
ЗапуститьПриложение(ПутьКПриложению + " " + ПараметрыЗапуска);
Аналогичным образом мы можем запустить 64-битную консоль cmd.exe или powershell.exe. Проанализируем пример с PowerShell:
// Запуск 64-битного PowerShell для выполнения скрипта
ПутьКPS = "C:\Windows\Sysnative\WindowsPowerShell\v1.0\powershell.exe";
Команда = "-File ""D:\Scripts\MyScript.ps1""";
ЗапуститьПриложение(ПутьКPS + " " + Команда);
В некоторых случаях нам может потребоваться временно отключить механизм перенаправления на уровне всего потока приложения. Это более сложный, но гибкий метод, требующий использования функций Windows API. Рассмотрим ситуацию, когда нам нужно проверить наличие файла в системной папке перед запуском.
Для реализации этого метода в 1С можно использовать объект КомандаСистемы или написать небольшую внешнюю компоненту, но чаще всего разработчики используют вызовы через скриптовые языки. Однако, если мы говорим о чистом WinAPI, нам понадобятся две функции: Wow64DisableWow64FsRedirection и Wow64RevertWow64FsRedirection.
Внимание: После выполнения необходимых действий перенаправление нужно обязательно включить обратно, иначе 32-битное приложение 1С может начать работать нестабильно, так как не сможет найти свои собственные 32-битные библиотеки в системных путях.
Если ваша задача — запустить PowerShell-скрипт, который взаимодействует с системными компонентами, всегда явно указывайте путь к 64-битной версии через Sysnative. Выясним причину: 32-битный PowerShell (находящийся в SysWOW64) имеет ограниченный доступ ко многим модулям администрирования. Если вы просто напишете powershell.exe в коде 1С, запустится именно ограниченная 32-битная версия.
Пример корректного вызова:
Команда = "C:\Windows\Sysnative\WindowsPowerShell\v1.0\powershell.exe -Command ""& {msg * /server:localhost 'Сообщение из PS'}""";
ЗапуститьПриложение(Команда);
Разберем ситуацию, упомянутую в обсуждениях, — использование путей к папке WinSxS. Некоторые разработчики находят исполняемые файлы в дебрях каталога C:\Windows\WinSxS\amd64_.... Мы крайне не рекомендуем использовать этот метод. Папки внутри WinSxS содержат в своих названиях версии обновлений (например, 6.1.7601...). Как только Windows установит очередное обновление безопасности, путь к файлу изменится, и ваш код в 1С перестанет работать.
Также не стоит пытаться копировать msg.exe или другие системные библиотеки в папку с базой 1С или в SysWOW64. Системные утилиты часто зависят от множества других DLL, и простое копирование одного .exe файла не приведет к успеху — приложение просто не запустится из-за отсутствия окружения.
Проанализируем сопутствующую проблему. Аналогичное перенаправление существует и для системного реестра. Если 32-битная 1С пытается прочитать ветку HKEY_LOCAL_MACHINE\Software, она будет автоматически перенаправлена в HKEY_LOCAL_MACHINE\Software\WOW6432Node.
Если вы запускаете 64-битное приложение, которое хранит свои настройки в основной ветке, а 1С записывает их в "32-битную" ветку, приложение их не увидит. Для решения этой проблемы при работе с COM-объектами (например, WScript.Shell) или при прямых вызовах WinAPI, необходимо использовать флаги доступа KEY_WOW64_64KEY.
Подводя итог, выделим основные правила работы из 32-битной 1С на 64-битных системах:
System32 всегда используйте виртуальный путь C:\Windows\Sysnative.WinSxS, так как они нестабильны.%PROCESSOR_ARCHITECTURE%, внутри 1С будут возвращать x86, даже если вы работаете на мощном 64-битном сервере.ЗапуститьПриложение не отрабатывает без видимых причин, попробуйте сначала выполнить ту же команду через cmd.exe /k, чтобы окно консоли не закрылось и вы смогли прочитать текст ошибки.Применяя эти знания, вы сможете стабильно интегрировать 1С с системными утилитами Windows, независимо от разрядности используемого клиента.