Как исправить ошибку «Индекс находится за границами массива» при настройке отборов в журнале регистрации 1С

← На главную

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

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

Выясняем причину: почему возникает ошибка?

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


{ВнешняяОбработка.StandardEventLog.Форма.PropertyContentsEditor.Форма(260)}: Индекс находится за границами массива
ParentDataPath = ParentDataPath + RealDataStrings[i];

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

Но почему в одной базе массив заполняется корректно, а в другой происходит сбой? Этому есть несколько логических объяснений:

Влияние расширений конфигурации (Extensions): Если в проблемной информационной базе подключены активные расширения, которые добавляют собственные объекты метаданных (новые справочники, документы, регистры или реквизиты), стандартный алгоритм разбора путей метаданных в платформенной обработке может дать сбой. Имена объектов из расширений часто содержат уникальные префиксы или специфические символы разделения, из-за чего функция разделения строки (split) формирует массив RealDataStrings неверной структуры и меньшей длины.
Повреждение кэша метаданных базы: Локальный кэш конфигурации на рабочем компьютере пользователя или кэш на сервере приложений «1С» может быть частично поврежден. Из-за этого платформа возвращает неверную или неполную структуру дерева метаданных при попытке построить список для интерактивного выбора.
Некорректные (битые) объекты метаданных: Ошибка может проявляться, если в структуре метаданных базы данных присутствуют «битые» ссылки на объекты. Такое случается после аварийного завершения обновления конфигурации, некорректной синхронизации данных (РИБ) или незавершенного удаления объектов конфигурации.

Архитектура стандартных обработок платформы

Многие начинающие программисты «1С» при попытке отладить эту ошибку сталкиваются с препятствием: они открывают Конфигуратор, но не находят в дереве метаданных обработку с именем StandardEventLog. Ее там действительно нет.

Дело в том, что журнал регистрации, отчет «Активные пользователи», инструменты поиска ссылок и удаления помеченных объектов встроены непосредственно в саму платформу «1С:Предприятие» в виде скомпилированных внешних обработок. Платформа обращается к ним по специальному внутреннему виртуальному протоколу v8res://.

В частности, обработка журнала регистрации физически расположена по виртуальному адресу: v8res://mngbase/StandardEventLog.epf.

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

Шаг 1. Как извлечь обработку из ресурсов платформы

Для того чтобы получить доступ к исходному коду и формам проблемной обработки, нам необходимо выгрузить файл StandardEventLog.epf из ресурсов платформы на локальный диск компьютера. Сделать это очень просто.

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


КопироватьФайл("v8res://mngbase/StandardEventLog.epf", "C:\StandardEventLog.epf");

Выполним этот код. Сразу после этого на диске C:\ появится файл StandardEventLog.epf. Теперь мы можем открыть его через Конфигуратор как обычную внешнюю обработку, увидеть структуру метаданных, макеты и все формы, включая вызывающую ошибку форму PropertyContentsEditor.

Шаг 2. Как настроить отладку извлеченной обработки

Теперь, когда у нас есть физический файл обработки на диске, мы можем легко локализовать проблему с помощью стандартного отладчика «1С»:

Откроем сохраненный файл C:\StandardEventLog.epf в режиме Конфигуратора.
Перейдем в модуль формы PropertyContentsEditor, найдем строку 260 и установим на нее точку останова.
Запустим сеанс «1С:Предприятие» в режиме отладки.
В пользовательском интерфейсе откроем нашу внешнюю обработку через главное меню: Файл -> Открыть (выбрав файл C:\StandardEventLog.epf).
Попробуем воспроизвести ошибку, открыв настройку отборов по метаданным. Отладчик мгновенно остановит выполнение кода на строке 260. Теперь мы можем детально изучить содержимое переменных RealDataStrings, i, ParentDataPath и понять, на каком именно объекте метаданных спотыкается платформа.

Способ А. Решение проблемы без изменения программного кода

Если мы не хотим вмешиваться в логику работы платформенных механизмов, стоит начать с простых шагов по очистке и диагностике базы данных. В подавляющем большинстве случаев это решает проблему, если она вызвана сбоем кэша или расширениями.

Выполним по шагам следующие действия:

