Power BI Desktop Diagnostics - What to Send Microsoft Support and Why

One of the least talked about features in Power BI Desktop is the diagnostics collector. Most people will never touch it. But the ones who do tend to be in a bad spot - report won't open, refresh is failing for no obvious reason, Desktop keeps crashing on a specific file. That's usually when someone in our team gets a panicked email asking if there's any way to figure out what's actually happening.

The Power BI Desktop diagnostics tool is genuinely useful when things are broken, and largely useless when things are fine. Microsoft documents it in their Power BI Desktop diagnostics article, and the documentation is accurate. What it does not really tell you is when to use it, what to expect when you read the output, and what the limitations are.

So here's the practical version, from someone who has read more .trc files than is healthy for one person.

When to actually use diagnostics

Microsoft says you should only collect diagnostics when support asks you to. Fair guidance, and you should follow it if you're working a support ticket. But in real consulting work, there are a few scenarios where collecting diagnostics is the right first move regardless of whether anyone asked.

The first is when Power BI Desktop crashes on a specific file. Maybe the .pbix opens fine, you click on a particular visual, and the whole thing falls over. Or it crashes part way through refresh. In these cases, the trace files contain the actual stack of what was happening when it died, which is gold for debugging.

The second is when a model is slow in ways you can't explain. You've got a 2GB .pbix that takes 90 seconds to render a visual, and you've already optimised the obvious stuff. The Analysis Services trace inside the diagnostics package shows you the actual DAX queries running and how long each one took. We've used this to find horror stories like a visual issuing 47 separate queries because someone accidentally added a slicer that disabled query folding.

The third is when you need to understand a model someone else built. Power BI Desktop has a model view, but the diagnostics package gives you a clean text description of every table, column, relationship, measure, and role. Sometimes that's faster to read than clicking through the UI, especially on a model with hundreds of objects.

This is the kind of thing our Power BI consulting team ends up doing when a client brings us in to fix or take over a report that's been built and rebuilt by four different people. The diagnostics output is often the fastest way to see what's actually in the model versus what people say is in the model.

What gets collected

The diagnostics zip contains a bunch of files. Not all of them appear every time - what you get depends on what happened on your machine and whether tracing was on when the problem occurred.

The useful ones, in roughly the order I open them when investigating:

AnalysisServicesInfo.trc is the trace file from the embedded Analysis Services engine. Open this in SQL Server Profiler if you have it, or in any tool that reads .trc files. It shows every query run during the session, with timings. If a report is slow, this is where you find the slow query.

SessionDeviceInfo.txt tells you what version of Power BI Desktop was running, what the operating system was, how much RAM was on the box, whether DirectQuery options were on, time zone configuration, all the environmental stuff that matters for reproducing issues. It also tells you which cloud tenant you were signed into, useful when you suspect a permissions or workspace issue.

ErrorsInfo.yaml shows up only if an error dialog was displayed during the session. So if Power BI Desktop showed a nasty "something went wrong" popup, the details are here. The error text is often more informative than what was shown in the dialog.

CSDL.xml, DatabaseSchema.json, and DataModelSchema.json all describe the structure of the data model. They overlap significantly. I usually open DataModelSchema.json first because the structure is the most readable. You get every table, every column, every measure with its DAX, every relationship, every role with its security predicates. This is the cleanest way to see what's actually in a model.

QueryEvaluations.json contains the results of Power Query operations during load or refresh. Useful when refresh is failing or returning unexpected data.

AutoPageRefresh.json lists data refresh settings. Mostly relevant if you suspect auto refresh is configured in a way you don't expect.

Traces/ folder contains the lower level trace data. Honestly I usually skim past this unless I'm escalating something to Microsoft.

How to actually collect it

Microsoft's UI is reasonable but worth walking through. File, Options and settings, Options, Global, Diagnostics. Tick "Enable tracing." Click "Collect diagnostic information." Power BI Desktop bundles up the available data into a zip file with a timestamp in the name and drops it in your Documents folder by default.

The catch is that "Enable tracing" needs to be on before you reproduce the problem. If you turn it on after the crash, you won't have the trace data for the crash. This bites people regularly. If you're investigating something intermittent, leave tracing on for a few days while you wait for it to happen again.

There's also a separate trick for Power Query traces, which the documentation mentions but is easy to miss. Go to %localappdata%\Microsoft\Power BI Desktop\Traces and clear it out first. Reproduce the issue. Close Power BI Desktop entirely so the buffers flush. Then zip the Traces folder yourself.

If you're using the Microsoft Store version of Power BI Desktop, the path is different: %userprofile%\Microsoft\Power BI Desktop Store App\Traces. We've had clients hand over diagnostics zips that were missing data because they were looking in the wrong folder. Annoying but easy to fix once you know.

What the diagnostics will not tell you

The diagnostics package covers a lot but it has limits worth understanding.

It does not capture the visual state of the report. It tells you which queries ran, but not which visuals were on screen when. If a particular visual is misbehaving, you may need to take a screenshot or screen recording to go alongside the trace.

It does not capture the data itself. The Analysis Services trace shows the SQL or DAX queries being run, but not the rows returned. If you suspect a data quality issue, you'll need to query the source separately.

It does not capture gateway logs. If you're investigating a refresh failure that involves the on-premises data gateway, the gateway has its own log files in %localappdata%\Microsoft\On-premises data gateway that are completely separate from Power BI Desktop diagnostics.

It does not capture network traces. If you suspect a latency or auth issue talking to a source, you need Fiddler or Wireshark separately.

And the obvious one: it does not run on the Power BI service. Service-side diagnostics live in workspace settings and the admin portal. Different beast entirely.

Privacy considerations worth knowing

The diagnostic data contains some things you should think about before sending. The Analysis Services trace logs full DAX queries, which means it logs filter values used in those queries. If your report has a filter for "Customer = ACME Pty Ltd" applied when you collect diagnostics, that string will be in the trace. For most clients this is fine. For organisations dealing with personal or financial data under strict controls, it's worth flagging before just emailing the zip to someone.

The data model schema files contain column names and table names, which are sometimes sensitive in themselves. Healthcare clients especially get nervous about this. If you're working with a privacy sensitive client, get sign off before shipping diagnostics out to Microsoft or anyone else. Our healthcare AI work has hit this a few times and it's easier to ask before than apologise after.

When to call for help

If you've collected diagnostics and you're still stuck, that's usually when bringing in someone with experience makes sense. Reading these files is a skill, and it's a skill that takes a while to build. Microsoft Support are reasonably good at it once you get to the right tier, but tickets can take time.

We have done enough Power BI diagnostic work over the years that we can usually identify the root cause from the trace files in under an hour. Whether that's worth paying for depends on how much your team's time is worth and how badly broken the report is. Get in touch if it's the kind of fire you want help putting out, or have a look at our Microsoft Fabric consulting work if you're at the point where you're thinking about a bigger architectural rethink.

Reference

The Microsoft source for diagnostic collection is at Collect and submit diagnostic information.