Что делать, если Конфигуратор 1С падает при редактировании пользователя?

Представьте ситуацию: вам необходимо внести изменения в права доступа или сменить пароль пользователю в консоли администрирования Конфигуратора. Вы открываете список пользователей, выбираете нужную учетную запись, дважды кликаете по ней — и в этот момент Конфигуратор мгновенно закрывается без каких-либо сообщений об ошибках. Эта проблема кажется мистической, особенно если на аналогичной тестовой базе все работает штатно. В данной статье мы разберем причины такого поведения платформы и найдем эффективный способ решения проблемы.

Анализируем симптомы и ищем отличия

Прежде всего, давайте проанализируем, что происходит «под капотом» системы в момент падения. Если мы воспользуемся инструментами мониторинга SQL-запросов (например, SQL Server Profiler), то увидим интересную картину. При обращении к списку пользователей платформа «1С:Предприятие» формирует прямой запрос к системной таблице v8users.

В проблемной базе запрос может выглядеть следующим образом:

SELECT TOP 1 
    ID, Name, Descr, OSName, Changed, RolesID, Show, Data, EAuth, AdmRole, UsSprH, Email 
FROM v8users 
WHERE ID <> @P1

Обратите внимание на поле Email. В старых версиях платформы (до 8.3.15) этого поля в таблице v8users просто не существовало. Оно было зарезервировано платформой для реализации функционала самостоятельного восстановления паролей пользователями. Если одна база (например, рабочая) уже «узнала» о существовании этого поля, а другая (тестовая) — еще нет, это первый сигнал о рассинхронизации структуры системных таблиц.

Почему происходит падение (Access Violation)

Падение без ошибки обычно указывает на критическую ошибку обращения к памяти. Проанализируем ситуацию: программный код Конфигуратора ожидает одну структуру данных, а при получении ответа от SQL-сервера сталкивается с другой или некорректно обрабатывает смещения в памяти. Это часто случается при обновлении платформы, когда обновление метаданных самой информационной базы прошло не до конца или с ошибками.

Важно понимать, что таблица v8users является системной. Программист не имеет к ней доступа через дерево метаданных в дереве конфигурации. Платформа управляет этой таблицей самостоятельно. Попытки вручную удалять колонки через SQL-менеджмент консоль (например, ALTER TABLE v8users DROP COLUMN Email) приведут лишь к тому, что 1С начнет выдавать явную ошибку о нехватке поля, но проблему «вылета» это не решит.

Разбираем причины появления поля Email

Поле Email тесно связано с настройками информационной базы. Если вы перейдете в меню Администрирование — Настройка параметров информационной базы, вы можете найти там опции, касающиеся восстановления паролей. В некоторых релизах платформы (особенно в ветках 8.3.18–8.3.22) наблюдался баг: даже если восстановление пароля отключено, конфигуратор пытался валидировать поле Email, что приводило к сбою, если внутренняя логика платформы разошлась с физической структурой БД.

Также в запросе часто фигурирует поле UsSprH. Оно отвечает за внешнюю аутентификацию (OpenID Connect). Если база данных была создана очень давно и прошла через десятки обновлений платформ, системные таблицы могли накопиться в «переходном» состоянии.

Метод решения: принудительная реструктуризация

Как выяснилось на практике, стандартное «Тестирование и исправление» (ТиИ) с галочкой «Реструктуризация таблиц информационной базы» не всегда помогает в случае с системными таблицами вроде v8users. Это происходит потому, что ТиИ проверяет объекты метаданных, созданные пользователем, но может игнорировать глубокие системные механизмы.

Рассмотрим проверенный «лайфхак», который заставляет платформу полностью пересчитать хэш структуры всей базы данных и обновить служебные записи в таблице Params.

Пошаговая инструкция «Мета-хака»:

1. Откройте Конфигуратор в монопольном режиме.
2. Выберите любой малозначимый объект метаданных, например, какой-нибудь справочник (пусть это будет Справочник.ФизическиеЛица или любой другой).
3. Добавьте в него новый реквизит с произвольным именем, например, ВременныйРеквизитДляСинхронизации (тип значения не важен).
4. Нажмите F7 (Обновить конфигурацию базы данных). На этом этапе 1С увидит изменение структуры и инициирует процедуру Incremental Update. Платформа будет вынуждена сопоставить текущую структуру SQL-таблиц с описанием в кэше метаданных.
5. После успешного обновления удалите этот временный реквизит.
6. Снова нажмите F7 для применения изменений.

Почему это работает? При изменении структуры любого справочника платформа инициирует транзакцию, в ходе которой обновляются записи в таблице Params (в частности, DBNames и Config). Это фактически «протряхивает» всю схему базы данных, включая описания системных полей в таблице пользователей. После завершения этого процесса программный код Конфигуратора начинает корректно видеть состав колонок в v8users, и доступ к карточке пользователя восстанавливается.

Дополнительные рекомендации

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

1. Очистка серверного кэша. Иногда структура системных таблиц кэшируется в сеансовых данных на стороне сервера 1С. Попробуйте остановить службу Agent 1C:Enterprise и полностью удалить содержимое папки snccntxt в каталоге данных сервера.
2. Смена платформы. Как показывает практика, некоторые баги при отрисовке формы пользователя специфичны для конкретных релизов. Попробуйте запустить Конфигуратор на более новом (или, наоборот, более стабильном предыдущем) релизе платформы.
3. Проверка через выгрузку/загрузку .dt. Хотя в сложных случаях это не всегда помогает, выгрузка информационной базы в файл .dt и загрузка в новую чистую базу SQL может помочь пересоздать системные таблицы «с нуля» по правилам текущей версии платформы.

Резюме: Мы выяснили, что причиной падения является несоответствие версии структуры системных таблиц и ожиданий кода платформы. Использование метода «фиктивного изменения метаданных» позволяет синхронизировать эти уровни без риска потери данных и ручного вмешательства в SQL-таблицы, которое крайне не рекомендуется для системных объектов 1С.