При активной разработке в среде 1С:Предприятие 8.3, особенно при использовании механизма расширений, программисты могут столкнуться с крайне неприятной ситуацией. В момент попытки сохранить конфигурацию или обновить метаданные система «замирает», выводя модальное окно с текстом: «Пожалуйста подождите! Выполняется сохранение информации об ошибке». Это состояние может длиться бесконечно, блокируя работу Конфигуратора. Проблема специфична тем, что стандартные методы, такие как очистка пользовательского кэша, часто оказываются бессильны.
В этой статье мы подробно разберем, почему возникает этот сбой, как восстановить работоспособность базы и какие превентивные меры помогут избежать подобных ситуаций в будущем. Рассмотрим ситуацию на примере базы на SQL-сервере, так как именно там чаще всего проявляются конфликты при фиксации изменений.
Проанализируем, что происходит «под капотом» платформы в этот момент. Сообщение о сохранении информации об ошибке генерируется внутренним обработчиком исключений ядра 1С. Когда происходит критический сбой (например, нарушение ссылочной целостности в таблицах метаданных или ошибка компиляции на уровне сервера приложений), платформа пытается создать дамп памяти (отчет об ошибке). Однако, если причина сбоя связана с блокировками в СУБД или повреждением временных таблиц, сам процесс записи этого отчета зацикливается.
Основные факторы, провоцирующие проблему:
ConfigSave: В эту таблицу SQL-базы записываются изменения до того, как они будут окончательно приняты основной конфигурацией.Рассмотрим ситуацию, когда чистка локального кэша пользователя (папки Local\1C\1cv8) не помогла. В серверных базах критически важно очистить данные на стороне сервера приложений. Выполним следующие шаги:
services.msc).C:\Program Files\1cv8\srvinfo.reg_1541).snccntx и прочие временные хранилища сеансов. Важно: для полной очистки можно удалить содержимое папок с временными данными, но будьте осторожны с файлами настроек самого кластера.Этот метод позволяет сбросить некорректные состояния скомпилированных расширений, которые платформа пытается использовать при сохранении.
Если очистка кэша не помогает и база на SQL по-прежнему выдает ошибку, воспользуемся проверенным практическим методом — временным переходом в файловый режим. Проанализируем этот алгоритм:
.dt. Если Конфигуратор полностью заблокирован, можно попробовать создать копию базы средствами SQL Server, но лучше использовать механизм выгрузки..dt..dt.Этот метод работает, потому что при переходе из SQL в файловый режим и обратно происходит полная реструктуризация внутренних таблиц 1С, что очищает «мусорные» записи в системных таблицах конфигурации.
Для опытных администраторов и разработчиков, имеющих доступ к SQL Server Management Studio (SSMS), существует более радикальный, но быстрый способ. Разберем его по шагам:
Внимание: Перед любыми манипуляциями с SQL-таблицами обязательно создайте полную резервную копию базы данных!
ConfigSave:
SELECT * FROM ConfigSave
DELETE FROM ConfigSave
После выполнения этой команды Конфигуратор «забудет» о неудачной попытке сохранения, и вы сможете зайти в него штатно, чтобы удалить или переподключить расширение.
Если графический интерфейс Конфигуратора виснет сразу при открытии окна расширений, попробуем использовать параметры запуска. Платформа 1С позволяет управлять расширениями через командную строку. Рассмотрим пример команды для удаления проблемного расширения:
"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" DESIGNER /S "Server\BaseName" /DeleteExtension "ИмяРасширения" /Out "log.txt"
Здесь /DeleteExtension принудительно удаляет указанное расширение, минуя многие проверки графической оболочки. Результат операции можно будет увидеть в файле log.txt.
Проанализируем еще несколько факторов, которые могут влиять на появление окна «Выполняется сохранение информации об ошибке»:
.dmp блокируется антивирусом, который считает подозрительной запись большого объема данных во временные папки. Попробуйте временно отключить мониторинг или добавить папки 1С в исключения.C: сервера приложений. При генерации дампа ошибки системе может потребоваться несколько гигабайт пространства. Если места нет, процесс записи уходит в бесконечный цикл.1С:Розница 2.3, убедитесь, что режим совместимости расширения совпадает с режимом совместимости основной конфигурации. Различия в этих параметрах часто приводят к краху процесса dbgs или основного потока платформы.Подводя итог, можно сказать, что данная проблема почти всегда связана с невозможностью платформы корректно обработать исключительную ситуацию при записи метаданных. Использование связки «очистка серверного кэша + манипуляции с файловой копией» является наиболее безопасным и эффективным алгоритмом решения задачи.