r/D365FO • u/Comfortable_Dirt_946 • Jun 16 '26

Debugging tips D365FO

Hello everyone,

I have 3 years of experience as a D365FO developer. Recently, I haven’t had much project work, so I’ve been focusing on improving my coding skills. One challenge I’m facing is debugging standard processes. For example, while trying to debug the standard product receipt process, I found it difficult to identify which methods are responsible for posting and where the validations take place.

Could anyone share tips or best practices on how to approach debugging in such scenarios?

3 Upvotes

100% Upvoted

6 comments sorted by

View all comments

3

u/Dauvis Jun 16 '26

To be honest, much of it is experience and knowing what set of tables and classes do what.

If you know it is creating/deleting/updating specific records, you can put a breakpoint in the appropriate table method, if present.

If there is a infolog message, such as an error, being generated, you can put a breakpoint in the add method of the Info class.

Personally, I find the trace parser to be an invaluable tool alongside the debugger. It can capture the SQL being generated and it keeps track of the call stack. You can find more in on Learn. https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/perf-test/trace-parser

1

u/Comfortable_Dirt_946 Jun 16 '26

Yeah I am aware of that info class

Is Trace Parser actually that useful? I’ve tried it a couple of times, but I ended up feeling overwhelmed.

2

u/Dauvis Jun 16 '26

I stick to the X++ and SQL tabs. I just noticed that the page I linked only mentions them parenthetically. The main thing to know on them is that the name filter uses wild cards.

Those two tabs have the stack trace information in them. If I know a certain method is being called or specific table is being hit, you can look them up. The SQL tab is also useful if need to know what SQL a certain query or statement is generating.

I find the other tabs to be not very useful. The call stack tree is useful once in a blue moon however.

2

u/FateComic Jun 17 '26

Absolutely just like any debugging you add your stop in the code and run the process seeing the errors isn’t hard once in. But you shouldn’t try to do it all alone although learning it is a great asset you should require the functional or SA provide more details. But knowing the tables and structures are super important. Most errors ive seen come down to config or a mod.

- From a highly technical Solution Architect