[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++.