Tips & Tricks around debugging X++ code in Dynamics AX

When you are developing X++ code for Dynamics AX over the time you will for sure run into a situation where the below Tips & Tricks can make your debugging live easier. The information are no secrets it is just hard finding them the very first time you need them. Since I was also once in the situation needing to find them, I thought it is maybe a good idea to collect the most useful ones I'm using day to day...

The most oblivious one: Interrupting the code execution
When you have written some code that is causing an endless loop (or a very long execution) and you want to know what code is currently keeping the client busy the easiest way is pressing [Ctrl] + [Break] on the keyboard.
This will stop the code execution and show up a message box: Are you sure that you want to cancel this operation?
If you hold down the [Shift] button on the keyboard while you click at the No button of the message box, the AX Debugger will be launched exactly at the line of code that was about to be executed. From here you can continue to step over / into line by line and try to identify the cause of your endless loop.

The breakpoint is sometimes not hit?
Sometimes it happens that a breakpoint is not hit although you are sure the respective code was executed. For example if you want to debug code behind User Controls like Form buttons this can happen.
Here instead of putting a breakpoint at a line of code insert the breakpoint keyword.

public void executeQuery()
{
   ;
   breakpoint;   super();
}

Please note that using breakpoint has a serious side effect:
The breakpoint will be hit by all user sessions! This is definitely something you don't want to do in a live environment.

How can I see the call stack that resulted in a X++ exception?
When you run into an exception that is showing up in the InfoLog usually double clicking at the error brings you to the line of code where the error was raised.
Sometimes knowing the line of code where the error was raised is however not good enough as the individual call stack is what you need to know. Putting a breakpoint at the line of code where the exception was raised is helpful, what however if you are in a loop and you don't know what loop iteration results in the error especially if the error is random?
Instead of putting the breakpoint at the line of code where the exception might be raised, put a breakpoint in the add method of the Info class, e. g. at the line switch (logLevel).

Exception add(
   // ...
   ;
   switch (logLevel)
   // ...

Info::add is always called when something is written to the InfoLog and since an exception shows up in the InfoLog as soon as the exception was raised the Info::add method is called and here you will hit your breakpoint.

How can I get the current X++ call stack?
The static method xppCallStack() of the xSession Kernel class returns the current X++ call stack:

   //...
   Info(con2str( xSession::xppCallStack() ));
   //...

The function funcname() returns the name of the method where it has been called.

public void executeQuery()
{
   ;
   Info( funcname() ); //In this case "executeQuery" will show up in the InfoLog

   super();
}

How can I see the SQL query that the Dynamics AX Kernel is generating for my Form?
When you are debugging your solution you sometimes might want to see the SQL Query the Dynamics AX Kernel has generated for your Form. While you can of course trace this directly at your Database Server, you also can do this in X++ using the QueryBuildDataSource class.
Let's imagine you have a Form that has PurchTable as Data Source. You have to override the executeQuery method of the PurchTable Data Source and add the following code:

public void executeQuery()
{
   Query q;
   QueryBuildDataSource qbds;
   ;
   q = this.query();
   qbds = q.dataSourceName("PurchTable"); //Replace with the current Table
   info( qbds.toString() );

   super();
}