|
| 1 | +--- |
| 2 | +title: Troubleshoot profiling errors |
| 3 | +description: Learn how to resolve possible profiling errors with error message guidance |
| 4 | +ms.date: 10/26/2022 |
| 5 | +ms.topic: how-to |
| 6 | +ms.assetid: |
| 7 | +author: mistymadonna |
| 8 | +ms.author: mihays |
| 9 | +manager: jmartens |
| 10 | +ms.technology: vs-ide-debug |
| 11 | +ms.workload: |
| 12 | + - "multiple" |
| 13 | +--- |
| 14 | +# Troubleshoot profiling errors and fix issues |
| 15 | + |
| 16 | +This article provides solutions for some of the most common errors that can prevent using or getting sufficient data from the Performance Profiler in Visual Studio. |
| 17 | + |
| 18 | +## No results |
| 19 | + |
| 20 | +Error: "There is no data in the current set of filters" |
| 21 | + |
| 22 | +When opening a *diagsession* file, certain filters are applied such as hiding native code, or hiding non-user code to make the trace easier to understand. Additionally, there are other filters that can be applied such as **time selection** and **thread**, which further narrow down the data shown. If these filters are applied in a way that there's no data remaining to show, then you'll see this warning. |
| 23 | + |
| 24 | +**How to fix** |
| 25 | +- Ensure that your time selection has data in it. If you’ve changed your time selection in the graph above the data, select **Clear Selection** to reset it. |
| 26 | +- Next, if there's still no data, ensure that all categories and threads are enabled in their respective dropdowns. |
| 27 | +- If the application you are profiling is native code, then be sure to enable the **Show Native Code** option in the **Settings** drop-down. |
| 28 | +- If you still have no data, then the trace you collected likely was too short for any data to be present. Make sure the program you're collecting data for does'nt complete too quickly (less than a second). |
| 29 | + |
| 30 | +See also: [Show External Code](../profiling/optimize-profiler-settings.md) |
| 31 | + |
| 32 | +## Taking a long time for the results to complete |
| 33 | + |
| 34 | +If analyzing the heap after collection seems slow to load, see the following possible solutions that can help resolve wait time issues. |
| 35 | + |
| 36 | +**How to fix** |
| 37 | +Sometimes it can take longer when trying to analyze snapshots from memory-intensive applications, but upgrading to a more recent version of Visual Studio should reduce the analysis wait time. If this issue is persistent after upgrading, there might be a performance bug on the tool. Create a feedback ticket and share the *diagsession* file that was created. With the file, we can determine why the data is slow to analyze and find where we can make performance improvements. |
| 38 | + |
| 39 | +Be sure to provide a trace and heap dump files in the Feedback ticket. |
| 40 | + |
| 41 | +See also: |
| 42 | +- [How to collect a ETW trace](../ide/how-to-report-a-problem-with-visual-studio.md) |
| 43 | +- [For symbol loading issues](../profiling/optimize-profiler-settings.md) |
| 44 | + |
| 45 | +## Error "Could not create a manifest file for this *diagsession*" or "error could not create manifest file for *diagsession*, Visual Studio will not able to reopen this session." |
| 46 | + |
| 47 | +This issue means there was a problem when preparing the memory snapshot data to be analyzed and displayed after stopping to collect data. There are multiple potential causes for the issue to appear, from a failure to get the correct information from the collection agents to the actual data processing. Therefore, it won't be possible to diagnose what the issue is without further logging. |
| 48 | + |
| 49 | +**How to fix** |
| 50 | +Reply to your Feedback ticket with additional logging information so that we can diagnose the issue. You can get the log information by running the following commands from an elevated command prompt: |
| 51 | + |
| 52 | +```console |
| 53 | +reg add HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\DiagnosticsHub /v LogLevel /t REG_SZ /d All /reg:32 |
| 54 | +reg add HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\DiagnosticsHub /v LogDirectory /t REG_SZ /d [directory of your choice] /reg:32 |
| 55 | +``` |
| 56 | + |
| 57 | +After running these commands, start Visual Studio, reproduce your scenario, close Visual Studio, then zip up your chosen DiagnosticsHub log directory and attach it to this ticket. From that point, we should be able to better diagnose what is happening. |
| 58 | + |
| 59 | +After adding the log to your ticket, run these commands to disable logging: |
| 60 | + |
| 61 | +```console |
| 62 | +reg delete HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\DiagnosticsHub /f /v LogLevel /reg:32 |
| 63 | +reg delete HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\DiagnosticsHub /f /v LogDirectory /reg:32 |
| 64 | +``` |
| 65 | + |
| 66 | +## Error: "Source information not available." |
| 67 | +In order to view source information, you need to have PDBs available from the time of collection. So, for example, if you collect a CPU usage |
| 68 | +*diagsession* file, make some changes to your code, recompile (which replaces the old PBD), then open the *.diagsession* again, you wouldn't likely be able to see source information for the modules of your code that you've updated. |
| 69 | + |
| 70 | +**How to fix** |
| 71 | +The easiest workaround for this issue is to collect a new *diagsession* after making changes. This way you can be sure your PDBs will be up to date. |
| 72 | + |
| 73 | +## Error: "Memory analysis failed due to an internal error." |
| 74 | + |
| 75 | +After a long memory profiling session, any attempt to analyze the result is met with the error. |
| 76 | + |
| 77 | +There was a mismatch between the snapshot information captured by the memory tool and that of the collection agent. This result means that the memory tool wasn't able to find the heap state file for a native snapshot. Or, this result the memory tool couldn't match the GC start time of the snapshot to the one registered in the *diagsession* file to retrieve the GCStats. |
| 78 | + |
| 79 | +**How to fix** |
| 80 | +This issue was due to a bug in the tool that was fixed in 17.3. Upgrading to a later version should solve the issue. If the issue is still persistent after upgrading, create a feedback ticket and attach to the ticket: |
| 81 | + |
| 82 | +- The *diagsession* file |
| 83 | +- A minidump of Visual Studio |
| 84 | +- A screenshot of the memory snapshots that were taken. |
| 85 | + |
| 86 | +There isn't a workaround for this issue and the profiling session will need to be restarted. |
| 87 | + |
| 88 | +## See also |
| 89 | + |
| 90 | +- [Analyze CPU usage](../profiling/cpu-usage.md) |
| 91 | +- [Identify hot paths with Flame Graph](../profiling/flame-graph.md) |
0 commit comments