Различаются версии клиента и сервера 1С: как исправить ошибку

Какие версии сравнивать

Запущенный клиент
Путь,сеанс и полная версия

Целевой сервер
Процесс,путь и та же полная версия

Конфигурацию,x86/x64 и внешние компоненты проверяют отдельно.

Для рассматриваемой клиент-серверной схемы версии клиента и сервера должны совпадать точно. Одного «8.3» или «8.3.27» недостаточно. Правило указано в руководстве администратора 1С 8.3.27, разделе 4.3.6.4.

Если вместо несовпадения версий указан сетевой отказ, сначала используйте статью «Сервер 1С не обнаружен». Не исправляйте разные ошибки одним массовым обновлением.

Шаг 1. Запишите ошибку, адрес базы и масштаб

1. Сохраните полный текст ошибки с обоими номерами версий и временем.
2. Уточните способ входа: прямой клиент, RDS/RemoteApp, Linux или HTTP-публикация.
3. Запишите Srvr/порт и Ref либо URL нужной базы. Не ориентируйтесь только на подпись «Бухгалтерия» в списке.
4. Проверьте, сбой у одного сотрудника, всей терминальной фермы или всех клиентов.
5. Узнайте о последних обновлениях, переключениях DNS, кластера и серверных служб.

Не запоминайте правило «нужная версия всегда справа»: сохраняйте подписи и весь текст сообщения. В смешанной среде ошибка может относиться к другому узлу или компоненту.

Шаг 2. Windows: узнайте, что запущено на сервере

Следующие команды читают состояние. Выполняйте их на фактическом сервере кластера в повышенной PowerShell-сессии. Полный вывод аргументов перед передачей в заявку проверьте на секреты.

Где: Сервер Windows. Зачем: Найти службы агента и их реальные пути запуска.

Get-CimInstance Win32_Service |
    Where-Object { $_.PathName -match 'ragent\.exe' } |
    Select-Object Name, State, ProcessId, StartName, PathName |
    Format-List

Ожидаемый результат: Имена служб, состояние, PID и каталог bin. Сопоставьте с нужными портами и каталогом данных; при нескольких службах не выбирайте первую автоматически.

Где: Тот же сервер. Зачем: Сопоставить агент, менеджер и рабочие процессы с исполняемыми файлами.

$SrvProcesses = Get-CimInstance Win32_Process |
    Where-Object { $_.Name -in @('ragent.exe','rmngr.exe','rphost.exe') }
$SrvProcesses | Select-Object Name, ProcessId, ExecutablePath, CommandLine

Ожидаемый результат: Пути фактически работающих компонентов. Пустой ExecutablePath может означать недостаточные права, а не отсутствие файла.

Где: Тот же сервер, после предыдущей команды. Зачем: Прочитать версии бинарных файлов, а не только имена каталогов.

$SrvProcesses.ExecutablePath | Where-Object { $_ } | Sort-Object -Unique |
    ForEach-Object {
        $VersionInfo = [System.Diagnostics.FileVersionInfo]::GetVersionInfo($_)
        [pscustomobject]@{
            Path=$_; FileVersion=$VersionInfo.FileVersion
            ProductVersion=$VersionInfo.ProductVersion
        }
    }

Ожидаемый результат: Для каждого доступного файла — FileVersion/ProductVersion. Свяжите результат с PID и целевым кластером; файл по другому пути не является доказательством версии нужной службы.

Команды опираются на Get-CimInstance и FileVersionInfo. Версию СУБД здесь не сравнивают с номером клиента 1С.

Шаг 3. Windows: найдите фактически запущенный клиент

Где: Проблемный компьютер или RDS-узел, где работает клиент. Зачем: Узнать полный путь и сеанс процесса 1С.

Get-CimInstance Win32_Process |
    Where-Object { $_.Name -in @('1cv8.exe','1cv8c.exe','1cestart.exe') } |
    Select-Object Name, ProcessId, SessionId, ExecutablePath, CommandLine

Ожидаемый результат: Процессы текущих доступных сеансов. В RDS проверяйте сеанс нужного пользователя; при нехватке прав попросите администратора выполнить чтение.

