dotnet · gewarren · Sep 12, 2025 · Sep 12, 2025
@@ -44,9 +44,9 @@ byte[] output = new byte[targetSize];
 
 ## Affected APIs
 
-- <xref:System.Security.Cryptography.MLDsa.ImportMLDsaSecretKey*?displayProperty=fullName>
-- <xref:System.Security.Cryptography.MLDsa.ExportMLDsaSecretKey*?displayProperty=fullName>
-- <xref:System.Security.Cryptography.MLDsaAlgorithm.SecretKeySizeInBytes?displayProperty=fullName>
-- <xref:System.Security.Cryptography.SlhDsa.ImportSlhDsaSecretKey*?displayProperty=fullName>
-- <xref:System.Security.Cryptography.SlhDsa.ExportSlhDsaSecretKey*?displayProperty=fullName>
-- <xref:System.Security.Cryptography.SlhDsaAlgorithm.SecretKeySizeInBytes?displayProperty=fullName>
+- `System.Security.Cryptography.MLDsa.ImportMLDsaSecretKey()`
+- `System.Security.Cryptography.MLDsa.ExportMLDsaSecretKey()`
+- `System.Security.Cryptography.MLDsaAlgorithm.SecretKeySizeInBytes`
+- `System.Security.Cryptography.SlhDsa.ImportSlhDsaSecretKey()`
+- `System.Security.Cryptography.SlhDsa.ExportSlhDsaSecretKey()`
+- `System.Security.Cryptography.SlhDsaAlgorithm.SecretKeySizeInBytes`
@@ -48,7 +48,7 @@ dotnet-counters [-h|--help] [--version] <command>
 
 - **`--version`**
 
-  Displays the version of the dotnet-counters utility.
+  Displays the version of the `dotnet-counters` utility.
 
 - **`-h|--help`**
 
