Падает AOS, AX 2012 R3

[jonny]

Всем привет.
Столкнулся со странной проблемой, периодически падает AOS при следущей последовательности действий:
Открываем форму заказов на продажу, добавляем строчку, закрываем форму, закрываем аксапту, при попытке запуска аксапты AOS падает. Повторяется ошибка не всегда, примерно 1 раз из 5, но именно при такой последовательности действий.
В Event log следущая ошибка:

Faulting application name: Ax32Serv.exe, version: 6.3.1000.1030, time stamp: 0x5490d4dd
Faulting module name: ntdll.dll, version: 6.3.9600.17278, time stamp: 0x53eebd22
Exception code: 0xc0000374
Fault offset: 0x00000000000f0d6c
Faulting process id: 0x1300
Faulting application start time: 0x01d02e573e74d273
Faulting application path: C:\Program Files\Microsoft Dynamics AX\60\Server\DAX6R3_TST\Bin\Ax32Serv.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: 4deecf29-9a70-11e4-8132-0050569ab206
Faulting package full name:
Faulting package-relative application ID:

При чем она тоже есть не всегда, иногда просто:
RPC exception 1726 occurred in session 4 process is Ax32.exe thread is 7064(User: eglusche, ClientType: GUI)

Настроил WER, чтобы получить дамп памяти при падении, просмотрел его в WinDbg, стек вызовов такой:

This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(1fb0.e44): Unknown exception - code c0000374 (first/second chance not available)
ntdll!NtWaitForMultipleObjects+0xa:
00007ffb`5e6e1c2a c3 ret
0:032> kp
Child-SP RetAddr Call Site
00000000`25adddd8 00007ffb`5e71c286 ntdll!NtWaitForMultipleObjects+0xa
00000000`25addde0 00007ffb`5e71bde4 ntdll!RtlReportExceptionEx+0x452
00000000`25ade3b0 00007ffb`5e740dc2 ntdll!RtlReportException+0xbc
00000000`25ade440 00007ffb`5e6d340f ntdll!RtlReportCriticalFailure$filt$0+0x33
00000000`25ade470 00007ffb`5e6e1222 ntdll!_C_specific_handler+0x87
00000000`25ade4e0 00007ffb`5e6e431d ntdll!_GSHandlerCheck_SEH+0x76
00000000`25ade510 00007ffb`5e6a3057 ntdll!RtlpExecuteHandlerForException+0xd
00000000`25ade540 00007ffb`5e6a2309 ntdll!RtlDispatchException+0x197
00000000`25adec10 00007ffb`5e740d6c ntdll!RtlRaiseException+0x18d
00000000`25adf260 00007ffb`5e743f06 ntdll!RtlReportCriticalFailure+0x8c
00000000`25adf370 00007ffb`5e744b04 ntdll!RtlpHeapHandleError+0x12
00000000`25adf3a0 00007ffb`5e6fb9c5 ntdll!RtlpLogHeapFailure+0xa4
00000000`25adf3d0 00000000`64458d94 ntdll!RtlFreeHeap+0x793f5
00000000`25adf470 00007ff7`66bc2d94 msvcr100!free+0x1c
00000000`25adf4a0 00007ff7`66c8b5e5 Ax32Serv!SqlVirtualField::`vector deleting destructor'+0x64
00000000`25adf4e0 00007ff7`66dddfe1 Ax32Serv!cleanUpClassesAndCursors+0x35
00000000`25adf510 00007ff7`66ddf512 Ax32Serv!CSessionMgr:estroySession+0x251
00000000`25adf790 00007ff7`66de09f4 Ax32Serv!CSessionMgr:estroySessionWLock+0xc2
00000000`25adf7f0 00000000`64411bc7 Ax32Serv!CSessionMgr:estroySessionThreadEntry+0x24
00000000`25adf830 00000000`64411c55 msvcr100!_callthreadstart+0x17
00000000`25adf860 00007ffb`5c0c16ad msvcr100!_threadstart+0x75
00000000`25adf890 00007ffb`5e6a4409 kernel32!BaseThreadInitThunk+0xd
00000000`25adf8c0 00000000`00000000 ntdll!RtlUserThreadStart+0x1d