Диагностика расширений: Перейдем в меню Администрирование -> Расширения и временно отключим те расширения конфигурации, которые добавляют в систему новые справочники, документы или реквизиты. Если после этого ошибка в журнале регистрации исчезает — дело в некорректной интерпретации платформой метаданных расширения. Решением будет либо обновление платформы до более актуального релиза (где эта ошибка уже исправлена разработчиками «1С»), либо переименование объектов в расширении без использования сложных префиксов.
Очистка серверного кэша: Сбои кэширования метаданных на сервере приложений — частая причина ошибок выхода индекса за границы массива. Остановим службу сервера «1С:Предприятие» и физически удалим папки с кэшем базы данных, которые расположены в каталоге srvinfo\reg_1541\ (папки с длинными UUID-именами). После этого запустим службу заново.
Очистка локального кэша пользователя: Удалим базу из списка запуска в стартере «1С» и добавим её заново — это самый простой способ полностью пересоздать локальный кэш на рабочем месте пользователя.
Тестирование и исправление (ТиИ): Запустим базу в режиме Конфигуратора, перейдем в меню Администрирование -> Тестирование и исправление. Обязательно выберем пункты «Проверка логической целостности конфигурации» и «Проверка ссылочной целостности». При обнаружении битых ссылок настроим систему на их очистку или создание дефолтных объектов. Также рекомендуется выполнить проверку базы утилитой chdbfl.exe, если используется файловый вариант базы данных.

Способ Б. Кардинальное решение через исправление кода и подмену обработки

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

Разберем по шагам, как безопасно модифицировать код и заставить систему использовать исправленную версию журнала регистрации.

Шаг 1. Модификация кода обработки. Откроем нашу выгруженную обработку StandardEventLog.epf в Конфигураторе. Перейдем в модуль формы PropertyContentsEditor на строку 260. Заменим проблемный участок кода на безопасную конструкцию, которая предварительно проверяет размерность массива:


Если i < RealDataStrings.Количество() Тогда
    ParentDataPath = ParentDataPath + RealDataStrings[i];
Иначе
    // Запишем предупреждение в Журнал регистрации или просто пропустим некорректный элемент
    ЗаписьЖурналаРегистрации("ОбходОшибкиМетаданных", УровеньЖурналаРегистрации.Предупреждение,,, 
        "Не удалось определить путь метаданных для индекса: " + Строка(i));
КонецЕсли;

Сохраним изменения в файле StandardEventLog.epf.

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

Откроем модуль управляемого приложения нашей конфигурации (или модуль обычного приложения, в зависимости от используемого режима запуска) и в обработчике события ПриНачалеРаботыСистемы пропишем следующий код:


Процедура ПриНачалеРаботыСистемы()
    
    // Путь к нашей исправленной обработке на сервере или локальном диске
    ПутьКФайлу = "C:\Fixes\StandardEventLog.epf"; 
    ФайлОбработки = Новый Файл(ПутьКФайлу);
    
    Если ФайлОбработки.Существует() Тогда
        Попытка
            ДвоичныеДанные = Новый ДвоичныеДанные(ПутьКФайлу);
            АдресХранилища = ПоместитьВоВременноеХранилище(ДвоичныеДанные);
            
            // Подключаем нашу внешнюю обработку взамен стандартной платформенной
            ВнешниеОбработки.Подключить(АдресХранилища, "StandardEventLog", Ложь);
        Исключение
            ЗаписьЖурналаРегистрации("ПодменаЖурналаРегистрации", УровеньЖурналаРегистрации.Ошибка,,, 
                "Ошибка подключения исправленной обработки: " + ОписаниеОшибки());
        КонецПопытки;
    КонецЕсли;

КонецПроцедуры

Разберем, как работает этот механизм. Метод ВнешниеОбработки.Подключить регистрирует внешнюю обработку в памяти текущего сеанса. Передав в качестве второго параметра имя "StandardEventLog", мы перекрываем стандартное системное имя. Теперь при любой попытке пользователя открыть стандартный журнал регистрации платформа вместо встроенного в нее ресурса v8res:// автоматически обратится к нашей исправленной обработке из временного хранилища.

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