Capturing a D365 trace in Dynamics 365 Finance & Supply Chain has never been easier. In older versions, users needed special access and had to follow a complex process. Today, anyone can generate a trace directly from the user interface with just a few clicks.
A D365 trace is one of the most effective tools for diagnosing performance issues. It produces a file that records all SQL and X++ code calls made during the session. The trace includes detailed information such as call stacks, execution counts, and timings for each call. These insights help you quickly identify the root cause of slowness and can even assist with debugging.
In this article, I’ll explain the basics of taking a D365 trace and share key tips for ensuring your trace captures useful data.
How to take a D365 trace
This section outlines the key steps to create a D365 trace. For more information, refer to Microsoft’s official documentation: Capture a trace – Finance & Operations | Dynamics 365 | Microsoft Learn
To open the sidebar for taking a trace, click the ‘?’ icon in the top ribbon bar, then select ‘Trace’ from the menu.
If the ‘Trace’ option doesn’t appear in the menu, you may need to assign the System tracing user role to the user. This role allows users to initiate a trace but does not grant permission to view or download captured traces.
Starting the D365 trace
After selecting the Trace option, a sidebar will appear with buttons to start a trace or view existing traces. For the trace name, choose any unique identifier. I recommend using a name that clearly describes the process you’re tracing. If you’re capturing multiple traces of the same process, append a number to the end of each file name for easy tracking.
Recent releases introduced a toggle to include SQL parameter values. Always enable this setting—it provides valuable details about the parameters used in each query, making analysis much easier.
Once you’ve set everything up, click Start trace. If a trace with the same name already exists, the system will display an error message.
Stopping the D365 trace
Wait for the next screen to confirm that the trace has started. Once the Stop trace button appears, begin the process you want to capture. When the process is complete, click Stop trace to proceed to the next screen.
Try to perform the process as quickly as possible between starting and stopping the trace. This helps ensure the trace captures only the relevant data and avoids extra noise that could make analysis more difficult.
Retrieval options
After the trace completes, you’ll have a few options for retrieving the file. The first option is to download the trace directly to your computer’s Downloads folder. However, if you experience any network issues, such as VPN restrictions or unstable connections, the download could fail, and you won’t be able to retry it.
Because of this, I recommend always choosing Upload trace. This uploads the file to the D365 environment, where it becomes accessible to anyone with the appropriate permissions. The file will remain available until the next database refresh, making it easy for other users to access and analyze.
Once you’ve selected your storage option, you can return to the main menu.
From the main menu, click Captured traces to view all trace files you’ve recorded and uploaded to the server. If you don’t see the trace you’re looking for, make sure you’re in the correct legal entity.
To download a trace file, simply select its name from the list.
Key considerations when taking a D365 trace
Now that we’ve covered the basic steps for capturing a trace, let’s explore some key considerations. These include file size limits, server constraints, and best practices for tracing long running or batch processes.
What a D365 trace captures
A D365 trace captures all SQL and X++ code statements executed during the trace, but only from a single AOS server. This means that the trace will include not only the process you’re tracing but also any other processes running on the same server. However, if your process triggers an operation (such as an async or SysOperation call) that sends the operation to another AOS, the trace won’t capture that portion of logic. One benefit of this setup is that another user connected to the same AOS can help capture the trace for the user performing the action. Also, keep in mind that a trace file will only capture SQL commands once they’re completed. If you stop the trace while a long-running SQL command is still in progress, the system will lose that data.
Trace size limitation
Unlike previous versions of Dynamics AX, where you could increase the file size of a trace, D365 is limited to 1 gigabyte. Once this 1 GB threshold is reached, any additional events will be dropped from the trace. As mentioned earlier, the trace captures events from all users connected to the same AOS. To manage file size, it’s best to run the trace when fewer users are active or in a sandbox environment where you can isolate the process.
When tracing a long-running process, I typically stop the trace after one minute. Then, I check the file size to determine how much longer I can run the trace in the future without exceeding the limit.
What information to pass along to reviewer
Since multiple users may be running processes on the same server, it’s helpful to capture the session ID for your specific process. When you review the trace file, the system groups events by session ID, so having this information helps you locate the correct grouping.
To find your session ID, go to the Feedback menu in the top ribbon bar. This will also show which AOS you’re connected to. Additionally, providing details such as the replication steps of the process and the estimated time it took to complete can be very helpful. While you can still analyze the trace to see the timings, including this information upfront will assist other reviewers.
D365 trace of a long-running process
Due to the file size limitation, capturing a trace for a long-running process can be challenging. The interactive session will freeze until the operation completes, preventing access to the Stop trace button. For this reason, I often recommend opening a second browser session. Perform the trace in that session while running the operation in the first session. As long as both sessions connect to the same AOS, the trace captures the relevant data.
To manage file size, I start and stop multiple traces based on when the file approaches its size limit. For processes that run for hours, I take traces at different stages of the operation—the beginning, middle, and end. Since these phases may involve different parts of the code, this approach provides a more complete sample without capturing the entire process.
D365 trace of a batch job
Tracing batch jobs can be more challenging. As mentioned earlier, you can only trace processes on an AOS to which you are connected. In D365, users cannot connect directly to the batch server, so tracing a batch job on a production server isn’t possible.
However, in cloud-hosted development environments, both the user and batch server are combined into a single AOS. If you can replicate the performance issue in a development environment, you can capture the trace there and gather the necessary information to diagnose the problem.
I’ve also noticed that some tier 2 sandbox environments are transitioning to a dual-purpose user/batch AOS. In these cases, as long as you’re connected to the same AOS where the batch job is running, the trace will capture the relevant data.
Changing your AOS connection
You can change which AOS instance you’re connected to by following these steps in the Chrome browser. While on a D365 browser page, press F12 to open the Developer Tools. In the top ribbon, navigate to the Application tab, then expand the Cookies section in the left-hand panel. Select the cookie associated with your environment name, and locate the ms-dyn-affinity cookie. In the screenshot above, the connection is to AOS1. To switch to a different AOS, modify this value accordingly and refresh your browser session. After making the change, always use the Feedback menu to confirm that you are connected to the intended AOS instance.
Conclusion
In this article, I’ve walked you through the process of capturing a D365 trace and highlighted key considerations to keep in mind. Tracing in D365 is one of my favorite techniques for diagnosing performance issues. I also use it to review code or understand which methods trigger during a business process.
In upcoming posts, I’ll dive into how to load a trace file into the Trace Parser tool and share the steps I follow to analyze traces effectively.
In the meantime, feel free to explore my related post, D365 Query Performance Utilizing the Query Store – My D365 Journey, where I discuss how I use the Query Store to analyze queries identified through a D365 trace.