Где: Тот же узел. Зачем: Проверить свойства найденного клиентского файла.

$ClientExe = Read-Host 'Полный путь найденного 1cv8c.exe или 1cv8.exe'
Get-Item -LiteralPath $ClientExe |
    Select-Object FullName, @{Name='FileVersion';Expression={$_.VersionInfo.FileVersion}},
        @{Name='ProductVersion';Expression={$_.VersionInfo.ProductVersion}}

Ожидаемый результат: Путь и полный номер сборки. Read-Host только сохраняет введённый путь в переменную; Get-Item читает сведения и не меняет установку.

Сравните этот номер с серверным. Пункт «Установленные приложения» показывает наличие пакета, но не выбранный исполняемый файл. После установки новой версии уже открытый старый процесс не превращается в новый.

Шаг 4. Проверьте, установлен ли нужный комплект

Где: Клиентский Windows-узел. Зачем: Посмотреть стандартные каталоги версий без удаления старых установок.

$ClientRoots = @('C:\Program Files\1cv8','C:\Program Files (x86)\1cv8')
foreach ($ClientRoot in $ClientRoots) {
    if (Test-Path -LiteralPath $ClientRoot) {
        Get-ChildItem -LiteralPath $ClientRoot -Directory |
            Select-Object FullName
    }
}

Ожидаемый результат: Список каталогов в двух стандартных местах. Нестандартные или пользовательские установки проверяют отдельно; наличие каталога требует проверки нужного файла внутри.

Несколько релизов могут быть нужны разным базам. Не удаляйте их все, пока не составлен перечень систем и зависимостей. Тонкий клиент обычно запускается через 1cv8c, толстый — через 1cv8; тип клиента выбирают по требованиям приложения, а не по случайному ярлыку.

Шаг 5. Если клиента нет — установите согласованный релиз

Получите дистрибутив точной версии через официальный канал или управляемый репозиторий компании. Выберите поддерживаемую ОС, разрядность и клиентские компоненты. Для исправления одного ПК не меняйте сервер без плана.

Где: Клиентский Windows-узел. Зачем: Проверить подпись полученного установочного файла до запуска.

$InstallerPath = Read-Host 'Полный путь проверяемого setup.exe'
Get-AuthenticodeSignature -LiteralPath $InstallerPath |
    Select-Object Status, StatusMessage, SignerCertificate

Ожидаемый результат: Status и издатель. Valid означает корректную проверку подписи в данной среде, но не доказывает, что это требуемая версия или нужный пакет. При ошибке происхождение и доверие выясняют до установки.

Назначение команды — в Get-AuthenticodeSignature. Для распакованного комплекта учитывайте, какие файлы подписаны; не придумывайте универсальное имя MSI и набор silent-параметров.

Где: После проверки файла и согласования установки. Зачем: Открыть установщик и дождаться его завершения.

$InstallProcess = Start-Process -FilePath $InstallerPath -Wait -PassThru
$InstallProcess.ExitCode

Ожидаемый результат: Установщик откроется интерактивно. Выберите клиентские компоненты; код завершения проверяют по документации этого установщика. Запрос перезагрузки не игнорируют. -Wait ждёт завершения, -PassThru возвращает объект процесса.

Это не команда скрытого массового развёртывания. После установки снова проверьте путь и FileVersion конкретного клиента. При отсутствии прав установку выполняют штатным средством управления, а не выдачей пользователю постоянных административных полномочий.

Шаг 6. Запустите нужный клиент по полному пути

Сначала закройте собственные старые сеансы обычным способом. Не завершайте процессы других пользователей. В примере используется тонкий клиент и учебная база Accounting; подставьте утверждённые Srvr/Ref.

Где: PowerShell проблемного пользователя, после выбора правильного ClientExe. Зачем: Исключить влияние старого ярлыка и стартера при проверке.

& $ClientExe ENTERPRISE /S 'app1c.corp.example.net:1541\Accounting'

