In a previous article we looked at how to debug in Microsoft Dynamics 365 for Finance and Operations. Now that you are debugging, is Visual Studio not stopping on your breakpoints? This could be that your D365 debug symbols are not loading. There are several settings that need to be set correctly to allow D365 debug symbols to load. In this article I will explain how you can troubleshoot this issue.
Uncheck ‘Enable Just My Code’
The first option we need to review to make sure D365 debug symbols are working is the ‘Enable Just My Code’ flag. In Visual Studio, in the menu go to Dynamics 365>Options. Expand the Debugging node, and select the General node. In the right pane, locate the Enable Just My Code checkbox. Uncheck this flag. Now Visual Studio will not step over calls to system, framework, and other non-user code. This flag is checked by default. So you need to uncheck it.
Load Symbols Only For Items In The Solution
The second option we need to review to make sure D365 debug symbols are loaded is the ‘Load Symbols Only for Items In Solution‘ option. In Visual Studio, in the menu go to Dynamics 365>Options. Expand the Dynamics 365 node, and select the Debugging node. In the right pane, locate the ‘Load symbols only for items in the solution’ checkbox. Uncheck this checkbox. Now the D365 Debug symbols will be loaded for all objects. And not just the objects that are part of your project. And quite often you do need to debug code that is only in base Microsoft objects.
Load Microsoft Symbols
The third option we need to review to make sure D365 debug symbols are loaded is the ‘Microsoft Symbol Servers’ flag. In Visual Studio, in the menu go to Dynamics 365>Options. Expand the Debugging node, and select the Symbols node. In the right pane, locate the Microsoft Symbol Servers checkbox. Check this checkbox. Also select the ‘Load all modules, unless excluded‘ option. You can click the ‘Load only specified modules‘ option and then click the ‘Specified included modules‘ link. This can improve performance of debugging. However, I recommend you use the first option until your symbols are loaded properly. Then you can come back and make adjustments to these settings.
Debug The Code
Follow the instructions in this previous article to add a breakpoint, attach to process, and begin debugging. If all of the above settings are set correctly, the D365 debug symbols should load correctly. You can tell that the symbols have loaded, when you have attached to the process, and the red breakpoint circles are fully filled in. If the symbols have not loaded correctly, the red circles will empty and not filled in.
In the below screenshot, you can see that the red breakpoint circle is not filled in. This means that the D365 debug symbols have not loaded. It will take some time after the debugger is first attached to load all the symbols. Look at the messages at the bottom of Visual Studio. These messages tell you if the symbols are actively being loaded.
Once the D365 debug symbols have finished loading, you should see a filled in red circle. This indicates that system will stop execution on this line of code. And the code will show in the Visual Studio Debugger.
Build The Code
Finally, if the breakpoints are still not being hit, compile your solution. You may also want to try to perform a complete model build. If you recently pulled in the latest code from source control, the compiler may not have built the code, and created D365 debug symbols. Compiling the code will create these symbols and should allow your code to be debugged.
Conclusion
When using a D365 cloud hosted environment there are several settings, that are set by default in Visual Studio, that prevent you from debugging the code. In this article we covered what those settings are, and how you can change them to allow debugging the x++ code. Hopefully this will save you some time and confusion in the future.
Great article, thanks for that.
Thanks so much for this article!
I have a lot of problems trying to find the right place to place the breakpoint, let alone the silly symbol issue. So this makes it very helpful to be able to place the breakpoint anywhere when troubleshooting.
I am so glad this was helpful!
I have the same setup as your debugging but notice there are a ton of symbols loaded when I’m manually picking the files I want to debug. I understand a full build will create symbols and they now recommend not doing full builds with VS2019 since the debugging experience is terrible. Do you know how to remove all the loaded symbols? I click on the Empty Symbol Cache and the load only specified modules is selected and still showings tons of loaded MS symbols for AppicationSuite and others.
Under debug>options>debugging there is a tab that lets you specify what modules you want to load symbols for. You can use this to help debug more quickly. That said, usually once you load the other modules once or twice I find that the symbols get cached and subsequent debugging goes a lot faster. But it definitely can be slow some times. I agree.
I should follow up on my first reply and know the .pdb files are found under the bin folder of the associated folder from PackagesLocalDirectory, ie: c:\AOSService\PackagesLocalDirectory\ApplicationFoundation\bin\Dynamics.AX.ApplicationFoundation.5.pdb. Can these be moved out of the .pdb files and load them manually?
I don’t recommend doing anything with the pdb files. Visual studio will handle them. You can do a full build initially. But after that, you shouldn’t need to rebuild the base Microsoft code in most cases. Just build your solution. And if you have problems or have done a “get latest” to get more code from source control then do a build of your model. If you still have issues you can build your model and check the check box to build referenced modules. But you typically don’t need to build the base Microsoft models. And while the symbols take a long to load the first time or two, they shouldn’t load slowly every time.
This was so helpful, thank you
You are welcome!!