Переход на 64-разрядную версию клиентского приложения 1С:Предприятие — это логичный шаг для повышения стабильности работы с большими конфигурациями, требующими значительного объема оперативной памяти. Однако системные администраторы часто сталкиваются с ситуацией, когда после установки 64-битного клиента программа перестает видеть лицензию, хотя 32-битный клиент на том же компьютере продолжает работать без проблем. Рассмотрим подробно причины этого поведения и разберем по шагам, как настроить систему для корректной работы.
Одной из самых распространенных причин является то, что 32-разрядные и 64-разрядные приложения в операционной системе Windows обращаются к разным программным директориям. Проанализируем, где платформа ищет настройки для поиска аппаратных ключей HASP.
Для 32-битного клиента основным местом хранения файла nethasp.ini является папка: C:\Program Files (x86)\1cv8\conf. Когда вы устанавливаете 64-битный клиент, он ищет настройки в совершенно другом месте: C:\Program Files\1cv8\conf. Если настройки сетевого ключа (IP-адрес сервера лицензий) прописаны только в папке для x86, 64-битный клиент попытается найти ключ с помощью широковещательного запроса (broadcast). В сложных сетях или при наличии маршрутизаторов такие запросы часто блокируются, и клиент выдает ошибку лицензирования.
Для решения этой проблемы выполним следующие действия:
C:\Program Files (x86)\1cv8\conf и скопируем файл nethasp.ini.C:\Program Files\1cv8\conf.[NH_COMMON] и [NH_TCPIP]. Убедимся, что параметр NH_TCPIP = ENABLED раскомментирован, а в параметре NH_SERVER_ADDR указан точный IP-адрес сервера, где установлен аппаратный ключ.Многие серверы и рабочие станции годами работают на старых версиях драйверов HASP (например, версии 6.x), которые были установлены еще в эпоху доминирования 32-битных систем. Выясним, как это влияет на работу современных приложений. Хотя 32-битный процесс платформы может успешно взаимодействовать со старым драйвером через механизмы совместимости, 64-битный процесс 1cv8.exe требует более строгого соблюдения протоколов взаимодействия.
Проанализируем ситуацию: в диспетчере устройств ключ может отображаться как исправный, но 64-битный уровень абстракции драйвера не передает данные приложению. Рекомендуется обновить драйвер Sentinel HASP до актуальной версии (не ниже 8.x). Это обеспечит корректную работу 64-битного стека протоколов.
Рассмотрим механизм получения лицензий. Лицензия может быть получена клиентом двумя способами: напрямую от менеджера лицензий (HASP LM) или через сервер 1С:Предприятия (процесс rphost). Если в настройках информационной базы (в консоли администрирования серверов 1С) установлена галочка «Разрешить выдачу лицензий сервером 1С:Предприятия», то поиск ключа осуществляет не клиент, а сервер.
Однако, при переходе на x64-клиента, иногда возникает конфликт приоритетов. Если клиент не может достучаться до сервера лицензий напрямую, а сервер 1С по какой-то причине считает, что лицензий в его пуле больше нет (или они заняты 32-битными сессиями), 64-битный клиент не сможет запуститься. Проанализируем параметры запуска: иногда стоит временно отключить выдачу лицензий сервером, чтобы проверить, сможет ли 64-битный клиент найти ключ самостоятельно при правильно настроенном nethasp.ini.
Если вы используете конфигурации категории «1С:Совместимо», они часто включают в себя дополнительные системы защиты (например, СЛК — Система Лицензирования и Конфигурирования). Разберем, в чем заключается подвох при смене разрядности.
Многие старые отраслевые решения используют внешние компоненты (DLL), которые жестко скомпилированы под 32-битную архитектуру. Когда вы запускаете 64-битную платформу, она физически не может загрузить 32-битную библиотеку защиты в свое адресное пространство. В результате платформа выдает ошибку, которая на первый взгляд выглядит как отсутствие лицензии «1С», хотя на самом деле «отвалилась» защита самой конфигурации.
Посмотрим на примеры таких ситуаций:
В этом случае решением будет либо поиск 64-битной версии внешней компоненты у разработчика решения, либо (как часто советуют на форумах) возврат к 32-битному клиенту, если использование x64 не продиктовано критической нехваткой памяти.
Операционная система Windows использует разные ветки реестра для 32- и 64-битных приложений (механизм Registry Redirector). Проанализируем влияние этого фактора. 32-битные приложения видят ветку HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node, в то время как 64-битные обращаются напрямую к HKEY_LOCAL_MACHINE\SOFTWARE.
Если параметры защиты или пути к программным лицензиям (в случае их использования) были прописаны инсталлятором некорректно, 64-битный клиент может их просто не увидеть. Также зафиксированы случаи, когда для корректной инициализации системы лицензирования 64-битный клиент требовалось один раз запустить от имени администратора. Это позволяет платформе зарегистрировать необходимые COM-объекты в «чистой» 64-битной ветке реестра.
Выясним влияние безопасности ОС на лицензирование. Система DEP (Data Execution Prevention) в 64-битных версиях Windows работает более агрессивно. Попытки драйвера защиты или защищенного модуля конфигурации выполнить код в областях памяти, помеченных как «только данные», могут блокироваться. Это приводит к непредсказуемым ошибкам, включая «Лицензия не обнаружена».
Попробуем добавить исполняемый файл 64-битного клиента C:\Program Files\1cv8\номер_версии\bin\1cv8.exe в исключения DEP или временно перевести DEP в режим работы «только для основных программ и служб Windows» для проверки этой гипотезы.
Подводя итог, можно сказать, что сами по себе клиентские лицензии (аппаратные USB-ключи серии HASP HL) не делятся на 32-битные и 64-битные. Они универсальны. Проблема всегда кроется в транспорте — в том, как 64-битное приложение пытается достучаться до этого ключа. Если вы столкнулись с такой проблемой, рекомендуем следующий алгоритм действий:
nethasp.ini во всех папках conf.Если выполнение данных шагов не помогает, а конфигурация «вылетает» при обновлении на 32-битном клиенте из-за нехватки памяти (как упоминалось в обсуждении), стоит рассмотреть вариант выполнения обновления непосредственно на сервере в режиме 64-битного rphost, оставив пользователям привычные 32-битные клиенты для повседневной работы.