Ожидаемый результат: Вызов & запускает именно указанный исполняемый файл. ENTERPRISE выбирает пользовательский режим; /S задаёт серверную базу. Пароль в командную строку не передаётся. Ожидается вход в нужную базу либо новая конкретная ошибка для дальнейшего разбора.

Перед запуском убедитесь, что ClientExe относится к требуемой версии и типу клиента. Факт исчезновения окна несовпадения — ещё не полная приёмка: проверьте имя базы, платформу в «О программе» и контрольную операцию.

Прямой запуск работает, обычный ярлык — нет

Откройте свойства ярлыка и сравните Target/Arguments. Он может указывать напрямую на старый bin, на общий стартер или на другой адрес базы. В окне запуска проверьте поле версии для конкретной записи базы.

Где: Профиль проблемного Windows-пользователя. Зачем: Прочитать локальные настройки выбора версии, не меняя их.

$StartCfg = Join-Path $env:APPDATA '1C\1CEStart\1cestart.cfg'
if (Test-Path -LiteralPath $StartCfg) {
    Select-String -LiteralPath $StartCfg -Pattern 'DefaultVersion|InstalledLocation|CommonCfgLocation'
}

Ожидаемый результат: Строки выбора версии и источников настройки, если файл существует. Это только локальный уровень: могут действовать общие настройки и параметры записи базы.

Не обнуляйте 1cestart.cfg и не удаляйте список баз. Сначала сохраните файлы, выясните, откуда приходит ограничение, затем измените именно настройку проблемной базы или управляемый ярлык. Стартовый механизм и выбор клиента описаны в разделах 4.3.6 и приложении 3 руководства 1С.

RDS и RemoteApp: проверяйте терминальный узел, а не домашний ПК

При терминальной работе клиент 1С исполняется на RDS-сервере. Установка платформы на ноутбук сотрудника не меняет этот процесс. В ферме узлы могут иметь разные наборы пакетов и настроек.

1. Определите RDS-узел и SessionId пользователя.
2. Прочитайте ExecutablePath процесса командами выше.
3. Проверьте пакет и опубликованный путь RemoteApp на каждом задействованном узле.
4. После согласованного изменения перезапустите именно приложение пользователя, сохранив его работу.
5. Повторите вход на каждом целевом узле фермы.

Не завершайте все сеансы ради проверки одного клиента. Если база работает напрямую на администраторском ПК, это не подтверждает исправность опубликованного приложения фермы.

Linux: сопоставьте живой процесс с реальным пакетом

Где: Сервер или клиент Linux, где запущен проверяемый компонент. Зачем: Увидеть PID и аргументы процессов 1С.

ps -eo pid,user,args | grep -E '[r]agent|[r]mngr|[r]phost|[1]cv8c|[1]cv8'

Ожидаемый результат: Список процессов. Выберите нужный узел/роль; наличие нескольких каталогов версий не означает, что все они используются.

Где: Тот же узел, с правами чтения выбранного процесса. Зачем: Узнать фактический исполняемый файл.

read -r -p 'PID нужного процесса: ' pid_1c
readlink -f "/proc/$pid_1c/exe"

Ожидаемый результат: Путь живого процесса либо ошибка доступа/исчезнувший PID. Не запускайте серверный бинарный файл с неподтверждённым параметром ради получения версии.

Где: Debian/Astra-подобная система с пакетной установкой. Зачем: Сопоставить найденный файл с установленным пакетом.

read -r -p 'Полный путь из предыдущей команды: ' exe_1c
dpkg-query -S "$exe_1c"

Ожидаемый результат: Пакет-владелец файла либо отсутствие соответствия. Для распакованной установки данных dpkg может не быть.

Где: Та же система, после определения имени пакета. Зачем: Прочитать его точную версию.

read -r -p 'Имя найденного пакета: ' package_1c
dpkg-query -W -f='${Package} ${Version} ${Architecture}\n' "$package_1c"

Ожидаемый результат: Версия и архитектура пакета. Сверьте их с процессом и данными кластера; чужой установленный пакет не доказывает версию нужной службы.

