Skip to content

Update unsupported verssions of .NET in diagnostics documentation #39651

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from
Closed

Update unsupported verssions of .NET in diagnostics documentation #39651

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
18ac813
Update unsupported verssions of .NET in diagnostics documentation
tommcdon Feb 23, 2024
a8e35f0
Apply suggestions from code review
gewarren Aug 2, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
60 changes: 30 additions & 30 deletions docs/core/diagnostics/available-counters.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,27 +16,27 @@ The following counters are published as part of .NET runtime (CoreCLR) and are m

| Counter | Description | First available in |
|--|--|--|
| :::no-loc text="% Time in GC since last GC"::: (`time-in-gc`) | The percent of time in GC since the last GC | .NET Core 3.1 |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels more about when were they introduced rather than supported. Is this needed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we remove the column then? It doesn't feel useful to know when a particular counter was introduced if it predates all available versions of .NET.

Copy link
Member

@noahfalk noahfalk Feb 23, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think leaving the column as it was still might help clarify that these counters are not available on .NET Framework. It also preserves the structure of the table because some counters were introduced recently enough (.NET 7 for example) that we have supported versions that both do and do not have the counter. It would feel a little odd if some tables have the extra column but others don't depending on whether a counter was added in the last 3 years.

| :::no-loc text="Allocation Rate"::: (`alloc-rate`) | The number of bytes allocated per update interval | .NET Core 3.1 |
| :::no-loc text="CPU Usage"::: (`cpu-usage`) | The percent of the process's CPU usage relative to all of the system CPU resources | .NET Core 3.1 |
| :::no-loc text="Exception Count"::: (`exception-count`) | The number of exceptions that have occurred | .NET Core 3.1 |
| :::no-loc text="GC Heap Size"::: (`gc-heap-size`) | The number of megabytes thought to be allocated based on <xref:System.GC.GetTotalMemory(System.Boolean)?displayProperty=nameWithType> | .NET Core 3.1 |
| :::no-loc text="Gen 0 GC Count"::: (`gen-0-gc-count`) | The number of times GC has occurred for Gen 0 per update interval | .NET Core 3.1 |
| :::no-loc text="Gen 0 Size"::: (`gen-0-size`) | The number of bytes for Gen 0 GC | .NET Core 3.1 |
| :::no-loc text="Gen 1 GC Count"::: (`gen-1-gc-count`) | The number of times GC has occurred for Gen 1 per update interval | .NET Core 3.1 |
| :::no-loc text="Gen 1 Size"::: (`gen-1-size`) | The number of bytes for Gen 1 GC | .NET Core 3.1 |
| :::no-loc text="Gen 2 GC Count"::: (`gen-2-gc-count`) | The number of times GC has occurred for Gen 2 per update interval | .NET Core 3.1 |
| :::no-loc text="Gen 2 Size"::: (`gen-2-size`) | The number of bytes for Gen 2 GC | .NET Core 3.1 |
| :::no-loc text="LOH Size"::: (`loh-size`) | The number of bytes for the large object heap | .NET Core 3.1 |
| :::no-loc text="POH Size"::: (`poh-size`) | The number of bytes for the pinned object heap (available on .NET 5 and later versions) | .NET Core 3.1 |
| :::no-loc text="GC Fragmentation"::: (`gc-fragmentation`) | The GC Heap Fragmentation (available on .NET 5 and later versions) | .NET Core 3.1 |
| :::no-loc text="Monitor Lock Contention Count"::: (`monitor-lock-contention-count`) | The number of times there was contention when trying to take the monitor's lock, based on <xref:System.Threading.Monitor.LockContentionCount?displayProperty=nameWithType> | .NET Core 3.1 |
| :::no-loc text="Number of Active Timers"::: (`active-timer-count`) | The number of <xref:System.Threading.Timer> instances that are currently active, based on <xref:System.Threading.Timer.ActiveCount?displayProperty=nameWithType> | .NET Core 3.1 |
| :::no-loc text="Number of Assemblies Loaded"::: (`assembly-count`) | The number of <xref:System.Reflection.Assembly> instances loaded into a process at a point in time | .NET Core 3.1 |
| :::no-loc text="ThreadPool Completed Work Item Count"::: (`threadpool-completed-items-count`) | The number of work items that have been processed so far in the <xref:System.Threading.ThreadPool> | .NET Core 3.1 |
| :::no-loc text="ThreadPool Queue Length"::: (`threadpool-queue-length`) | The number of work items that are currently queued to be processed in the <xref:System.Threading.ThreadPool> | .NET Core 3.1 |
| :::no-loc text="ThreadPool Thread Count"::: (`threadpool-thread-count`) | The number of thread pool threads that currently exist in the <xref:System.Threading.ThreadPool>, based on <xref:System.Threading.ThreadPool.ThreadCount?displayProperty=nameWithType> | .NET Core 3.1 |
| :::no-loc text="Working Set"::: (`working-set`) | The number of megabytes of physical memory mapped to the process context at a point in time based on <xref:System.Environment.WorkingSet?displayProperty=nameWithType> | .NET Core 3.1 |
| :::no-loc text="% Time in GC since last GC"::: (`time-in-gc`) | The percent of time in GC since the last GC | .NET 6 |
| :::no-loc text="Allocation Rate"::: (`alloc-rate`) | The number of bytes allocated per update interval | .NET 6 |
| :::no-loc text="CPU Usage"::: (`cpu-usage`) | The percent of the process's CPU usage relative to all of the system CPU resources | .NET 6 |
| :::no-loc text="Exception Count"::: (`exception-count`) | The number of exceptions that have occurred | .NET 6 |
| :::no-loc text="GC Heap Size"::: (`gc-heap-size`) | The number of megabytes thought to be allocated based on <xref:System.GC.GetTotalMemory(System.Boolean)?displayProperty=nameWithType> | .NET 6 |
| :::no-loc text="Gen 0 GC Count"::: (`gen-0-gc-count`) | The number of times GC has occurred for Gen 0 per update interval | .NET 6 |
| :::no-loc text="Gen 0 Size"::: (`gen-0-size`) | The number of bytes for Gen 0 GC | .NET 6 |
| :::no-loc text="Gen 1 GC Count"::: (`gen-1-gc-count`) | The number of times GC has occurred for Gen 1 per update interval | .NET 6 |
| :::no-loc text="Gen 1 Size"::: (`gen-1-size`) | The number of bytes for Gen 1 GC | .NET 6 |
| :::no-loc text="Gen 2 GC Count"::: (`gen-2-gc-count`) | The number of times GC has occurred for Gen 2 per update interval | .NET 6 |
| :::no-loc text="Gen 2 Size"::: (`gen-2-size`) | The number of bytes for Gen 2 GC | .NET 6 |
| :::no-loc text="LOH Size"::: (`loh-size`) | The number of bytes for the large object heap | .NET 6 |
| :::no-loc text="POH Size"::: (`poh-size`) | The number of bytes for the pinned object heap (available on .NET 5 and later versions) | .NET 6 |
| :::no-loc text="GC Fragmentation"::: (`gc-fragmentation`) | The GC Heap Fragmentation (available on .NET 5 and later versions) | .NET 6 |
| :::no-loc text="Monitor Lock Contention Count"::: (`monitor-lock-contention-count`) | The number of times there was contention when trying to take the monitor's lock, based on <xref:System.Threading.Monitor.LockContentionCount?displayProperty=nameWithType> | .NET 6 |
| :::no-loc text="Number of Active Timers"::: (`active-timer-count`) | The number of <xref:System.Threading.Timer> instances that are currently active, based on <xref:System.Threading.Timer.ActiveCount?displayProperty=nameWithType> | .NET 6 |
| :::no-loc text="Number of Assemblies Loaded"::: (`assembly-count`) | The number of <xref:System.Reflection.Assembly> instances loaded into a process at a point in time | .NET 6 |
| :::no-loc text="ThreadPool Completed Work Item Count"::: (`threadpool-completed-items-count`) | The number of work items that have been processed so far in the <xref:System.Threading.ThreadPool> | .NET 6 |
| :::no-loc text="ThreadPool Queue Length"::: (`threadpool-queue-length`) | The number of work items that are currently queued to be processed in the <xref:System.Threading.ThreadPool> | .NET 6 |
| :::no-loc text="ThreadPool Thread Count"::: (`threadpool-thread-count`) | The number of thread pool threads that currently exist in the <xref:System.Threading.ThreadPool>, based on <xref:System.Threading.ThreadPool.ThreadCount?displayProperty=nameWithType> | .NET 6 |
| :::no-loc text="Working Set"::: (`working-set`) | The number of megabytes of physical memory mapped to the process context at a point in time based on <xref:System.Environment.WorkingSet?displayProperty=nameWithType> | .NET 6 |
| :::no-loc text="IL Bytes Jitted"::: (`il-bytes-jitted`) | The total size of ILs that are JIT-compiled, in bytes | .NET 5 |
| :::no-loc text="Methods Jitted Count"::: (`methods-jitted-count`) | The number of methods that are JIT-compiled | .NET 5 |
| :::no-loc text="GC Committed Bytes"::: (`gc-committed`) | The number of bytes committed by the GC | .NET 6 |
Expand All @@ -47,22 +47,22 @@ The following counters are published as part of [ASP.NET Core](/aspnet/core) and