не сказал мне ни о чем Во всех источниках описывается как разбираться, если ошибка в при исполнении какого либо кода X++, но тут нет вызова кода приложения, какая то проблема в ядре. Kerlel и client стоят самые последние.

Куда еще порыть можно? Или нет смысла мучаться, а надо отправлять отчет в майкрософт?

[gl00mie]

Попробуйте отключить выполнение бизнес-логики в CIL и посмотрите, удастся ли снова завалить AOS найденным вами способом. Аналогичный случай был у меня в прошлом году: при определенных обстоятельствах вроде как в штатной ситуации падал AOS AX 2012 R2, при этом удалось выудить вот такой стек вызовов:

Child-SP          RetAddr           Call Site
00000000`2451d8c8 00000000`77763072 ntdll!NtWaitForSingleObject+0xa
00000000`2451d8d0 00000000`777632b5 ntdll!RtlReportSqmEscalation+0x1162
00000000`2451d9c0 00000000`7776331a ntdll!RtlReportException+0xb5
00000000`2451da40 00000000`77764155 ntdll!RtlReportException+0x11a
00000000`2451da70 00000000`776b85c8 ntdll!RtlUnhandledExceptionFilter+0x325
00000000`2451daa0 00000000`776c9d2d ntdll!_C_specific_handler+0x9c
00000000`2451db10 00000000`776b91cf ntdll!RtlDecodePointer+0xad
00000000`2451db40 00000000`776b97c8 ntdll!RtlUnwindEx+0xbbf
00000000`2451e220 00000000`77764102 ntdll!RtlRaiseException+0x248
00000000`2451ebd0 00000000`77764746 ntdll!RtlUnhandledExceptionFilter+0x2d2
00000000`2451eca0 00000000`77765952 ntdll!EtwEnumerateProcessRegGuids+0x216
00000000`2451ecd0 00000000`77767604 ntdll!RtlQueryProcessLockInformation+0x972
00000000`2451ed00 00000000`7770dc1f ntdll!RtlLogStackBackTrace+0x444
00000000`2451ed30 00000000`774a1a4a ntdll!RtlIsDosDeviceName_U+0x141ff
00000000`2451edb0 00000000`74fe8d94 kernel32!HeapFree+0xa
00000000`2451ede0 00000001`40213110 msvcr100!free+0x1c
00000000`2451ee10 00000001`3ffe5c7e Ax32Serv!CQLFreeVars+0x130
00000000`2451ee60 00000001`3ffe91e3 Ax32Serv!cqlClass::doFree+0x6e
00000000`2451ef40 000007fe`fe4afe85 Ax32Serv!ServerFreeClass+0x163
00000000`2451f010 000007fe`fe4a4d12 rpcrt4!Invoke+0x65
00000000`2451f0a0 000007fe`fe4a16bd rpcrt4!NdrStubCall2+0x32a
00000000`2451f6c0 000007fe`fe4a3134 rpcrt4!NdrServerCall2+0x1d
00000000`2451f6f0 000007fe`fe4a3296 rpcrt4!DispatchToStubInCNoAvrf+0x14
00000000`2451f720 000007fe`fe49bf2e rpcrt4!RPC_INTERFACE::DispatchToStubWorker+0x146
00000000`2451f840 000007fe`fe49bd92 rpcrt4!OSF_SCALL::DispatchHelper+0x15e
00000000`2451f960 000007fe`fe49bd29 rpcrt4!OSF_SCALL::ProcessReceivedPDU+0x36b
00000000`2451f9f0 000007fe`fe49b853 rpcrt4!OSF_SCONNECTION::ProcessReceiveComplete+0x3e9
00000000`2451faa0 000007fe`fd4e85ff rpcrt4!CO_ConnectionThreadPoolCallback+0x123
00000000`2451fb50 00000000`776b097a KERNELBASE!BasepTpIoCallback+0x4b
00000000`2451fb90 00000000`776bff2f ntdll!RtlEqualDomainName+0x38a
00000000`2451fc40 00000000`774959ed ntdll!RtlValidateHeap+0x4af
00000000`2451ff40 00000000`776cc541 kernel32!BaseThreadInitThunk+0xd
00000000`2451ff70 00000000`00000000 ntdll!RtlUserThreadStart+0x21