Для RPM-систем используйте штатный учёт их пакетов. Путь каталога и версия пакета полезны вместе; если файлы менялись вне пакетного механизма, потребуется проверка целостности и происхождения. На Linux выбор клиента по полному пути устраняет тот же класс ошибок, что и в Windows.

HTTP, веб-клиент и модуль публикации

При входе через браузер на пользовательском ПК нет локального 1cv8c, который можно «исправить переустановкой». Проверяйте серверную цепочку: URL → веб-сервер/модуль публикации → целевой кластер.

• Куда ведёт конкретный URL и какую информационную базу он публикует.
• Из какого комплекта платформы загружается модуль веб-сервера.
• Соответствует ли публикация целевому кластеру после обновления или переноса.
• Есть ли старый backend за обратным прокси или балансировщиком.

Для тонкого клиента по HTTP автоматическое получение обновления зависит от релиза, публикации, доступного дистрибутива и прав. Официальное описание изменений в 8.3.26 относится к этому механизму; оно не обещает универсальное исправление любого прямого подключения.

Не подменяйте DLL/SO вручную между комплектами и не меняйте публикации без копии настроек и окна работ. Отдельная инструкция — публикация 1С на веб-сервере.

Разрядность и внешние компоненты

Совпадение полного релиза платформы и одинаковая разрядность всех компонентов — разные вопросы. Нельзя диагностировать эту ошибку правилом «сервер64бит, значит клиент32бит запрещён».

Разрядность выбирают с учётом ОС, внешних компонент, COM и драйверов. Установка x64 вместо нужного x86 может устранить один выбранный путь запуска, но нарушить работу интеграции. Аналогично смена платформы под существующим COM-коннектором требует отдельной проверки его регистрации и вызывающего приложения.

Кроссплатформенные возможности описаны фирмой 1С; реальные ограничения проверяют по установленному релизу и применяемым компонентам.

Когда действительно менять серверную платформу

Если целевой сервер должен остаться на согласованном релизе, установите соответствующий клиент. Если утверждён переход всей системы, подготовьте общее изменение, а не обновление «первого найденного агента».

1. Совместимость платформы, конфигурации, ОС, СУБД и расширений.
2. Копии данных и настроек с проверенным восстановлением.
3. План для всех узлов кластера, веб-модулей, интеграций, RAS и инструментов администрирования.
4. Окно работ и порядок завершения пользовательских сеансов.
5. Клиентские комплекты и управляемые ярлыки для пользователей.
6. Приёмка и план возврата, учитывающий выполненные изменения данных.

Откат одного exe не отменяет возможное изменение структуры данных. Не давайте универсальную команду массового restart или downgrade без конкретного проекта. Общая подготовка разобрана в статье о настройке сервера 1С.

Три прикладных сценария

Это учебные сценарии, не отчёты о выполненном ремонте. В каждом случае сначала собирают наблюдения, затем меняют один подтверждённый источник расхождения.

Как подтвердить исправление

1. 1. Подтвердить целевой серверАдрес базы,процесс и полный релиз
2. 2. Проверить клиентРеальный путь,сеанс и сборка
3. 3. Запустить нужный файлДоверенный комплект и явный путь
4. 4. Исправить обычный запускЯрлык,стартер,RDS или публикация
5. 5. Принять работуНужная база,платформа и контрольная операция

• Совпали полные версии фактического клиента и целевого сервера.
• Пользователь открыл именно нужную базу и подтвердил платформу.
• Выполнена согласованная контрольная операция без изменения лишних данных.
• Обычный ярлык/стартер/RemoteApp выбирает тот же согласованный клиент.
• Проверены затронутые узлы, веб-публикация и необходимые интеграции.
• Старые комплекты удаляются только после проверки зависимостей.

Не считайте очистку кэша, удаление srvinfo или снятие лицензии лечением несовпадения версий. После исчезновения этой ошибки возможна другая проблема; её фиксируют и разбирают отдельно, а не продолжают случайную переустановку.

Паспорт версий и протокол проверки

Сопровождение платформы и инфраструктуры 1С

Частые вопросы