← На главную

В практике администрирования 1С:Предприятие встречается парадоксальная ситуация: на одном и том же сервере в рамках RDP-сессии у пользователя успешно запускается 32-битный клиент, но 64-битный выдает ошибку «Ключ защиты не обнаружен». При этом у других пользователей обе версии работают корректно. Разберем детально, почему так происходит и как устранить эту проблему, опираясь на технические особенности поиска лицензий платформой.

Анализ механизма поиска лицензий

Для начала проанализируем, как 1С ищет лицензии. Платформа 8.3 не разделяет клиентские программные лицензии по разрядности. Это означает, что если файл .lic корректно активирован и доступен, его должны видеть обе версии платформы. Однако пути поиска и окружение для процессов x86 и x64 в операционной системе Windows могут различаться.

Рассмотрим основные места хранения лицензий, которые проверяет платформа:

1. Каталог профиля текущего пользователя: %AppData%\1C\1cv8\conf.
2. Каталог локальных настроек пользователя: %LocalAppData%\1C\1cv8\conf.
3. Общий каталог для всех пользователей: %ProgramData%\1C\licenses.
4. Каталог установки платформы (папка conf внутри каталога конкретной версии).

Шаг 1. Сбор подробной информации об ошибке

Прежде чем приступать к активным действиям, воспользуемся штатным инструментом диагностики. В окне с сообщением об отсутствии лицензии нажмем кнопку «Подробно». Проанализируем полученный текст. Нас интересуют строки, начинающиеся с «Локальный ключ защиты» и «Программная лицензия». Платформа выводит список всех путей, по которым она пыталась найти файлы .lic.

Сравним этот список для 32-битной и 64-битной версий. Если в 64-битной версии список путей короче или в нем отсутствуют сетевые пути, которые есть в 32-битной, причина кроется в конфигурационных файлах.

Шаг 2. Проверка конфигурационных файлов conf.cfg и location.cfg

Выясним, не заданы ли для разных архитектур разные правила поиска. Платформы x32 и x64 устанавливаются в разные системные каталоги:

• Для x32: C:\Program Files (x86)\1cv8\conf
• Для x64: C:\Program Files\1cv8\conf

Проверим содержимое файла conf.cfg в обоих каталогах. Если в одном из них прописан параметр ConfLocation, указывающий на альтернативное место хранения настроек, это может привести к тому, что x64 клиент просто «не знает», где искать лицензии.

Также обратим внимание на файл location.cfg. Этот файл используется, если лицензии были намеренно перенесены в нестандартный каталог. Разберем пример настройки в этом файле:

location=C:\CustomLicensePath\

Если такой файл существует только в каталоге Program Files (x86), то 64-битная платформа о нем не узнает. Необходимо обеспечить идентичность настроек в общих каталогах conf для обеих архитектур.

Шаг 3. Права доступа к системным папкам

Проанализируем ситуацию с правами доступа. Программные лицензии чаще всего хранятся в C:\ProgramData\1C\licenses. Несмотря на то, что это общая папка, механизмы обращения к ней из 32-битных и 64-битных приложений могут различаться из-за особенностей виртуализации (UAC Virtualization) или специфических ограничений безопасности в RDP-сессии.

Убедимся, что у проблемного пользователя есть права «Чтение» и «Просмотр содержимого» на папку ProgramData\1C\licenses и на все файлы внутри неё. Иногда бывает, что файл лицензии был создан под конкретным пользователем и не имеет разрешений для группы «Пользователи».

Шаг 4. Очистка пользовательского кэша и профиля

Часто причиной сбоя становятся «мусорные» или поврежденные файлы в профиле пользователя. Платформа 1С кэширует информацию о найденных лицензиях. Если в профиле пользователя завалялся старый файл лицензии или поврежденный конфигурационный файл, 64-битная версия может столкнуться с ним первой и прекратить дальнейший поиск.

Выполним очистку по следующему алгоритму:

1. Завершим все сеансы пользователя 1С.
2. Удалим содержимое каталогов:
   • %AppData%\1C\1cv8
   • %LocalAppData%\1C\1cv8
3. Проверим наличие файлов .lic в корне этих каталогов. Если они там есть и не являются актуальными — удалим их.

Шаг 5. Отключение поиска HASP-ключей

Даже если используются программные лицензии, 1С по умолчанию пытается опросить USB-ключи защиты (HASP). В 64-битной среде время ожидания ответа от драйвера HASP или сетевого менеджера лицензий может отличаться. Чтобы ускорить процесс и исключить конфликты, принудительно отключим поиск ключей HASP в настройках запуска конкретной базы.

Для этого в списке баз нажмем «Изменить» -> «Далее» -> «Далее» и в поле «Дополнительные параметры запуска» введем:

/UseHasp-

Или отредактируем файл nethasp.ini, установив параметр NH_USE_HASP = Disabled. Это заставит платформу сразу переходить к поиску программных лицензий.

Шаг 6. Радикальное решение: переустановка платформы

Если вышеописанные шаги не помогли, воспользуемся проверенным методом полной переустановки. Разберем последовательность действий:

1. Удалим все версии платформы 1С через «Панель управления».
2. Вручную удалим каталоги C:\Program Files\1cv8 и C:\Program Files (x86)\1cv8.
3. Перезагрузим сервер для очистки заблокированных системных вызовов.
4. Установим сначала 64-битную платформу, затем 32-битную (если она необходима для работы с COM-объектами или внешними компонентами).
5. При установке убедимся, что выбран компонент «Модули расширения веб-сервера», если это требуется, но главное — установим драйвер защиты, если используются аппаратные ключи, или пропустим его, если используются только программные.

Таким образом, проблема чаще всего кроется не в самой платформе, а в разнице путей конфигурации (conf.cfg) или специфических правах доступа пользователя в среде RDP. Последовательная проверка путей из окна «Подробно» позволяет локализовать место разрыва в цепочке поиска лицензии.