Debug::Assert() Method Causes Stack Trace Error in Dynamics AX When in Debugging Mode
I recently encountered a scenario of users getting a stack trace error when trying to generate an invoice while in debugging mode in Dynamics AX. When working through bugs on the test server, calling the Debug::assert() caused the stack trace error to appear.
Problem: User getting stack trace error when trying to generate an Invoice.
Cause: Since we were working through a lot of bugs, the testers were finding we had to have debugging enabled on the test server. When the process hits this: Debug::assert() code, the AX debugger was invoked automatically, displaying the stack trace error. The user would never get this error in production because the debugging would be disabled.
Reproducing Error: I had issues trying to reproduce this error in our development environment. When the error occurred it never hit a break point in the debugger so I couldn’t find the line of code that was generating the error. After some research I found out that I had to check the ‘Execute business operations in CIL’ (Tools – Options – Development form). After checking I was able to do more debugging in AX and Visual Studio to find where the error was being generated, when trying to call Debug::assert().
How to Resolve Debug::assert() error: To eliminate this error during our testing the change was simple. First make sure that ‘Execute business operations in CIL’ is checked. NOTE: after checking/unchecking this you have to generate a CIL before you will see the changes in VS. Then you need to find the Debug::assert() that is causing the error. When you find comment out the line but make sure to put a TODO statement to make sure to uncomment the code before the move to production. For example, //TODO uncomment Debug::assert when debugging is turned off. This TODO will come up when you do a compile within AX. The downside to this is that I did have to make a change to a SYS layer class/method. However, once you remove the commented line and TODO you can do a Compare and delete the VAR layer since there are no longer any code changes.
This issue took a bit for me to work through. Hopefully these steps can save someone time in the future. Happy debugging.