Падает АОС - ax32Serv buffer overrun...

[Jony]

Добрый вечер.

Поиском не нашел нужного ответа, пишу по новой.

Проблема такая: переодически, без видимой закономерности, возникает ошибка переполнения буфера. Выпадает диалоговое окошко (Тоже самое что описано по этой ссылке Buffer Overrun)

В систем-лог создается запись:

Application popup: Microsoft Visual C++ Runtime Library : Buffer overrun detected!

Program: ... Files\Navision\Axapta Server\Bin\Ax32Serv.exe

A buffer overrun has been detected which has corrupted the program's
internal state. The program cannot safely continue execution and must
now be terminated.

кто когда-либо решал подобную проблему, помогите справиться, буду очень благодарен.

На сервере SQL стоит только служба sql, на сервере AOS, только служба аоса.
на машине sql стоит w2003\ sql2000std
на машине aos стоит w2003\ приложение ax3sp4 + kr3

Из настроек аоса меняли только Buffer size на закладке Database в 64кб


может како-нибуть некоректрый код вызывать такое падение аоса? хоть какие нибуть мыли..

[zZ_TOP_Zz]

А может попробовать еще увеличить размер буфера. У нас на некоторых АОСах стоит размер буфера 250

[Sada]

Еще есть какие нибуть идеи? А то начинает это доставать.

[zZ_TOP_Zz]

ну лично у меня нет идей больше

[Sada]

На теперяшнем месте работы еще до меня ставили и кэш 250 и всяка разна. Не помогало. Думали накатить КР2 или 3, авось поможет. Накатили КР3. Не помогло. АОС как падал так и продолжает падать и валяться. Шаманили. Били в бубны. Пели песни шаманские. Код просматривать нереально(сильно кастомезированное приложение). Отчаяние....

[raz]

Для проформы спрошу: на другом железе проверяли? полную переустановку софта делали?

ЗЫ. Причина вопроса в том, что проблема не наблюдается у всех (не имеет массовый характер), значит проблема ваша = железо, софт, модификации.

[Sada]

На другом железе не проверяли. Железяке не больше недели, на которую поставлено всё с нуля. Если разберемся в чём причина (а выбора у нас нет), то я обязательно отпишу в чём загвоздка.

[zZ_TOP_Zz]

А какая версия Ax32Serv.exe и клиента?

[Bishop]

На всякий случай спрошу - вы размер буфера в настройках AOS устанавливаете как "64" или как "65536" (либо "64000")?
Просто, там значение должно указываться в "кб", что неочевидно в самой утилите.

[Bishop]

Кстати, действительно следует попробовать переустановить роли клиента и сервера приложений. У нас буквально на этой неделе обнаружилось, что размер Ax32Serv.exe изменился по сравнению с чистой установкой (DAX 4.0 SP2), из-за чего AOS падал при настройке прав доступа и печати любого отчета в Excel или Word (с любого клиента).
Причина изменения размера файла не выяснена, есть только подозрение на вирусы, которые были недавно выявлены и устранены.
Помогла переустановка AOS.

[YellowSubmarine]

Цитата:

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

На другом железе не проверяли. Железяке не больше недели

Железяка новая? Вариант неисправности / перегрева железа не рассматривали.

[Sada]

Раасматриваем всё. Но на сколько должна перегрется желехяка, чтоб АОС упал...
Про Ax32Serv.exe пока сказать не могу. Не на работе я

[player]

Может это и не при чем, но на всякий случай - DEP пробовали отключать?

[Jony]

Размер кеша стоит именно 256.

Сервер ставили с нуля неделю назад. Перегрева нет.
Вирусы - тут незнаю. Проганю, но сомниваюсь что в них дело.

[gl00mie]

Цитата:

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

Рассматриваем всё. Но на сколько должна перегрется желехяка, чтоб АОС упал...

На счет и по поводу - был как-то аналогичный случай, правда, не с AOS'ом, а с обычным Word'ом из Ms Office 2003: падал, зараза, на ровном месте от совершенно безобидных действий, при том что все остальное работало, как ни странно, нормально. После кучи переустановок офиса и накатываний сервис-паков и патчей был запущен тест оперативной памяти, который выявил, что дело, судя по всему, было в ней: она оказалась битая.

[zelibobis]

А какая у Вас платформа 64-ёх разрядная? Или 32-ух? Вопрос касается и железа и ОС и сервера БД.

[Jony]

Платформа 32 бит.

Еще такое дополнение, может быть натолкнет на какую-нибуть мысль:

Клиенты работают с АОСом через терминальный сервер citrix

[ZVV]

Раньше поднимал уже эту тему тут:
Buffer Overrun

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

[Jony]

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

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

Грохнули все фотки из справочника сотрудников и все стало нормально.

Может нечто подобное про контейнерные поля обсуждалось на форуме, поиском не нашел.
Оставляю инфу для тех, кто еще борется с Buffer Overrun...

[Sada]

Добавлю. К Bufer Overrun добавилась такая неприятная вещь как просто падение AOSa. Работал, работал и вдруг упал. Ни логов, ничего не оставляла система. Мистика....И дальше чаще. Нет худа без добра. Перелопатили и оптимизировали тысячи страниц кода. Индексы, фигиндексы на таблицах. В общем всё что только можно. Естественно все стало шевелится быстрее (где то заметно быстрее, приложение досталось от прошлой команды ребят). И буквально при промотре справочника сотрудников случайно SQL ругнулся на del_EmplPhoto и тут пришло озарение.... Барабашки нет!!! Аминь...
PS: Jony и я работаем вместе.