Training
Learning path
Use advance techniques in canvas apps to perform custom updates and optimization - Training
Use advance techniques in canvas apps to perform custom updates and optimization
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
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.
Error: "There is no data in the current set of filters"
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 see this warning.
How to fix
See also: Show External Code
If analyzing the heap after collection seems slow to load, see the following possible solutions that can help resolve wait time issues.
How to fix 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.
Be sure to provide a trace and heap dump files in the Feedback ticket.
See also:
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.
How to fix 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:
reg add HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\DiagnosticsHub /v LogLevel /t REG_SZ /d All /reg:32
reg add HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\DiagnosticsHub /v LogDirectory /t REG_SZ /d [directory of your choice] /reg:32
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.
After adding the log to your ticket, run these commands to disable logging:
reg delete HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\DiagnosticsHub /f /v LogLevel /reg:32
reg delete HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\DiagnosticsHub /f /v LogDirectory /reg:32
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 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 updated.
How to fix The easiest workaround for this issue is to collect a new diagsession after making changes. This way you can be sure your PDBs are up to date.
After a long memory profiling session, any attempt to analyze the result is met with the error.
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.
How to fix 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:
There isn't a workaround for this issue and the profiling session will need to be restarted.
Sometimes during data capture, events can be dropped that can cause the resulting profiling report to be inaccurate or unusable. Dropped events can happen for many different reasons, but it primarily occurs when the system is unable to flush events out to disk faster than the incoming rate.
How to fix To help reduce dropped events, you can close other disk- and CPU-intensive operations while profiling. By closing these operations, the system can dedicate more resources to flushing the incoming events. You can also try reducing the sampling frequencies on the tools that support these configuration settings, such as the CPU Usage tool and .NET Allocation tool, and thereby reduce overhead.
The Visual Studio profiler uses Event Tracing for Windows (ETW) to collect its performance information. There are a finite number of ETW sessions available for use on a system and if all the sessions are already in use you get the following error: ETW resources have been exhausted
. These sessions are used by other programs such as the SysInternals suite of tools, other profilers, and other diagnostic tools. You can resolve this issue by either:
Closing the programs that are using the sessions to free up resources, or
Setting aside more resources by running the following from an elevated command prompt and then rebooting:
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WMI" /v EtwMaxLoggers /t REG_DWORD /d 128
Running this command increases the default number of sessions from 64 to 128 (256 is the max number of sessions allowed on a system).
The Visual Studio profiler uses Event Tracing for Windows (ETW) to collect its performance information. Currently, collecting profile samples using ETW is unsupported on Windows for ARM64 when running in a Virtual Machine (VM). To work around this limitation, you can either use the CPU Usage tool on an actual ARM64 device or use the Instrumentation tool to capture timing information.
Due to an issue introduced with the .NET 7 runtime and propagated to .NET 8 runtime versions 8.0.0 and 8.0.1, it isn't possible to enumerate objects when using server garbage collection. Server garbage collection is enabled by default for ASP.NET Core applications.
How to fix
To work around this issue:
See also:
Training
Learning path
Use advance techniques in canvas apps to perform custom updates and optimization - Training
Use advance techniques in canvas apps to perform custom updates and optimization
Documentation
First look at profiling tools - Visual Studio (Windows)
Review the different diagnostic tools available in Visual Studio for profiling your C#, Visual Basic, C++, and F# applications.
CPU profiling in the Performance Profiler - Visual Studio (Windows)
Learn about the CPU profiler performance tool, which shows the CPU time and percentage spent executing code in C++, C#, Visual Basic, and JavaScript apps.
Run profiling tools on release or debug builds - Visual Studio (Windows)
Explore the differences between running profiling tools for your applications in Visual Studio on release or debug builds.