Loading D365 traces works much like it did in Dynamics AX 2012, but with Dynamics 365 Finance & Supply Chain, the process becomes even easier. You no longer need to install the Dynamics Trace Parser tool manually—cloud-hosted environments already include it by default. You can also find the TraceParser.msi installer directly on a cloud-hosted box or within the downloads when setting up a Unified Developer Experience (UDE) environment, allowing you to install it locally if needed.
In my previous article, D365 Trace – My D365 Journey, I explained how to create a trace. This article will guide you through the process of importing a trace and selecting the correct session for analysis.
For more details from Microsoft on using Trace Parser, check out Diagnose issues and analyze performance by using Trace parser – Finance & Operations | Dynamics 365 | Microsoft Learn.
Setting up trace parser for loading D365 traces.
After connecting to a cloud-hosted environment, search for the application Microsoft Dynamics 365 Unified Operations – Trace Parser and launch it. Ideally, load the trace from the same environment that contains the code and customizations under review. This setup allows the Trace Parser tool to display both your custom code and the standard Microsoft base code during analysis. I’ll cover this in more detail in my next article.
If you’re running Trace Parser for the first time, you’ll need to create the database before importing any traces. For the Server Name, enter . to use the local server, or specify the name of a different SQL Server instance if needed. For the Database Name, you can enter any name you like—I usually go with TraceParser. If I create multiple databases, I’ll append a number to keep track of each iteration.
After you select Register, the tool prompts you to confirm database creation. Click Yes to proceed.
Importing the trace file
Once the database is created or the tool is launched, a form appears. If traces have already been loaded, they will be listed on the screen. You can open one by selecting it and clicking Open Trace. To load a new trace, click the Import Trace button instead.
Select the trace file you want to import. Trace files use the .etl extension. After selecting the file, click Open to begin the import process.
You’ll see a couple of progress bars as the file loads. This process may take a few minutes, depending on how many events the trace captured. The first progress bar shows that the selected file is loading.
After the file finishes loading, a second progress bar appears while the tool writes the trace data to the database. You can also monitor this process in SQL Server Management Studio using the Activity screen.
Once the trace file loads, the tool displays overview details and lets you select a specific session to review.
Selecting the correct session
A D365 trace captures sessions from every user active on the server at the time of tracing. To focus on specific users or actions, you need to select the right session from your trace file. Since many users can be active at once, the list of sessions can get quite long. That’s why, in my previous article, I recommend running traces on a sandbox environment or when the system is quiet. Below are a few methods I use to select the correct session.
This screenshot shows the different sessions captured in the trace file I loaded.
Selecting from the session ID
If the user recorded their session information when capturing the trace (as discussed in my previous article), you can compare it to the UserName field in the trace file.
Selecting from the user ID
If the session ID wasn’t captured during the trace, you can still filter by using the ‘UserName’ field. To find the corresponding user name, navigate to System administration > Users > Users, then match the Telemetry ID field on that form to the UserName field in the trace file. This approach helps identify the user associated with a given trace entry when session details are unavailable.
Selecting by sorting by total activity
When neither the session ID nor the username is known, the method I primarily use is to sort by the SqlAggregateTime and XppAggregateExclusiveDuration fields. In most cases, you review a trace file because of a performance issue. So, the sessions with the highest time spent in either SQL statements or X++ code are usually the ones worth investigating.
Once a Session ID is selected from the drop-down, the trace parser tool will populate detailed information for that specific session. I also like to verify that it’s the correct session by matching the SQL queries or X++ code to the operations that were being performed during the trace. This extra step helps ensure I’m analyzing the right context. I’ll go into more detail on how to do that in my next article.
Errors when loading D365 traces
Occasionally, when loading D365 trace files, I encounter errors. One common example is a message indicating that events were dropped. This often happens when the trace file exceeds 1 gigabyte in size. In most cases, the file is still usable for analysis, but some data may be missing.
Another error you might see is that no readable data is available. When this occurs, the file may be unusable, and no data is loaded. However, in some instances, the issue lies with the database itself. In those cases, I recommend testing the trace in another environment or creating a new database with a different name.
To create a new empty database, go to the File menu and select Register database. After importing multiple trace files over time, I sometimes notice a slowdown in performance when loading new ones. When that happens, I typically create a new database to ensure smooth operation for future trace file imports.
Improving the speed of loading D365 traces
There are a few database settings that can help improve the speed of loading D365 trace files. To begin, launch SQL Server Management Studio (SSMS) and select the database you created for use with Trace Parser.
Right-click the database name and select Properties. Then navigate to the Options page and change the Recovery Model from Full to Simple. Since we use this database only for trace analysis and don’t need data recovery or backups, choosing the Simple recovery model is more appropriate. The Full recovery model adds overhead by continuously writing detailed transaction logs to support point-in-time recovery. Since that’s unnecessary for this scenario, switching to Simple helps minimize log growth and improves performance during trace imports.
You can make another helpful modification under the Files page of the database properties. Increase the file autogrowth settings from their default values. Since trace files can be quite large, it’s important to reduce the number of autogrowth events during import. I typically increase the ROWS Data file autogrowth from the default 64 MB to 1024 MB, and the LOG file from 64 MB to 512 MB. These larger growth increments help minimize interruptions caused by frequent autogrowth operations, which can negatively affect performance during trace loading.
Conclusion
In this article, I walked through the process of loading a D365 trace file, including how to register a trace database, select the appropriate session, and apply key optimizations to improve trace loading performance.
In the next article, I’ll focus on what to do after loading the trace — how to interpret the data, identify bottlenecks, and extract meaningful performance insights. Stay tuned for practical tips on navigating and analyzing trace results efficiently.
