единственный способ это исправить - зарегистрировать соответствующий запрос в поддержке

[fed]

Цитата:

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

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

Да - это была последняя услуга поддержки, которой мы продолжали пользоваться. Но с полгода назад, Тарик Белл (Спасибо ему за это!) добился открытия доступа к отладочным символам аксапты и опубликовал серию статей про анализ краш-дампов:
Setting up WinDbg and Using Symbols
Finding the AX user that caused an AOS crash (axforum)
Finding the X++ call stack that caused a crash (axforum)
Finding the AX user and the X++ call stack from a memory dump the easy way
So your AOS crashed, is hanging, or you just want to see what it's doing

добавлено emeadaxsupport: What to do if you have a crash

После этого краш-дампы стало возможным анализировать самому - без поддержки...

Цитата:

В плане потери времени я бы не был так пессимистичен. Я обычно тестовые данные не готовлю, а вкратце описываю сюжет и оптправляю. У специалиста могут появиться вопросы, но я рекомендую ему попробовать воспроизвести все самому и в 90% случаев он превосходно справляется.

Вероятно за 6 лет работы от имени одного партнера с одними и теми же саппортерами ты их просто выдресировал

fed добавил ссылку здесь
http://blogs.msdn.com/b/axsa/archive...in-ax2012.aspx

[EVGL]

Цитата:

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

Вероятно за 6 лет работы от имени одного партнера с одними и теми же саппортерами ты их просто выдресировал

Да нет, я просто им пишу: "Извини, Наталия Фернандес / Золтан / Амитабха, но у меня нет времени на разжевывание. Обрати внимание на это и это." И ничего, справляются.

[Logger]

Цитата:

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

Да - это была последняя услуга поддержки, которой мы продолжали пользоваться. Но с полгода назад, Тарик Белл (Спасибо ему за это!) добился открытия доступа к отладочным символам аксапты и опубликовал серию статей про анализ краш-дампов:
Setting up WinDbg and Using Symbols
Finding the AX user that caused an AOS crash
Finding the X++ call stack that caused a crash
Finding the AX user and the X++ call stack from a memory dump the easy way
So your AOS crashed, is hanging, or you just want to see what it's doing

Эти ссылки надо в рамочку и на видное место. В какой нить раздел на форуме. Как минимум тэг "полезное" обеспечен.
Я когда их увидел в блоге - еще удивился - не ожидал такого. А оказывается это опять fed постарался.
Большое спасибо.

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

С одной стороны грустно что все так. А с другой стороны хорошо что они у нас есть

[gl00mie]

Цитата:

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

с полгода назад, Тарик Белл (Спасибо ему за это!) добился открытия доступа к отладочным символам аксапты и опубликовал серию статей про анализ краш-дампов:
Setting up WinDbg and Using Symbols
Finding the AX user that caused an AOS crash (axforum)
Finding the X++ call stack that caused a crash (axforum)
Finding the AX user and the X++ call stack from a memory dump the easy way
So your AOS crashed, is hanging, or you just want to see what it's doing

добавлено emeadaxsupport: What to do if you have a crash

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

Цитата:

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

Надо только учесть, что у Tariq'а в статье есть пара опечаток, которые становятся очевидны при просмотре приведенного им выхлопа отладчика:

1. Цитата:

   Look for the Ax32Serv!interpret::evalFunc frames take the location from the line below and then run in AX2009 64 bit: dw 000000002311b150+30
   на самом деле +20
2. Цитата:

   Next you can run in AX2009 64 bit: db 000000002311b150+38
   на самом деле +28

Для аналогичного анализа дампа памяти или "живого" клиента AX 2009 подходят приведенные им рецепты для AX4 32-bit (ну и плюс в этом случае надо использовать WinDBG x86 - даже на винде x64). Да, и лучше это все делать на ядре RU7, потому что для него отладочные символы в открытом доступе есть, а для RU6, насколько я могу судить, - нет.
Также хочу напомнить, что с ключом ком. строки /console AOS можно запустить не как сервис, а как обычное консольное приложение - в т.ч. прямо из-под отладчика.

[Logger]

Цитата:

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

Да - это была последняя услуга поддержки, которой мы продолжали пользоваться. Но с полгода назад, Тарик Белл (Спасибо ему за это!) добился открытия доступа к отладочным символам аксапты и опубликовал серию статей про анализ краш-дампов:
Setting up WinDbg and Using Symbols
Finding the AX user that caused an AOS crash (axforum)
Finding the X++ call stack that caused a crash (axforum)
Finding the AX user and the X++ call stack from a memory dump the easy way
So your AOS crashed, is hanging, or you just want to see what it's doing

добавлено emeadaxsupport: What to do if you have a crash

После этого краш-дампы стало возможным анализировать самому - без поддержки...

Вероятно за 6 лет работы от имени одного партнера с одними и теми же саппортерами ты их просто выдресировал

fed добавил ссылку здесь
http://blogs.msdn.com/b/axsa/archive...in-ax2012.aspx

Пишут что автомат отключили
https://blogs.msdn.microsoft.com/axs...-discontinued/
и вместо него есть еще одна инструкция
https://blogs.msdn.microsoft.com/cob..._dmp_analysis/