Thursday, December 12, 2013

Debug code in 'runTableMethodIL' in AX 2012

On occasion in the debugging process, you will not be able to access some code you can see written in Dynamics AX but for some reason is not hitting your breakpoint.

Other than a few things to look for like a breakpoint on a field method or debugging enabled on server, its possible the code of interest is actually running in the CIL (Common Iterop Lanuage) via the runTableMethodIL x++ call. Unfortunately, due to the way the debugger app works, you can't plow into the code after this method. There are ways to do it but sometimes I need to jump in quick so I change a line of code or change as user option to have it call the AX method normally instead of via the CIL optimized way so I can debug like normal.

There are two ways to handle this:
Option A: Change the 'Execute business operations in CIL user option' to false (should by default be set to true)
Option B: Temporarily change the code for debugging.

For option B, the code change method is pretty easy. Just comment out the CIL line and replace it with the static call to the tables static method detailed in the runTableMethodIL method. See the picture below for an example.This comes in handy when debugging not just using your user (e.g. processes running under users other than your current user).

THIS IS NOT A PERMANENT FIX. This is just so I can debug this situation quickly and is a very helpful quick tool. I would highly recommend switching it back before promoting your code aka as soon as you're done tinkering.

The reason for the CIL is that the application gains performance by running in CIL.

Figure 1 - The 'Execute business operations in CIL' option

Figure 2 - An example of the code switch


  1. Is this for when the do not run in cil, under development options ain't enough?

  2. Oscar, Correct. If running a quick debug process, you can uncheck that box and it will work for your user (Figure 1 above). But again, that is user specific so doesn't help when debugging processes that leverage the same code for multiple processes run under multiple service accounts. I simplified for the original post but modified the post to include your point for a single users as its important to highlight. Obviously the best approach depends on each situation. Thanks for the feedback!