Tips & Tricks for Debugging in Visual Studio for D365

In this blog, I have covered some tips and tricks supported for D365 in Visual studio.

Tip # 1 – Pin data tips
While debugging code we have frequently hover over data tips in order to see the values contains in variables. In VS we can pin the data tip for the variable to give our-self quick access. To pin the data tip, click the pin icon while hovering over it. You can pin multiple variables.

First way to pin is to select your variable and right-click it as shown in image.

Second way to pin is to hover your variable click pin icon.

Tip # 2 – Conditional Break points
If it is difficult or time-consuming to recreate a particular state in your app, consider whether the use of a conditional breakpoints can help. Right-click a break-point icon (the red ball) and choose Conditions. In the Break-point Settings window, type an expression.

Tip # 3 – Track an out-of-scope object
We can view variables values using debugger window. However, when a variable goes out of scope in the Watch window, you may notice that it is grayed out. In VS we can track those variable by creating an Object ID for it in the Watch window.

To Create an object Id:
– Set a break-point near a variable that you want to track.
– Stop your break-point at your variable.
– Find variable in the Locals window (Debug > Windows > Locals), right-click the variable, and select Make Object ID.
– Right-click the object ID variable and choose Add Watch.

Tip # 4 – View return values for functions
In order to view return values for your functions, look at the functions that appear in the Autos window to see the return value for a function, make sure that the function you are interested in has already executed.

Tip # 5 – Format your string in a visualizer
When working with strings, it can be helpful to view the entire formatted string. To view a plain text, XML, HTML, or JSON string, click the magnifying glass icon Visualizer Icon while hovering over a variable containing a string value.

Tip # 6 – Manage breakpoints
In VS when we set-up some breakpoints and now we need to switch one-off for as it’s getting hit too much but we will need it again for debugging. If we remove the break-point we’ll have to come back and find it again. So instead of removing the break-point we can use Break-point window. This window will show all breakpoints you have set but crucially lets you disable them without un-setting them by simply removing the check-mark. Check it again to re-enable it.

Tip # 7 – Break into code on handled exceptions
The debugger breaks into your code on unhandled exceptions. However, handled exceptions can also be a source of bugs and you may want to investigate when they occur. We can configure the debugger to break into code for handled exceptions as well by configuring options in the Exception Settings dialog box. Open this dialog box by choosing Debug > Windows > Exception Settings. Also in the dialog box window you can search your relevant exception in which you want to break the code when exception occur.

Reference Link: 
1- Tips & Trick to debug in visual studio
2- Visual Studio Debugging Tips That Will Lighten Your Load

Debug from Visual Studio X ++ code running on the server AX 2012

Much of the code we developed in X ++ classes running on the server layer ( Data Providers reports, processes Batch , SysOperation , …), which is a little uncomfortable when debugging. If we put a breakpoint from the X ++ editor in MorphX in code running on the server, we see how the integrated debugger never stops at this point.

Prepare the development environment for debugging server code from Visual Studio (including the X ++ code, the server always runs as CIL code) forces us to consider a few prerequisites, so I’ll list here to keep on hand when we do need:

Prerequisites and prior considerations:

  • Ensure that the code CIL is fully executed without errors. Otherwise, we want to debug the assembly may not be available in its latest version, but the last to be compiled without errors.
  • To debug remote code to run Visual Studio as long as Administrator (with elevated privileges by clicking -right> Run as administrator). Otherwise, we will have problems later permissions.
  • Remote debugging from Visual Studio must be on the same server where the AOS is installed, indirectly forcing us to use a development environment, because this is not ideal for production OSA configuration.
  • AOS configuration option must be on Enable breakpoints to debug X ++ code runing on this server (this is also not recommended in production OSA).
  • Associate a process for purifying AOS puts the server in a state extremely unstable , with very significant risk that the service restarts unexpectedly. Therefore it is highly recommended to use a development server isolated not to disturb the other developers.If we use a single AOS for all developers, it may be interesting to take another AOS for remote debugging.

Start the remote debugging:

  • Start Visual Studio on the server and Elevated.
  • If you are not already showing, show the Application Explorer (from the menu View ), which shows the OSA VS.
  • Navigating the Application Explorer and put breakpoints where we want to stop running (add breakpoins in Visual Studio , notMorphX !!).
  • If the message appears in the status bar of Visual Studio (at the bottom of the window) “Loading symbols” is best to wait until this process is complete. The first is a slow process; The following times will run much faster.


  • Go to menu Debug> Attach to Process
  • Activate the checkbox Show processes from all users and show processes for all sessions , select the process Ax32Serv.exe AOS we want debug and press Associate .

Visual Studio - Attach to Process

  • After this process you may be reloaded symbols (X ++ code and assembled AOS CIL is discharged to the session of Visual Studio). All code is downloaded to C: \ Program Files \ Microsoft Dynamics AX \ 60 \ Server \ <NAME AOS> \ bin \ XppIL \ source for Visual Studio has access to the show and we in the editor.
  • When you have downloaded all objects, and can run our application and to reach the breakpoint , it will stop at the open session ofVisual Studio (not the debugger MorphX ).
  • If you are trying to debug is invoked from an external application, such as a web service, we can have another instance of Visual Studio open to run. In this case it should be a different instance of Visual Studio we use to debug it is associated with OSA.
  • If we let all the symbols are downloaded, we can surf the execution routinely, but sometimes the source of some objects will not be available during debugging. In this case we can stop debugging and open the object in the Application Explorer , to make sure thatVisual Studio has downloaded.

More information: