Batch Jobs / Server Debugging in Dynamics AX


In my previous post, I’ve told you about the client code debugging, which is similar in Dynamics AX 2009 and AX 2012. The server code debugging has differences for these two versions and here is how you can do it.

Debug the server-side code in Dynamics AX 2009

    • Go to the server environment and open the AX Client Configuration Utility. Then press the Manage button and choose Create New Configuration. Name the configuration.
    • On the tab page Connection set the server name, instance name, and port. Make sure that you use the appropriate port, because if you have many instances of AX it can differ from the standard 2712 port.
    • On the tab page Developer make sure that the Enable user breakpoints to debug in the Business Connector and Enable global breakpoints to debug code running in the Business Bonnector or client check-boxes are marked.
    • Open the AX Server Configuration Utility and press the Manage button. Select Create New Configuration and name the configuration.
    • On the tab page Application Object Server select the application file location, alternate bin directory, and application instance. Make sure that Enable breakpoints to debug X++ code running on this server and Enable global breakpoints to debug X++ code running in batch jobs are checked.
    • Open the development workspace from the Dynamics AX client to set a breakpoint on a necessary line.
    • Schedule a batch job. Its status can be checked in Basic > Inquiries > Batch Job. The execution will soon be stopped at the previously inserted breakpoint and you can continue stepping through the code.

Debug the server-side code in Dynamics AX 2012

You should use Visual Studio, as batch jobs in AX 2012 are compiled into Common Intermediate Language (CILa code that the Microsoft. NET Framework can use improving performance) and run on the server. First of all, make sure that you have access to the AOS environment and that Visual Studio is installed there. Now you can do the following:

    • Go to the server environment and open the AX Server Configuration Utility. The server configuration is usually set during the AOS installation, so it doesn’t necessarily have to be changed by every new user. Make sure that the configuration is the one you need and check the Enable breakpoints to debug X++ code running on this server and Enable global check-boxes.
    • Now open Visual Studio. Please note that in order to attach to the AOS process, the development environment must run at the server side.
    • Choose View > Application Explorer in the main menu of IDE. If the AOS Disconnected message appears in the Application Explorer, the IDE should be configured to open with the specific AX client settings. As soon as you are connected, find the needed classes in the AOT of the Application Explorer pane.
    • To attach IDE to the AOS process, select Attach to process in the Debug menu. Check Show processes from all users and Show processes from all sessions in the dialog.
    • If you have many AOS services because of multiple AOS configurations, make sure to select the right service, as they differ by ID only. Use the Task manager to run this check: open the process properties and get the AOS name from the AOS path.
    • When you are sure which process you want VS to attach to, select it in the Attach to process window.
    • If the security warning appears, click Attach to proceed. If you are logged into the server account that is not the account used for the AOS service, the warning will appear again and again.

Either before or after setting the breakpoints note that they have statuses displayed by the notification icons:

breakpoint-1Normal state, enabled and disabled


breakpoint-2Breakpoint will never be hit


breakpoint-3Breakpoint within unavailable code. In this case, make sure that the incremental CIL is generated.


    • Schedule the batch job. Visual Studio will open as soon as its required breakpoint is hit.
    • In the Visual Studio debugger you can use the same commands as in the Dynamics AX debugger: step in, step out, add watch, etc.
    • If changes are made to the X++ code, they will have no effect unless the CIL generation is done after the X++ code compilation. The incremental CIL will compile the objects modified since the last incremental generation. When this is done, the changes will appear in next debugging session.

Now that you know more about server debugging in AX 2009 and AX 2012, I will move on to the next topic and tell you how to debug services in Dynamics AX.