Почему возникает ошибка «1С поддерживается только windows_x86 или _x86_64 платформы» и как её исправить?

← На главную

При работе в клиент-серверном варианте платформы 1С:Предприятие пользователи и разработчики часто сталкиваются с загадочным сообщением: «1С поддерживается только windows_x86 или _x86_64 платформы». Ошибка сбивает с толку, так как она может появиться на современном компьютере с операционной системой Windows 10 или 11 и процессором Intel Core i3/i5/i7, который полностью соответствует требованиям. В этой статье мы подробно разберем, почему возникает этот конфликт, проанализируем техническую подоплеку и найдем способы решения проблемы.

Выясним причину: архитектура системы и контекст выполнения

Для начала проанализируем ситуацию, которая чаще всего приводит к этой ошибке. В современной ИТ-инфраструктуре часто используется «гибридная» схема: на рабочих станциях пользователей установлена ОС Windows, а сервер 1С:Предприятия работает под управлением Linux (Ubuntu, CentOS, Astra Linux и др.).

Ошибка возникает не потому, что ваш компьютер «плохой» или процессор «не подходит». Она сигнализирует о том, что код программы пытается вызвать технологию, которая существует только в среде Microsoft Windows, находясь при этом в контексте сервера, работающего на Linux. Платформа 1С честно сообщает: «То, что вы просите меня сделать, я умею делать только на Windows-платформах».

Рассмотрим основные сценарии, вызывающие этот сбой:

Использование COM-объектов на стороне сервера.
Подключение внешних компонент, не имеющих Linux-версии (отсутствие .so файлов).
Прямые обращения к ADO или специфическим системным библиотекам Windows (DLL).
Работа с торговым оборудованием или драйверами через старые интерфейсы.

Сценарий 1: Использование COM-объектов на сервере

Разберем самый распространенный случай. В коде конфигурации часто встречается создание объектов для работы с Excel, Word или парсинга почты через Outlook. Например:


// Пример проблемного кода
Попытка
    Excel = Новый COMОбъект("Excel.Application");
Исключение
    Сообщить("Ошибка создания Excel");
КонецПопытки;

Если этот код выполняется в процедуре с директивой &НаСервере или в серверном модуле, то при работе на Linux-сервере платформа выдаст искомую ошибку. Технология COM (Component Object Model) является проприетарной разработкой Microsoft и физически отсутствует в ядре Linux.

Как мы можем это решить?

Проанализируем возможность переноса выполнения кода на клиентскую сторону. Если действие инициируется пользователем (например, загрузка файла), мы должны выполнять создание COM-объекта в контексте &НаКлиенте. На Windows-клиенте этот код отработает корректно, даже если сервер — Linux.

Если же перенос на клиент невозможен (например, работа идет в регламентном задании), следует отказаться от COM в пользу кроссплатформенных методов. Для работы с Excel рассмотрим использование библиотек для прямого чтения XLSX-файлов или встроенные средства платформы 1С: ТабличныйДокумент.Прочитать().

Сценарий 2: Внешние компоненты (Native API vs COM)

Многие внешние компоненты, особенно для работы со штрихкодами, криптографией или оборудованием, исторически поставлялись только в виде .dll файлов. Рассмотрим ситуацию: сервер пытается вызвать метод УстановитьВнешнююКомпоненту(). Если в макете компоненты нет библиотеки с расширением .so (скомпилированной под Linux), система выдаст ошибку о неподдерживаемой платформе.

Выясним, как проверить компоненту. Современные компоненты должны разрабатываться по технологии Native API. Проверим код подключения:


// Правильный подход с проверкой платформы
Если ПодключитьВнешнююКомпоненту("ОбщийМакет.МояКомпонента", "MyComponent", ТипВнешнейКомпоненты.Native) Тогда
    // Работаем с компонентой
Иначе
    // Обработка ошибки
КонецЕсли;

Если ваша компонента поддерживает только ТипВнешнейКомпоненты.COM, она никогда не заработает на Linux-сервере 1С. В этом случае необходимо искать аналог, поддерживающий Native API и имеющий сборки под обе операционные системы.

Сценарий 3: Проверка среды в коде (Инструкции препроцессора)

Чтобы избежать аварийного завершения работы, мы должны научить нашу программу определять, где именно она выполняется. Разберем использование инструкций препроцессора. Это позволяет «спрятать» Windows-зависимый код от сервера Linux.


#Если Клиент И Windows Тогда
    // Здесь безопасно вызываем COM-объекты
    Объект = Новый COMОбъект("MSScriptControl.ScriptControl");
#Иначе
    // Альтернативная логика для Linux или серверного контекста
    ВызватьИсключение "Данная функция доступна только на Windows-клиенте";
#КонецЕсли

Посмотрим на пример из типовых конфигураций (БСП). Часто используется проверка через программные методы. Мы можем проанализировать свойство системы:


Информация = СистемнаяИнформация;
Если Информация.ТипПлатформы = ТипПлатформы.Windows_x86 Или Информация.ТипПлатформы = ТипПлатформы.Windows_x86_64 Тогда
    // Windows-специфичный код
КонецЕсли;

Практические шаги по устранению ошибки

Если вы столкнулись с этой ошибкой, выполним следующие шаги для диагностики:

Определим место возникновения: Используем замер производительности или отладку, чтобы найти точную строку кода, на которой происходит прерывание.
Проверим контекст: Посмотрим, выполняется ли этот код на сервере (директива &НаСервере, модуль объекта, общий модуль с галочкой «Сервер»).
Проверим тип сервера: Убедимся, что сервер действительно работает под Linux (это можно увидеть в консоли администрирования 1С или через «О программе» в меню справки).
Изучим вызываемый объект: Если это Новый COMОбъект, ADODB.Connection, V83.Application — мы нашли виновника.
Применим решение: Либо переносим вызов на клиентскую часть (Windows), либо используем кроссплатформенные аналоги (например, вместо ADO используем «Внешние источники данных» платформы через ODBC).

Особенности 64-битных систем и библиотек

Иногда ошибка может возникать даже на Windows-сервере, если происходит попытка вызвать 32-битную компоненту из-под 64-битного процесса сервера 1С. Хотя текст ошибки в последних версиях платформы стал более унифицированным, суть остается прежней: несоответствие разрядности или операционной среды.

Проанализируем ситуацию с ADO (ActiveX Data Objects). Это популярный способ подключения к внешним SQL-базам. На Linux-сервере он не работает. Для решения этой задачи разберем использование механизма «Внешние источники данных». Он позволяет платформе 1С самостоятельно взаимодействовать с СУБД, используя драйверы unixODBC на Linux, что делает код универсальным и предотвращает появление ошибок совместимости.

Подводя итог, отметим: ошибка «1С поддерживается только windows_x86 или _x86_64 платформы» — это всегда сигнал о том, что код написан без учета кроссплатформенности. Переход на Native API, использование встроенных средств работы с файлами и правильное распределение кода между клиентом и сервером позволят вашей системе работать стабильно в любой среде.