В практике системного администрирования и поддержки пользователей 1С часто возникают ситуации, когда база данных перестает запускаться без видимых на то причин. Особенно неприятно, когда это происходит с файловой версией 1С:Управление торговлей 10.3, которая годами работала стабильно. В данной статье мы разберем сложный случай, когда программа зависает сразу после ввода имени пользователя, и выясним, как это связано с конфигурацией сетевого оборудования сервера или рабочей станции.
Типичная ситуация выглядит следующим образом: пользователь выбирает свою учетную запись, вводит пароль, и окно 1С переходит в состояние «Не отвечает». При этом попытки зайти в Конфигуратор заканчиваются тем же результатом. Очистка кэша, переустановка платформы и даже перенос базы на другой компьютер (где она работает исправно) указывают на то, что проблема кроется не в самой базе данных, а в операционной системе и окружении.
Для того чтобы понять, что происходит «под капотом» платформы в момент зависания, необходимо проанализировать Технологический журнал. Рассмотрим фрагмент лога, который проливает свет на причину сбоя:
16:40.608005-0,EXCP,2,process=1cv8c,OSThread=5032,Exception=0874860b-2b41-45e1-bc2b-6e186eb37771,Descr='src\LicenseBaseImpl.cpp(3546):
0874860b-2b41-45e1-bc2b-6e186eb37771: Ошибка программного лицензирования. Неверный формат файла программного лицензирования: file://C:/ProgramData/1C/licenses/file0.lic'
Ошибки в модулях CryptoGeneralHelpers.cpp и LicenseBaseImpl.cpp однозначно указывают на проблемы в подсистеме защиты и лицензирования. Платформа не может корректно прочитать или сопоставить файл лицензии с текущим оборудованием.
Проанализируем ситуацию глубже. Программная лицензия 1С (особенно в базовых версиях) жестко привязана к ключевым параметрам компьютера: имени ПК, серийному номеру системного раздела, параметрам процессора и, что критически важно, к MAC-адресам сетевых адаптеров.
При каждом запуске платформа 1С выполняет опрос оборудования через службу WMI (Windows Management Instrumentation). Если в системе внезапно появляется огромное количество виртуальных сетевых устройств (например, Tap-Windows adapter V9), процесс сбора информации о них замедляется в геометрической прогрессии. Рассмотрим причины «размножения» таких адаптеров:
Когда количество таких устройств достигает сотен (как в рассматриваемом случае — около 200 единиц), WMI-запрос платформы 1С уходит в глубокий тайм-аут, что внешне выглядит как полное зависание интерфейса.
Если мы обнаружили в диспетчере устройств сотни одинаковых адаптеров, удалять их вручную по одному — крайне неэффективная задача. Рассмотрим, как автоматизировать этот процесс с помощью консольной утилиты Microsoft DevCon.
Выполним следующие шаги:
devcon.exe.devcon findall =net.
devcon remove *TAP0901*
(Идентификатор *TAP0901* может отличаться в зависимости от версии драйвера, его можно уточнить в свойствах устройства).После выполнения этой команды система очистит дерево устройств, и WMI-опрос снова станет мгновенным.
Проанализируем более современный метод очистки, не требующий скачивания сторонних утилит. В ОС Windows 8.1 и выше мы можем воспользоваться мощью PowerShell.
Разберем по шагам выполнение скрипта:
# Получаем список всех сетевых адаптеров, чье имя содержит "Tap-Windows"
$adapters = Get-WmiObject Win32_PnPEntity | Where-Object { $_.Name -match "Tap-Windows" }
# Перебираем их и удаляем
foreach ($dev in $adapters) {
Write-Host "Удаляем устройство: $($dev.Caption)"
# Вызов метода удаления через WMI
$dev.Terminate()
}
Важно: После такой массовой чистки крайне рекомендуется выполнить перезагрузку компьютера, чтобы база данных PNP (Plug and Play) корректно обновила свое состояние.
Если удаление через диспетчер устройств не помогает, или устройства появляются снова, нам необходимо очистить записи о них в реестре Windows. Информация о сетевых интерфейсах хранится в ветке:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}
Рассмотрим структуру этой ветки. В ней находятся подразделы с именами 0000, 0001 и так далее. Каждый подраздел соответствует сетевому адаптеру. Мы можем проанализировать параметр DriverDesc в каждом подразделе и, если он соответствует фантомному Tap-Windows adapter, удалить весь подраздел.
Будьте осторожны: Ошибочное удаление подразделов физических сетевых карт может привести к потере доступа в интернет.
Выясним важный нюанс: после того как мы удалим лишние адаптеры и 1С начнет запускаться, программа может выдать сообщение: «Лицензия не обнаружена» или «Привязка к компьютеру нарушена». Это происходит потому, что «хеш-сумма» оборудования изменилась (количество и состав сетевых карт теперь иные).
В этом случае потребуется повторная активация:
Чтобы ситуация не повторилась, проанализируем настройки системы. Часто повторное размножение адаптеров происходит из-за работы нелегального ПО для активации Windows. Рекомендуется заменить такие активаторы на легальные ключи или использовать методы активации, не создающие виртуальных сетевых интерфейсов.
Также стоит отключить автоматическую установку драйверов для конкретных неопознанных устройств через групповые политики (gpedit.msc), если вы не уверены в их происхождении. Это предотвратит попытки системы бесконечно устанавливать драйвер на виртуальное устройство, которое работает некорректно.
Подводя итог, отметим, что зависание 1С при запуске — это не всегда проблема кода или данных. Системный подход к анализу техжурнала и состояния оборудования позволяет быстро найти истинную причину в виде перегруженного списка сетевых устройств и вернуть работоспособность программы в кратчайшие сроки.