| Counter | Description | First available in |
|--|--|--|
| :::no-loc text="Current Requests"::: (`current-requests`) | The total number of requests that have started, but not yet stopped | .NET Core 3.1 |
| :::no-loc text="Failed Requests"::: (`failed-requests`) | The total number of failed requests that have occurred for the life of the app | .NET Core 3.1 |
| :::no-loc text="Request Rate"::: (`requests-per-second`) | The number of requests that occur per update interval | .NET Core 3.1 |
| :::no-loc text="Total Requests"::: (`total-requests`) | The total number of requests that have occurred for the life of the app | .NET Core 3.1 |
| :::no-loc text="Current Requests"::: (`current-requests`) | The total number of requests that have started, but not yet stopped | .NET 6 |
| :::no-loc text="Failed Requests"::: (`failed-requests`) | The total number of failed requests that have occurred for the life of the app | .NET 6 |
| :::no-loc text="Request Rate"::: (`requests-per-second`) | The number of requests that occur per update interval | .NET 6 |
| :::no-loc text="Total Requests"::: (`total-requests`) | The total number of requests that have occurred for the life of the app | .NET 6 |

## Microsoft.AspNetCore.Http.Connections counters

The following counters are published as part of [ASP.NET Core SignalR](/aspnet/core/signalr/introduction) and are maintained in [`HttpConnectionsEventSource.cs`](https://github.com/dotnet/aspnetcore/blob/main/src/SignalR/common/Http.Connections/src/Internal/HttpConnectionsEventSource.cs).

| Counter | Description | First available in |
|--|--|--|
| :::no-loc text="Average Connection Duration"::: (`connections-duration`) | The average duration of a connection in milliseconds | .NET Core 3.1 |
| :::no-loc text="Current Connections"::: (`current-connections`) | The number of active connections that have started, but not yet stopped | .NET Core 3.1 |
| :::no-loc text="Total Connections Started"::: (`connections-started`) | The total number of connections that have started | .NET Core 3.1 |
| :::no-loc text="Total Connections Stopped"::: (`connections-stopped`) | The total number of connections that have stopped | .NET Core 3.1 |
| :::no-loc text="Total Connections Timed Out"::: (`connections-timed-out`) | The total number of connections that have timed out | .NET Core 3.1 |
| :::no-loc text="Average Connection Duration"::: (`connections-duration`) | The average duration of a connection in milliseconds | .NET 6 |
| :::no-loc text="Current Connections"::: (`current-connections`) | The number of active connections that have started, but not yet stopped | .NET 6 |
| :::no-loc text="Total Connections Started"::: (`connections-started`) | The total number of connections that have started | .NET 6 |
| :::no-loc text="Total Connections Stopped"::: (`connections-stopped`) | The total number of connections that have stopped | .NET 6 |
| :::no-loc text="Total Connections Timed Out"::: (`connections-timed-out`) | The total number of connections that have timed out | .NET 6 |

## Microsoft-AspNetCore-Server-Kestrel counters

Expand Down
2 changes: 1 addition & 1 deletion docs/core/diagnostics/compare-metric-apis.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -57,7 +57,7 @@ For more information, see [Performance counters in .NET Framework](../../framewo
### EventCounters

The [EventCounters](event-counters.md) API came next after `PerformanceCounters`. This API aimed to provide a uniform
cross-platform experience. The APIs are available by targeting .NET Core 3.1+, and a small subset is available on .NET Framework 4.7.1
cross-platform experience. The APIs were first introduced in .NET Core 3.1, and a small subset was introduced on .NET Framework 4.7.1
and above. These APIs are fully supported and are actively used by key .NET libraries, but they
have less functionality than the newer <xref:System.Diagnostics.Metrics?displayProperty=nameWithType> APIs. EventCounters are able to report
rates of change and averages, but do not support histograms and percentiles. There is also no support for multi-dimensional metrics. Custom
Expand Down
4 changes: 2 additions & 2 deletions docs/core/diagnostics/debug-deadlock.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ ms.date: 07/20/2020

# Debug a deadlock in .NET Core

**This article applies to: ✔️** .NET Core 3.1 SDK and later versions
**This article applies to: ✔️** .NET 6 SDK and later versions

In this tutorial, you'll learn how to debug a deadlock scenario. Using the provided example [ASP.NET Core web app](/samples/dotnet/samples/diagnostic-scenarios) source code repository, you can cause a deadlock intentionally. The endpoint will stop responding and experience thread accumulation. You'll learn how you can use various tools to analyze the problem, such as core dumps, core dump analysis, and process tracing.

Expand All @@ -25,7 +25,7 @@ In this tutorial, you will:

The tutorial uses:

- [.NET Core 3.1 SDK](https://dotnet.microsoft.com/download/dotnet) or a later version
- [.NET 6 SDK](https://dotnet.microsoft.com/download/dotnet) or a later version
- [Sample debug target - web app](/samples/dotnet/samples/diagnostic-scenarios) to trigger the scenario
- [dotnet-trace](dotnet-trace.md) to list processes
- [dotnet-dump](dotnet-dump.md) to collect, and analyze a dump file
Expand Down
4 changes: 2 additions & 2 deletions docs/core/diagnostics/debug-highcpu.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ ms.date: 07/20/2020

# Debug high CPU usage in .NET Core

**This article applies to: ✔️** .NET Core 3.1 SDK and later versions
**This article applies to: ✔️** .NET 6 SDK and later versions

In this tutorial, you'll learn how to debug an excessive CPU usage scenario. Using the provided example [ASP.NET Core web app](/samples/dotnet/samples/diagnostic-scenarios) source code repository, you can cause a deadlock intentionally. The endpoint will stop responding and experience thread accumulation. You'll learn how you can use various tools to diagnose this scenario with several key pieces of diagnostics data.

Expand All @@ -25,7 +25,7 @@ In this tutorial, you will:

The tutorial uses:

- [.NET Core 3.1 SDK](https://dotnet.microsoft.com/download/dotnet) or a later version.
- [.NET 6 SDK](https://dotnet.microsoft.com/download/dotnet) or a later version.
- [Sample debug target](/samples/dotnet/samples/diagnostic-scenarios) to trigger the scenario.
- [dotnet-trace](dotnet-trace.md) to list processes and generate a profile.
- [dotnet-counters](dotnet-counters.md) to monitor cpu usage.
Expand Down
2 changes: 1 addition & 1 deletion docs/core/diagnostics/debug-linux-dumps.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -49,7 +49,7 @@ Once LLDB starts, it may be necessary to use the `setsymbolserver` command to po
Dumps collected from a Linux machine can also be analyzed on a Windows machine using [Visual Studio](/visualstudio/debugger/using-dump-files), [Windbg](/windows-hardware/drivers/debugger/analyzing-a-user-mode-dump-file), or the [dotnet-dump](dotnet-dump.md) tool. Both Visual Studio and Windbg can analyze native and managed code, while dotnet-dump only analyzes managed code.

> [!NOTE]
> Visual Studio version 16.8 and later allows you to [open and analyze Linux dumps](https://devblogs.microsoft.com/visualstudio/linux-managed-memory-dump-debugging/) generated on .NET Core 3.1.7 or later.
> Visual Studio version 16.8 and later allows you to [open and analyze Linux dumps](https://devblogs.microsoft.com/visualstudio/linux-managed-memory-dump-debugging/).

- **Visual Studio** - See the [Visual Studio dump debugging guide](/visualstudio/debugger/using-dump-files).
- **Windbg** - You can debug Linux dumps on windbg using the [same instructions](/windows-hardware/drivers/debugger/analyzing-a-user-mode-dump-file) you would use to debug a Windows user-mode dump. Use the x64 version of windbg for dumps collected from a Linux x64 or Arm64 environment and the
Expand Down
4 changes: 2 additions & 2 deletions docs/core/diagnostics/debug-memory-leak.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ ms.date: 11/13/2023

# Debug a memory leak in .NET

**This article applies to:** ✔️ .NET Core 3.1 SDK and later versions
**This article applies to:** ✔️ .NET 6 SDK and later versions

Memory can leak when your app references objects that it no longer needs to perform the desired task. Referencing these objects prevents the garbage collector from reclaiming the memory used. That can result in performance degradation and an <xref:System.OutOfMemoryException> exception being thrown.

Expand All @@ -27,7 +27,7 @@ In this tutorial, you will:

The tutorial uses:

- [.NET Core 3.1 SDK](https://dotnet.microsoft.com/download/dotnet) or a later version.
- [.NET 6 SDK](https://dotnet.microsoft.com/download/dotnet) or a later version.
- [dotnet-counters](dotnet-counters.md) to check managed memory usage.
- [dotnet-dump](dotnet-dump.md) to collect and analyze a dump file (includes the [SOS debugging extension](sos-debugging-extension.md)).
- A [sample debug target](/samples/dotnet/samples/diagnostic-scenarios/) app to diagnose.
Expand Down
2 changes: 1 addition & 1 deletion docs/core/diagnostics/debug-threadpool-starvation.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ ms.date: 04/19/2022

# Debug ThreadPool Starvation

**This article applies to: ✔️** .NET Core 3.1 and later versions
**This article applies to: ✔️** .NET 6 and later versions

In this tutorial, you'll learn how to debug a ThreadPool starvation scenario. ThreadPool starvation occurs when the pool has no available threads to process new work items and it often causes applications to respond slowly. Using the provided example [ASP.NET Core web app](/samples/dotnet/samples/diagnostic-scenarios), you can cause ThreadPool starvation intentionally and learn how to diagnose it.

Expand Down
2 changes: 1 addition & 1 deletion docs/core/diagnostics/debug-windows-dumps.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ ms.date: 01/11/2023

# Debug Windows dumps

**This article applies to: ✔️** .NET Core 3.1 and later versions
**This article applies to: ✔️** .NET 6 and later versions

## Analyze dumps on Windows

Expand Down
2 changes: 1 addition & 1 deletion docs/core/diagnostics/diagnostic-port.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ ms.topic: overview

# Diagnostic ports

**This article applies to: ✔️** .NET Core 3.1 and later versions
**This article applies to: ✔️** .NET 6 and later versions

The .NET runtime exposes a service endpoint that allows other processes to send diagnostic commands and receive responses over an [IPC channel](https://en.wikipedia.org/wiki/Inter-process_communication). This endpoint is called a *diagnostic port*. Commands can be sent to the diagnostic port to:

Expand Down
4 changes: 2 additions & 2 deletions docs/core/diagnostics/diagnostics-in-containers.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,9 +10,9 @@ The same diagnostics tools that are useful for diagnosing .NET Core issues in ot

## Using .NET CLI tools in a container

**These tools apply to: ✔️** .NET Core 3.1 SDK and later versions
**These tools apply to: ✔️** .NET 6 SDK and later versions

The .NET Core global CLI diagnostic tools ([dotnet-counters](dotnet-counters.md), [dotnet-dump](dotnet-dump.md), [dotnet-gcdump](dotnet-gcdump.md), [dotnet-monitor](dotnet-monitor.md), and [dotnet-trace](dotnet-trace.md)) are designed to work in a wide variety of environments and should all work directly in Docker containers. Because of this, these tools are the preferred method of collecting diagnostic information for .NET Core scenarios targeting .NET Core 3.1 or later in containers.
The .NET Core global CLI diagnostic tools ([dotnet-counters](dotnet-counters.md), [dotnet-dump](dotnet-dump.md), [dotnet-gcdump](dotnet-gcdump.md), [dotnet-monitor](dotnet-monitor.md), and [dotnet-trace](dotnet-trace.md)) are designed to work in a wide variety of environments and should all work directly in Docker containers. Because of this, these tools are the preferred method of collecting diagnostic information for .NET Core scenarios targeting .NET 6 or later in containers.

You can also install these tools without the .NET SDK by downloading the single-file variants from the links in the previous paragraph. These installs require a global install of the .NET runtime version 3.1 or later, which you can acquire following any of the prescribed methods in the [.NET installation documentation](../install/index.yml) or by consuming any of the official runtime containers.

Expand Down
2 changes: 1 addition & 1 deletion docs/core/diagnostics/diagnosticsource-diagnosticlistener.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ ms.date: 05/12/2022
---
# DiagnosticSource and DiagnosticListener

**This article applies to: ✔️** .NET Core 3.1 and later versions **✔️** .NET Framework 4.5 and later versions
**This article applies to: ✔️** .NET 6 and later versions **✔️** .NET Framework 4.5 and later versions

<xref:System.Diagnostics.DiagnosticSource?displayProperty=nameWithType> is a module that allows code to be instrumented for production-time
logging of rich data payloads for consumption within the process that was instrumented. At run time, consumers can dynamically discover
Expand Down
Loading
Loading