Вспомнил я свой случай потому, что дело тоже обрывалось на освобождении памяти ядром, при этом явных следов работы кода Х++ не было. С другой стороны, все статьи уважаемого Tariq Bell на тему поиска "злополучного" стека вызовов кода X++ касаются ситуации, когда приложение выполняется в интерпретаторе байт-кода X++, а не когда оно работает в CIL.
В моем случае причина падения АОСа была локализована, как ни странно, в не совсем корректной обработке исключений при выполнении кода в CIL. Обработка исключений в CIL имеет определенные особенности, которые исследованы в публикации Exception handling with X++ and .NET Interop. В частности, из моего скромного опыта, следует корректно и аккуратно обрабатывать Exception::CLRError, даже если код явно не взаимодействует с CLR. К сожалению, стандартный код самых что ни на есть базовых классов в этом плане не безупречен.
В общем, как минимум, в моем случае причина падения АОСа, естественно, была в ядре - в том, как оно освобождает память при обработке исключений в CIL, но проблему удалось обойти за счет более аккуратного написания кода X++.

[jonny]

Спасибо за ответ.
Галочку Выполнение бизнес логики в CIL снял, не помогло, с 6-го повторения AOS упал.
Я не могу понять, как вообще может быть связаны манипуляции в форме заказа на продажу с падением при старте клиента.
А как вам удалось локализовать проблему в вашем случае?

[igortsk]

gl00mie, что-то уж очень похож Ваш стек на мой. проблема та же - падает АОС и не пойму из-за чего. С помощью статей Tariq не смог ничего подчерпнуть. Если помните, подскажите плиз где конкретно и что мне посмотреть, чтобы убедиться, что у меня не та же самая проблема? И если это она, что исправить. Заранее очень благодарен!

мой стек:

