← На главную

При совместной разработке конфигураций в среде 1С:Предприятие разработчики нередко сталкиваются со сбоями службы сервера хранилища конфигурации (crserver). Одна из распространенных неполадок возникает непосредственно на этапе инициализации: попытка создать новое хранилище на сервере по протоколу TCP завершается сообщением «Ошибка XML-протокола при работе с удаленным хранилищем конфигурации по причине: Ошибка преобразования данных XML». При этом существующие хранилища в том же каталоге продолжают функционировать в штатном режиме, а свободного места на диске сервера достаточно.

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

Быстрое решение: локальная инициализация и перенос на сервер

Когда требуется срочно создать хранилище конфигурации и нет времени на углубленный аудит серверных журналов, применим проверенный рабочий метод локального создания хранилища с последующим переносом файлов на сервер службы crserver.

Разберем по шагам последовательность действий:

1. Откроем нужную информационную базу в режиме «Конфигуратор» на локальном компьютере разработчика.
2. В главном меню перейдем в раздел «Конфигурация» — «Хранилище конфигурации» — «Создать хранилище...».
3. В окне мастера выберем вариант расположения «В каталоге (файловое хранилище)» и укажем любую локальную папку на диске (например, на рабочем столе или во временной директории).
4. Зададим имя пользователя с административными правами для создаваемого хранилища, укажем пароль и нажмем кнопку создания. Конфигуратор сформирует файл базы данных хранилища 1cv8ddb.1CD и служебные файлы.
5. Закроем конфигуратор или отключимся от созданного локального хранилища через меню «Конфигурация» — «Хранилище конфигурации» — «Администрирование хранилища».
6. Скопируем полученную папку со всеми созданными файлами на сервер, в корневой каталог, который обслуживается службой crserver (путь к нему задается системным параметром -d при регистрации службы). Имя перенесенной папки будет соответствовать имени хранилища при подключении.
7. Вернемся в конфигуратор и подключимся к перенесенному хранилищу стандартным образом по протоколу TCP: tcp://ИмяСервера:1542/ИмяПапки.

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

Анализ причин сбоя при удаленном создании

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

1. Недостаток прав системной учетной записи: Служба сервера хранилища выполняется от имени определенного системного пользователя (например, Local System или специальной сервисной учетной записи ОС). При обращении к существующей базе службе требуются только права чтения и модификации уже имеющихся файлов. Однако при удаленном создании служба обязана создать новую поддиректорию в корневом каталоге и инициализировать в ней структуру базы данных. Если у учетной записи службы нет прав на создание вложенных каталогов или файлов в целевой папке, операция аварийно обрывается, а клиент получает пустой или поврежденный ответ.
2. Проблемы с каталогом временных файлов (TEMP): При создании хранилища через сеть на сервер передается полный объем метаданных конфигурации. Служба crserver выполняет предварительную буферизацию и распаковку данных во временную директорию профиля пользователя службы (например, C:\Windows\System32\config\systemprofile\AppData\Local\Temp). Переполнение диска с временными файлами, квотирование или поврежденные права доступа приводят к ошибке сериализации потока.
3. Сетевые экраны, антивирусное ПО и DPI: Передача всего объема метаданных конфигурации по незашифрованному TCP-порту (по умолчанию 1542) представляет собой непрерывный высоконагруженный поток данных. Антивирусные модули сетевой защиты, фаерволы или межсетевые экраны с глубоким анализом пакетов (DPI) могут интерпретировать этот поток как аномалию, принудительно разрывая соединение по тайм-ауту или при превышении лимита длины пакета. Клиент при разрыве сетевого потока фиксирует «Ошибку преобразования данных XML».
4. Несоответствие релизов платформы: При несовпадении номера версии и сборки платформы у клиента и службы сервера хранилища протоколы обмена могут содержать несовместимые структуры XML-сериализации. В первую очередь всегда проверяем совпадение версии утилит crserver.exe и 1cv8.exe.
5. Ошибки сериализации в платформе: В отдельных версиях платформы (в частности, сборках ветки 8.3.24) присутствуют платформенные нюансы сериализации тяжелых конфигураций с большим количеством расширений или сложными типами данных при первичном создании базы через TCP.

Диагностика и системное устранение проблемы

Разберем шаги, которые позволят локализовать техническую неисправность и вернуть возможность удаленного создания хранилищ без применения обходных путей:

1. Настройка технологического журнала: Сконфигурируем сбор событий технологического журнала на сервере и на компьютере разработчика. Для этого создадим файл logcfg.xml с отбором событий EXCP и ERR по процессам crserver и 1cv8. В логах технологического журнала вместо общей формулировки об ошибке XML будет зафиксирована исходная причина (например, код системной ошибки операционной системы «Access denied» или сбой создания временного файла).
2. Проверка прав на файловую систему: Откроем свойства корневого каталога хранилищ на сервере и предоставим пользователю, под которым работает служба сервера хранилища, права уровня «Полный доступ» с обязательным наследованием на все дочерние объекты. Аналогичные права предоставим на системный каталог %TEMP% соответствующей учетной записи, предварительно очистив его от устаревших временных файлов.
3. Настройка антивирусных исключений: Добавим исполняемый файл crserver.exe, каталог расположения хранилищ и используемый TCP-порт (стандартно 1542) в списки исключений антивирусных мониторов и брандмауэра.

Альтернативные способы организации хранилища

Если служба хранилища по протоколу TCP регулярно демонстрирует нестабильность при работе по сети, рассмотрим более надежные варианты организации совместной разработки:

1. Публикация хранилища по протоколам HTTP/HTTPS: Подключение к серверу хранилища через веб-сервер (Apache или Microsoft IIS) с использованием модуля wslogr и файла дескриптора .1ccr значительно стабильнее прямого TCP-соединения. Веб-сервер поддерживает шифрование TLS/SSL, автоматическое сжатие пакетов и корректно обрабатывает разрывы связи и ограничения на максимальный размер передаваемого тела запроса (параметры maxAllowedContentLength в IIS или LimitRequestBody в Apache).
2. Переход на системы контроля версий (Git): Для современных конфигураций на управляемых формах эффективной альтернативой стандартному механизму хранилищ является выгрузка метаданных в иерархию файлов и ведение версионирования через Git при помощи 1C:Enterprise Development Tools (EDT) или стандартных средств командной строки платформы. Это исключает сетевые сбои служб хранилища и предотвращает риск повреждения файла базы данных 1cv8ddb.1CD.