@@ -90,15 +90,15 @@ dotnet-counters collect [-h|--help] [-p|--process-id] [-n|--name] [--diagnostic-
 
 - **`--diagnostic-port <port-address[,(listen|connect)]>`**
 
-  Sets the [diagnostic port](diagnostic-port.md) used to communicate with the process to be monitored. dotnet-counters and the .NET runtime inside the target process must agree on the port-address, with one listening and the other connecting. dotnet-counters automatically determines the correct port when attaching using the `--process-id` or `--name` options, or when launching a process using the `-- <command>` option. It's usually only necessary to specify the port explicitly when waiting for a process that will start in the future or communicating to a process that is running inside a container that isn't part of the current process namespace.
+  Sets the [diagnostic port](diagnostic-port.md) used to communicate with the process to be monitored. `dotnet-counters` and the .NET runtime inside the target process must agree on the port-address, with one listening and the other connecting. `dotnet-counters` automatically determines the correct port when attaching using the `--process-id` or `--name` options, or when launching a process using the `-- <command>` option. It's usually only necessary to specify the port explicitly when waiting for a process that will start in the future or communicating to a process that's running inside a container that isn't part of the current process namespace.
 
   The `port-address` differs by OS:
 
   - Linux and macOS - a path to a Unix domain socket such as `/foo/tool1.socket`.
   - Windows - a path to a named pipe such as `\\.\pipe\my_diag_port1`.
   - Android, iOS, and tvOS - an IP:port such as `127.0.0.1:9000`.
-  
-  By default, dotnet-counters listens at the specified address. You can request dotnet-counters to connect instead by appending `,connect` after the address. For example, `--diagnostic-port /foo/tool1.socket,connect` will connect to a .NET runtime process that's listening to the `/foo/tool1.socket` Unix domain socket.
+
+  By default, `dotnet-counters` listens at the specified address. You can request `dotnet-counters` to connect instead by appending `,connect` after the address. For example, `--diagnostic-port /foo/tool1.socket,connect` will connect to a .NET runtime process that's listening to the `/foo/tool1.socket` Unix domain socket.
 
   For information about how to use this option to start monitoring counters from app startup, see [using diagnostic port](#using-diagnostic-port).
 
@@ -108,7 +108,7 @@ dotnet-counters collect [-h|--help] [-p|--process-id] [-n|--name] [--diagnostic-
 
 - **`--counters <COUNTERS>`**
 
-  A comma-separated list of counters. Counters can be specified `provider_name[:counter_name]`. If the `provider_name` is used without a qualifying list of counters, then all counters from the provider are shown. To discover provider and counter names, consult [built-in metrics docs](https://learn.microsoft.com/dotnet/core/diagnostics/built-in-metrics). For [EventCounters](event-counters.md), `provider_name` is the name of the EventSource and for [Meters](metrics.md), `provider_name` is the name of the Meter.
+  A comma-separated list of counters. Counters can be specified `provider_name[:counter_name]`. If the `provider_name` is used without a qualifying list of counters, then all counters from the provider are shown. To discover provider and counter names, see [built-in metrics](built-in-metrics.md). For [EventCounters](event-counters.md), `provider_name` is the name of the EventSource and for [Meters](metrics.md), `provider_name` is the name of the Meter.
 
 - **`--format <csv|json>`**
 
@@ -120,13 +120,13 @@ dotnet-counters collect [-h|--help] [-p|--process-id] [-n|--name] [--diagnostic-
 
 - **`-- <command>`**
 
-  After the collection configuration parameters, the user can append `--` followed by a command to start a .NET application. `dotnet-counters` will launch a process with the provided command and collect the requested metrics. This is often useful to collect metrics for the application's startup path and can be used to diagnose or monitor issues that happen early before or shortly after the main entrypoint.
+  After the collection configuration parameters, the user can append `--` followed by a command to start a .NET application. `dotnet-counters` launches a process with the provided command and collect the requested metrics. This is often useful to collect metrics for the application's startup path and can be used to diagnose or monitor issues that happen early before or shortly after the main entry point.
 
   > [!NOTE]
-  > Using this option monitors the first .NET process that communicates back to the tool, which means if your command launches multiple .NET applications, it will only collect the first app. Therefore, it is recommended you use this option on self-contained applications, or using the `dotnet exec <app.dll>` option.
+  > Using this option monitors the first .NET process that communicates back to the tool, which means if your command launches multiple .NET applications, it will only collect the first app. Therefore, it's recommended you use this option on self-contained applications, or using the `dotnet exec <app.dll>` option.
 
   > [!NOTE]
-  > Launching a .NET executable via dotnet-counters will redirect its input/output and you won't be able to interact with its stdin/stdout. Exiting the tool via CTRL+C or SIGTERM will safely end both the tool and the child process. If the child process exits before the tool, the tool will exit as well. If you need to use stdin/stdout, you can use the `--diagnostic-port` option. See [Using diagnostic port](#using-diagnostic-port) for more information.
+  > If you launch a .NET executable via `dotnet-counters`, its input/output will be redirected and you won't be able to interact with its stdin/stdout. You can exit the tool via <kbd>Ctrl+C</kbd> or SIGTERM to safely end both the tool and the child process. If the child process exits before the tool, the tool will exit as well. If you need to use stdin/stdout, you can use the `--diagnostic-port` option. For more information, see [Using diagnostic port](#using-diagnostic-port).
 
 > [!NOTE]
 > To collect metrics using `dotnet-counters`, it needs to be run as the same user as the user running target process or as root. Otherwise, the tool will fail to establish a connection with the target process.
@@ -180,17 +180,17 @@ dotnet-counters monitor [-h|--help] [-p|--process-id] [-n|--name] [--diagnostic-
 
 - **`--counters <COUNTERS>`**
 
-  A comma-separated list of counters. Counters can be specified `provider_name[:counter_name]`. If the `provider_name` is used without a qualifying list of counters, then all counters from the provider are shown. To discover provider and counter names, consult [built-in metrics docs](https://learn.microsoft.com/dotnet/core/diagnostics/built-in-metrics). For [EventCounters](event-counters.md), `provider_name` is the name of the EventSource and for [Meters](metrics.md), `provider_name` is the name of the Meter.
+  A comma-separated list of counters. Counters can be specified `provider_name[:counter_name]`. If the `provider_name` is used without a qualifying list of counters, then all counters from the provider are shown. To discover provider and counter names, see [built-in metrics](built-in-metrics.md). For [EventCounters](event-counters.md), `provider_name` is the name of the EventSource and for [Meters](metrics.md), `provider_name` is the name of the Meter.
 
  **`-- <command>`**
 
-  After the collection configuration parameters, the user can append `--` followed by a command to start a .NET application. `dotnet-counters` will launch a process with the provided command and monitor the requested metrics. This is often useful to collect metrics for the application's startup path and can be used to diagnose or monitor issues that happen early before or shortly after the main entrypoint.
+  After the collection configuration parameters, you can append `--` followed by a command to start a .NET application. `dotnet-counters` will launch a process with the provided command and monitor the requested metrics. This is often useful to collect metrics for the application's startup path and can be used to diagnose or monitor issues that happen early before or shortly after the main entry point.
 
   > [!NOTE]
-  > Using this option monitors the first .NET process that communicates back to the tool, which means if your command launches multiple .NET applications, it will only collect the first app. Therefore, it is recommended you use this option on self-contained applications, or using the `dotnet exec <app.dll>` option.
+  > Using this option monitors the first .NET process that communicates back to the tool, which means if your command launches multiple .NET applications, it will only collect the first app. Therefore, it's recommended you use this option on self-contained applications, or using the `dotnet exec <app.dll>` option.
 
   > [!NOTE]
-  > Launching a .NET executable via dotnet-counters will redirect its input/output and you won't be able to interact with its stdin/stdout. Exiting the tool via CTRL+C or SIGTERM will safely end both the tool and the child process. If the child process exits before the tool, the tool will exit as well. If you need to use stdin/stdout, you can use the `--diagnostic-port` option. See [Using diagnostic port](#using-diagnostic-port) for more information.
+  > Launching a .NET executable via `dotnet-counters` will redirect its input/output and you won't be able to interact with its stdin/stdout. You can exit the tool via <kbd>Ctrl+C</kbd> or SIGTERM to safely end both the tool and the child process. If the child process exits before the tool, the tool will exit as well. If you need to use stdin/stdout, you can use the `--diagnostic-port` option. For more information, see [Using diagnostic port](#using-diagnostic-port).
 
 > [!NOTE]
 > On Linux and macOS, this command expects the target application and `dotnet-counters` to share the same `TMPDIR` environment variable.
@@ -199,7 +199,7 @@ dotnet-counters monitor [-h|--help] [-p|--process-id] [-n|--name] [--diagnostic-
 > To monitor metrics using `dotnet-counters`, it needs to be run as the same user as the user running target process or as root.
 
 > [!NOTE]
-> If you see an error message similar to the following one: `[ERROR] System.ComponentModel.Win32Exception (299): A 32 bit processes cannot access modules of a 64 bit process.`, you are trying to use `dotnet-counters` that has mismatched bitness against the target process. Make sure to download the correct bitness of the tool in the [install](#install) link.
+> If you see an error message similar to the following one: `[ERROR] System.ComponentModel.Win32Exception (299): A 32 bit processes cannot access modules of a 64 bit process.`, you're trying to use `dotnet-counters` that has mismatched bitness against the target process. Make sure to download the correct bitness of the tool in the [install](#install) link.
 
 ### Examples
 
@@ -255,9 +255,9 @@ dotnet-counters monitor [-h|--help] [-p|--process-id] [-n|--name] [--diagnostic-
   ```
 
   > [!NOTE]
-  > If the app uses .NET version 8 or lower the [System.Runtime Meter](https://learn.microsoft.com/dotnet/core/diagnostics/built-in-metrics-runtime#systemruntime) didn't exist yet and dotnet-counters will fall back to display the older [System.Runtime EventCounters](https://learn.microsoft.com/dotnet/core/diagnostics/available-counters#systemruntime-counters) instead. The UI will look slightly different as shown below.
+  > If the app uses .NET version 8 or lower, the [System.Runtime Meter](built-in-metrics-runtime.md#systemruntime) doesn't exist in those versions and `dotnet-counters` will fall back to display the older [System.Runtime EventCounters](available-counters.md#systemruntime-counters) instead. The UI looks slightly different, as shown here.
 
-  ```
+  ```output
   [System.Runtime]
         % Time in GC since last GC (%)                                 0
         Allocation Rate (B / 1 sec)                                5,376
@@ -284,10 +284,10 @@ dotnet-counters monitor [-h|--help] [-p|--process-id] [-n|--name] [--diagnostic-
         Working Set (MB)                                              19
   ```
 
-- Monitor just GC collections and GC heap allocation from `System.Runtime`:
+- Monitor just garbage collections and garbage collection heap allocation from `System.Runtime`:
 
   ```dotnetcli
-  > dotnet-counters monitor --process-id 1902 --counters System.Runtime[dotnet.gc.collections,dotnet.gc.heap.total_allocated] 
+  > dotnet-counters monitor --process-id 1902 --counters System.Runtime[dotnet.gc.collections,dotnet.gc.heap.total_allocated]
 
   Press p to pause, r to resume, q to quit.
   Status: Running
@@ -324,7 +324,7 @@ dotnet-counters monitor [-h|--help] [-p|--process-id] [-n|--name] [--diagnostic-
   [System.Runtime]
   dotnet.assembly.count ({assembly})      11
   ```
-  
+
 - Launch `my-aspnet-server.exe` with `arg1` and `arg2` as command-line arguments and monitor its working set and GC heap size from its startup:
 
   ```dotnetcli
@@ -348,8 +348,8 @@ dotnet-counters monitor [-h|--help] [-p|--process-id] [-n|--name] [--diagnostic-
 
 ## dotnet-counters ps
 
- Lists the dotnet processes that can be monitored by `dotnet-counters`.
- `dotnet-counters` version 6.0.320703 and later, also display the command-line arguments that each process was started with, if available.
+Lists the dotnet processes that can be monitored by `dotnet-counters`.
+`dotnet-counters` version 6.0.320703 and later also displays the command-line arguments that each process was started with, if available.
 
 ### Synopsis
 
@@ -359,24 +359,24 @@ dotnet-counters ps [-h|--help]
 
 ### Example
 
-Suppose you start a long-running app using the command ```dotnet run --configuration Release```. In another window, you run the ```dotnet-counters ps``` command. The output you'll see is as follows. The command-line arguments, if any, are shown in `dotnet-counters` version 6.0.320703 and later.
+Suppose you start a long-running app using the command ```dotnet run --configuration Release```. In another window, you run the ```dotnet-counters ps``` command. The output you see is as follows. The command-line arguments, if any, are shown in `dotnet-counters` version 6.0.320703 and later.
 
 ```dotnetcli
 > dotnet-counters ps
-  
+
   21932 dotnet     C:\Program Files\dotnet\dotnet.exe   run --configuration Release
   36656 dotnet     C:\Program Files\dotnet\dotnet.exe
 ```
 
 ## Using diagnostic port
 
-[Diagnostic port](./diagnostic-port.md) is a runtime feature that allows you to start monitoring or collecting counters from app startup. To do this using `dotnet-counters`, you can either use `dotnet-counters <collect|monitor> -- <command>` as described in the examples above, or use the `--diagnostic-port` option.
+[Diagnostic port](./diagnostic-port.md) is a runtime feature that allows you to start monitoring or collecting counters from app startup. To do this using `dotnet-counters`, you can either use `dotnet-counters <collect|monitor> -- <command>` as described in the previous examples, or use the `--diagnostic-port` option.
 
 Using `dotnet-counters <collect|monitor> -- <command>` to launch the application as a child process is the simplest way to quickly monitor it from its startup.
 
 However, when you want to gain a finer control over the lifetime of the app being monitored (for example, monitor the app for the first 10 minutes only and continue executing) or if you need to interact with the app using the CLI, using `--diagnostic-port` option allows you to control both the target app being monitored and `dotnet-counters`.
 
-1. The command below makes dotnet-counters create a diagnostics socket named `myport.sock` and wait for a connection.
+1. The following command makes `dotnet-counters` create a diagnostics socket named `myport.sock` and wait for a connection.
 
     > ```dotnetcli
     > dotnet-counters collect --diagnostic-port myport.sock
@@ -396,7 +396,7 @@ However, when you want to gain a finer control over the lifetime of the app bein
     > ./my-dotnet-app arg1 arg2
     > ```
 
-    This should then enable `dotnet-counters` to start collecting counters on `my-dotnet-app`:
+    This enables `dotnet-counters` to start collecting counters on `my-dotnet-app`:
 
     > ```output
     > Waiting for connection on myport.sock
@@ -405,4 +405,4 @@ However, when you want to gain a finer control over the lifetime of the app bein
     > ```
 
     > [!IMPORTANT]
-    > Launching your app with `dotnet run` can be problematic because the dotnet CLI may spawn many child processes that are not your app and they can connect to `dotnet-counters` before your app, leaving your app to be suspended at run time. It is recommended you directly use a self-contained version of the app or use `dotnet exec` to launch the application.
+    > Launching your app with `dotnet run` can be problematic because the dotnet CLI might spawn many child processes that aren't your app and they can connect to `dotnet-counters` before your app, leaving your app to be suspended at run time. It's recommended you directly use a self-contained version of the app or use `dotnet exec` to launch the application.