# Child-SP          RetAddr           Call Site
00 00000004`931ac908 000007fe`fd8a1430 ntdll!NtWaitForMultipleObjects+0xa
01 00000004`931ac910 00000000`77911753 KERNELBASE!WaitForMultipleObjectsEx+0xe8
02 00000004`931aca10 00000000`7798b635 kernel32!WaitForMultipleObjectsExImplementation+0xb3
03 00000004`931acaa0 00000000`7798b7b7 kernel32!WerpReportFaultInternal+0x215
04 00000004`931acb40 00000000`7798b80f kernel32!WerpReportFault+0x77
05 00000004`931acb70 00000000`7798ba2c kernel32!BasepReportFault+0x1f
06 00000004`931acba0 00000000`77acfe45 kernel32!UnhandledExceptionFilter+0x1fc
07 00000004`931acc80 00000000`77ad0225 ntdll!TppExceptionFilter+0xa5
08 00000004`931acce0 00000000`77a9a2cf ntdll!TppWorkerpInnerExceptionFilter+0x15
09 00000004`931acd10 00000000`77a28008 ntdll! ?? ::FNODOBFM::`string'+0x25a0
0a 00000004`931acd50 00000000`77a98419 ntdll!_C_specific_handler+0x8c
0b 00000004`931acdc0 00000000`77a3905d ntdll!_GSHandlerCheck_SEH+0x75
0c 00000004`931acdf0 00000000`77a28c0f ntdll!RtlpExecuteHandlerForException+0xd
0d 00000004`931ace20 00000000`77a5d948 ntdll!RtlDispatchException+0x45a
0e 00000004`931ad500 00000001`4059412a ntdll!KiUserExceptionDispatcher+0x2e
0f 00000004`931adac0 00000001`40594618 Ax32Serv!SqlData::cvtField+0x1ea
10 00000004`931adba0 00000001`4030092f Ax32Serv!SqlData::cvtRecord+0x458
11 00000004`931adc60 00000001`40300e92 Ax32Serv!SqlStmt::GetFetchedDataContents+0x67f
12 00000004`931ae5d0 00000001`40300fad Ax32Serv!SqlStmt::next+0x382
13 00000004`931ae670 00000001`404ef6d4 Ax32Serv!SqlStmtTimed::next+0x4d
14 00000004`931ae6a0 00000001`4027bc25 Ax32Serv!cqlDatasourceSql::fetchrec+0x384
15 00000004`931ae710 00000001`4027e745 Ax32Serv!cqlCursor::__next+0x605
16 00000004`931ae8f0 00000001`4027f18c Ax32Serv!cqlCursor::_next+0x2805
17 00000004`931aebc0 000007fe`ff57f4a5 Ax32Serv!ServerNext+0x45c
18 00000004`931aed40 000007fe`ff574502 rpcrt4!Invoke+0x65
19 00000004`931aee00 000007fe`ff570e7d rpcrt4!NdrStubCall2+0x32a
1a 00000004`931af420 000007fe`ff572924 rpcrt4!NdrServerCall2+0x1d
1b 00000004`931af450 000007fe`ff572a86 rpcrt4!DispatchToStubInCNoAvrf+0x14
1c 00000004`931af480 000007fe`ff56b6ee rpcrt4!RPC_INTERFACE::DispatchToStubWorker+0x146
1d 00000004`931af5a0 000007fe`ff56b552 rpcrt4!OSF_SCALL::DispatchHelper+0x15e
1e 00000004`931af6c0 000007fe`ff56b4e9 rpcrt4!OSF_SCALL::ProcessReceivedPDU+0x36b
1f 00000004`931af750 000007fe`ff56b013 rpcrt4!OSF_SCONNECTION::ProcessReceiveComplete+0x3e9
20 00000004`931af800 000007fe`fd8a8c6f rpcrt4!CO_ConnectionThreadPoolCallback+0x123
21 00000004`931af8b0 00000000`77a206ea KERNELBASE!BasepTpIoCallback+0x4b
22 00000004`931af8f0 00000000`77a2f7af ntdll!TppIopExecuteCallback+0x1ff
23 00000004`931af9a0 00000000`77905a4d ntdll!TppWorkerThread+0x3f8
24 00000004`931afca0 00000000`77a3b831 kernel32!BaseThreadInitThunk+0xd
25 00000004`931afcd0 00000000`00000000 ntdll!RtlUserThreadStart+0x1d

[Vadik]

igortsk, MS попросить посмотреть почему не хотите ?

[igortsk]

потому что подписка закончилась на AX, а там похоже нужна подписка

[gl00mie]

Цитата:

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

gl00mie, что-то уж очень похож Ваш стек на мой. проблема та же - падает АОС и не пойму из-за чего. С помощью статей Tariq не смог ничего подчерпнуть. Если помните, подскажите плиз где конкретно и что мне посмотреть, чтобы убедиться, что у меня не та же самая проблема?

Мне кажется, что стеки совсем разные. Если выкинуть служебные фреймы, связанные с RPC-вызовом и обработкой исключения, то у меня дело было, видимо, в освобождении памяти по кривому указателю:

Child-SP          RetAddr           Call Site
00000000`2451edb0 00000000`74fe8d94 kernel32!HeapFree+0xa
00000000`2451ede0 00000001`40213110 msvcr100!free+0x1c
00000000`2451ee10 00000001`3ffe5c7e Ax32Serv!CQLFreeVars+0x130
00000000`2451ee60 00000001`3ffe91e3 Ax32Serv!cqlClass::doFree+0x6e
00000000`2451ef40 000007fe`fe4afe85 Ax32Serv!ServerFreeClass+0x163

А тут валится всё на доступе к полю курсора:

Child-SP          RetAddr           Call Site
00000004`931adac0 00000001`40594618 Ax32Serv!SqlData::cvtField+0x1ea
00000004`931adba0 00000001`4030092f Ax32Serv!SqlData::cvtRecord+0x458
00000004`931adc60 00000001`40300e92 Ax32Serv!SqlStmt::GetFetchedDataContents+0x67f
00000004`931ae5d0 00000001`40300fad Ax32Serv!SqlStmt::next+0x382
00000004`931ae670 00000001`404ef6d4 Ax32Serv!SqlStmtTimed::next+0x4d
00000004`931ae6a0 00000001`4027bc25 Ax32Serv!cqlDatasourceSql::fetchrec+0x384
00000004`931ae710 00000001`4027e745 Ax32Serv!cqlCursor::__next+0x605
00000004`931ae8f0 00000001`4027f18c Ax32Serv!cqlCursor::_next+0x2805
00000004`931aebc0 000007fe`ff57f4a5 Ax32Serv!ServerNext+0x45c

Я лично в подобных случаях первым делом пытаюсь воспроизвести проблему на последней доступной сборке ядра. Если там проблема не воспроизводится, значит, кто-то уже наступил на те же грабли, и ядро успели поправить. Обновления ядра общедоступны, номера статей KB публикуются здесь, а как по номеру KB скачать исправление, было описано здесь.

[igortsk]

возможно ли, что это мы что-то на*бокодили? Но мы в ядро не лезем конечно..

[vmokerov]

Добрый день.

Подскажите, пожалуйста, как для Ax 2012 R3 x64 смещения узнать, которые добавлять к адресу в дампе памяти. Пробовал указанные для Ax 2009 x64 не выходит (https://blogs.msdn.microsoft.com/eme...aused-a-crash/). Еще в статье почему-то в описании алгоритма указываются одни числа для ax 2009 x64, а в примере другие.

[Logger]

Цитата:

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

В общем, как минимум, в моем случае причина падения АОСа, естественно, была в ядре - в том, как оно освобождает память при обработке исключений в CIL, но проблему удалось обойти за счет более аккуратного написания кода X++.

Можешь подробнее раскрыть тему ?
Как правильнее делать обработку исключений CLR чтобы свести к минимуму такие риски ?

[gl00mie]

На счет падения при старте клиента - не могу точно сказать, в чем связь с заказами. Сильно зависит от того, что именно у вас происходит при старте. АОС 2009-й очень любил валиться на операциях с контейнерами, так что, возможно, из SysLastValue распаковывается "что-то не то", сохраненное на предыдущем запуске.
Я локализовал проблему в ходе долгой и нудной отладки. На проблемное место меня навело то, что на нем обрывался стек вызовов управляемого кода, который я выводил в инфолог при возникновении исключения, хотя отладка показывала, что код, после выполнения которого все в итоге падает, находится на несколько уровней стека вызовов глубже.
Как вариант, можно попробовать включить трассировку и посмотреть, что именно происходит при запуске клиента непосредственно перед падением АОСа.

[jonny]

Цитата:

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

На счет падения при старте клиента - не могу точно сказать, в чем связь с заказами. Сильно зависит от того, что именно у вас происходит при старте. АОС 2009-й очень любил валиться на операциях с контейнерами, так что, возможно, из SysLastValue распаковывается "что-то не то", сохраненное на предыдущем запуске.
Я локализовал проблему в ходе долгой и нудной отладки. На проблемное место меня навело то, что на нем обрывался стек вызовов управляемого кода, который я выводил в инфолог при возникновении исключения, хотя отладка показывала, что код, после выполнения которого все в итоге падает, находится на несколько уровней стека вызовов глубже.
Как вариант, можно попробовать включить трассировку и посмотреть, что именно происходит при запуске клиента непосредственно перед падением АОСа.

Сравнил trace log для случая падения AOS с нормальным, похоже причина падения где то в CLRInterop::loadAssemblyDictionaryThread, в случае с упавшим AOS на этом месте обрывается дерево вызовов. К тому же в Event log есть сообщения типа:

Could not load assembly 'TillLayoutDesigner, Version=6.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies.

[AndyD]

Цитата:

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

К тому же в Event log есть сообщения типа:

Could not load assembly 'TillLayoutDesigner, Version=6.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies.

Это нормально
Есть сборки, которые предназначены для работы клиента.
Их нет на АОСе и он не может их загрузить, соответственно

[Ivanhoe]

Была похожая проблема при установке определенного хот-фикса безопасности для IE (сам хот-фикс поправили только в конце 2014-го). Но в последних билдах AX ее точно правили. У вас точно последний билд и клиента, и АОСа?

[jonny]

Цитата:

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

Была похожая проблема при установке определенного хот-фикса безопасности для IE (сам хот-фикс поправили только в конце 2014-го). Но в последних билдах AX ее точно правили. У вас точно последний билд и клиента, и АОСа?

Да, билд свежайший, от 5-го января

[gl00mie]

При установке определенного хот-фикса безопасности для IE == падало из-за ролевых центров?

[Ivanhoe]

Нет, как раз из-за стандартной ntdll.

[gl00mie]

Если есть подозрение на ошибку при загрузке какой-либо сборки, можно воспользоваться Process Monitor'ом и посмотреть, к каким файлам пытался обращаться АОС непосредственно перед падением.

[jonny]

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

[Freeangel]

Проверьте в параметрах не включена ли Предварительная загрузка форм.