Падение АОС с диагностикой «Cursor bulding error 2»

[AndrewRa]

Всем доброго времени суток!

В рабочее время с частотой примерно 1 – 3 раза в день перегружается основной АОС.
При этом, в eventlog сервера пишется ошибка:
Object Server 01: Unexpected situation
More Information: Cursor bulding error 2
Ошибку устойчиво воспроизвести не можем.

Зависимость падений от выполнения каких-либо периодических пакетных заданий или регулярных операций не выявлена.
Падения начались в начале декабря, когда был внедрен проект, активно использующий открытие сессий АХ на терминальном сервере…

Наши шаги:

1. На сервере АОСа настроено снятие дампов памяти при падении процесса Ax32Serv.exe (с помощью утилиты Debug Diagnostic Tool 1.2).

2. С помощью инструмента WinDbg (x64) из пакета Debugging Tools for Windows (x64) проанализированы полученные дампы и выявлено место в коде АХ, которое вызывает ошибку (Процедура анализа дампов).
Анализ дампа всегда указывает на один и тот же метод класса, в качестве клиентской машины всегда указан терминальный сервер.

3. Настроено логгирование выполнения всех этапов найденного метода в таблицу.
В результате сопоставления данных лога и анализа дампов выявлено конкретное место в коде метода, в котором происходит падение.
Но ничего подозрительного в коде не обнаружено – просто попытка доступа к объекту args.record()!..

У нас Axapta 2009 RU 5.

Может быть, кто-то сталкивался с подобной ситуацией?
В чем может быть причина падений?

[macklakov]

Цитата:

Сообщение от AndrewRa

активно использующий открытие сессий АХ

Что конкретно под этим имеется в виду? Клиентские сесси плодит?

Цитата:

Сообщение от AndrewRa

просто попытка доступа к объекту args.record()!..

А что там передается и откуда?

[AndrewRa]

По поводу терминальных сессий:
Имеется в виду, что всегда, когда имеет место падение АОС, анализ указывает на метод Main() определенного класса (всегда одного и того же), используемый формой, которую открывает удаленный пользователь, запустивший клиент АХ на терминальном сервере.
В декабре были разработаны отдельные формы для удаленных пользователей, так что падения могут быть обусловлены новым функционалом, а не изменениями в инфраструктуре.

По поводу объекта args.record():
Выявленный метод Main класса активно используется как в новых формах для удаленных пользователей, так и в существующих.
В аргументе args.record() передается запись таблицы источника данных формы.
Анализ указывает как место падения простую строку кода: if (args.record().RecId), т.е. - есть ли запись.
Кстати, для класса свойство RunOn установлено в значение Server.

[macklakov]

Спасибо, так понятнее. Рекомендую вам воспользоваться услугами квалифицированного AX разработчика. Я бы попробовал, для начала, что-то вроде:
if (args && args.record())
Но без доступа в систему это игра "в угадайку"

[Logger]

Соглашусь.
Когда мы только стартовали на ax2009 то бывали проблемы с кодом который на сервере пытался использовать курсоры созданные на клиенте.

попробуйте вариант Маклакова. Если не получится то можно, указанные анализх вынести в статический метод помеченный как client server - тогда проверка на клиенте пойдет. но это уже танцы с бубном.

[AndrewRa]

По поводу проверки if (args && args.record()):
На самом деле у нас так и есть:
boolean argsDataSetCorrect;
...
if (args)
{
if (args.dataset() == tablenum(SalesTable))
{
argsDataSetCorrect = true;
}
}
if (argsDataSetCorrect && args.record().RecId)
...
Для локализации места падения мы вынесли дополнительные проверки в отдельный блок кода.
Ранее я упростил код, чтобы не замутнять...

По поводу совета Логгера:
Спасибо! Попробуем.
О результатах напишу.

[macklakov]

RecId зачем?

[AndrewRa]

Чтобы проверить, есть ли текущая запись.
После этого If идут разные алгоритмы обработки.

Кстати, уже вынесли проверки в отдельный метод с модификатором Client (выполняемый на клиенте).
Ждем результатов...

[oip]

Коллеги имеют в виду написать вместо args.record().RecId просто args.record().

См. также: if (record) vs if (record.RecId)

[AndrewRa]

После выноса проверки в клиентский метод анализ дампа очередного падения указал на другое место!
Спасибо за советы, - ситуация сдвинулась с места!

Теперь падение происходит дальше по коду, просто при переначитке записи: salesTable.reread();
Может, попробовать перенести на клиент и эту часть функционала, или даже весь класс (свойство класса RunOn)?

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

Я тут подумал, на терминальном сервере у нас установлена другая операционка - Windows Server 2012 R2 (а на сервере АОСа Windows Server 2008 R2).
Не могут ли с этим быть связаны подобные нерегулярные ошибки при чтении на сервере созданного на клиенте курсора?

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

По поводу "написать вместо args.record().RecId просто args.record()" - уже пробовал, в первоначальном варианте было именно args.record().
Читал где-то на форуме, что это может помочь (хотя, судя по приведенной Олегом ссылке на тему, большинство за args.record())...

[macklakov]

Цитата:

Сообщение от AndrewRa

Читал где-то на форуме, что это может помочь (хотя, судя по приведенной Олегом ссылке на тему, большинство за args.record())...

В вашем случае, может приходить не cursor а null. У null RecId быть не может. Система на такое ругнется, как минимум.
Но это была просто попытка угадать. Без возможности посмотреть на то, что происходит на форме и вдумчиво оттестировать взаимодействие под дебагером, о чем-то конкретном говорить сложно.
P.S. Да и на то, как клиент установлен, тоже интересно взглянуть было бы.

[AndrewRa]

Внимательно прочитал системные требования (за ноябрь 2013):
Там явно не сказано о совместимости АХ2009 и Windows Server 2012 (можно не выше Windows Server 2008 R2)!!!
Значит, сам MS не дает гарантий корректной работы ах2009 на этой операционке....