Address EventPipe documentation feedback

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot-Session: a5765868-3160-4052-b7cd-86df02acb53b

Author: mdh1418

docs/core/diagnostics/dotnet-gcdump.md

@@ -1,7 +1,7 @@
 ---
 title: dotnet-gcdump diagnostic tool - .NET CLI
 description: Learn how to install and use dotnet-gcdump CLI tool to collect GC (Garbage Collector) dumps of live .NET processes using the .NET EventPipe.
-ms.date: 07/09/2026
+ms.date: 08/24/2026
 ms.topic: reference
 ai-usage: ai-assisted
 ---
@@ -47,9 +47,6 @@ The `dotnet-gcdump` global tool collects GC (Garbage Collector) dumps of live .N
 - Analyzing roots of objects (answering questions like, "what still has a reference to this type?").
 - Collecting general statistics about the counts of objects on the heap.
 
-> [!NOTE]
-> `dotnet-gcdump` collects with non-lossy buffering so the GC dump is complete on large heaps. Non-lossy buffering requires a .NET 11+ target runtime; on older runtimes, the tool automatically falls back to lossy buffering. Non-lossy buffering is complete only up to the runtime's buffer capacity, not against host memory exhaustion. Under memory pressure, the runtime can still drop events.
-
 ### View the GC dump captured from dotnet-gcdump
 
 On Windows, `.gcdump` files can be viewed in [PerfView](https://github.com/microsoft/perfview) for analysis or in Visual Studio. Currently, there is no way of opening a `.gcdump` on non-Windows platforms.
@@ -257,7 +254,7 @@ dotnet-gcdump report [-h|--help] [-p|--process-id <pid>] [-t|--report-type <Heap
 
 - `dotnet-gcdump` is unable to generate a `.gcdump` file due to missing information, for example, **[Error] Exception during gcdump: System.ApplicationException: ETL file shows the start of a heap dump but not its completion.**. Or, the `.gcdump` file doesn't include the entire heap.
 
-   `dotnet-gcdump` works by collecting a trace of events emitted by the garbage collector during an induced generation 2 collection. If the heap is sufficiently large, or there isn't enough memory to scale the eventing buffers, then the events required to reconstruct the heap graph from the trace might be dropped. On a .NET 11+ target runtime, `dotnet-gcdump`'s non-lossy buffering prevents this by blocking event producers instead of dropping events, up to the buffer's capacity. On older runtimes, where the tool falls back to the lossy buffer, or as an alternative, collect a dump of the process to diagnose issues with the heap.
+   `dotnet-gcdump` works by collecting a trace of events emitted by the garbage collector during an induced generation 2 collection. Prior to .NET 11, if the heap is sufficiently large, or there isn't enough memory to scale the eventing buffers, then the events required to reconstruct the heap graph from the trace may be dropped. In this case, to diagnose issues with the heap, it's recommended to collect a dump of the process.
 
 - `dotnet-gcdump` appears to cause an Out Of Memory issue in a memory constrained environment.
 

docs/core/diagnostics/dotnet-trace.md

@@ -1,7 +1,7 @@
 ---
 title: dotnet-trace diagnostic tool - .NET CLI
 description: Learn how to install and use the dotnet-trace CLI tool to collect .NET traces of a running process without the native profiler, by using the .NET EventPipe.
-ms.date: 08/21/2026
+ms.date: 08/24/2026
 ms.topic: reference
 ms.custom: sfi-ropc-nochange
 ai-usage: ai-assisted
@@ -112,10 +112,10 @@ dotnet-trace collect
 
 - **`--buffering-mode <Drop|Block>`**
 
-  Sets how the runtime buffers events. Accepts `0`/`Drop` or `1`/`Block` (case-insensitive), and defaults to `Drop`.
+  Sets how the runtime buffers events. Accepts `Drop` or `Block` (case-insensitive), and defaults to `Drop`.
 
-  - `0` / `Drop` (default): the lossy circular buffer. Events are dropped when the buffer overflows.
-  - `1` / `Block`: non-lossy tracing. The runtime blocks the threads emitting events when the buffer is full instead of dropping events, which produces a complete trace. It's non-lossy only up to the buffer's capacity, not against host memory exhaustion. Under memory pressure, events can still be dropped. `Block` requires a .NET 11+ target runtime and can make the traced application slower because event-emitting threads pause while the buffer stays full. On older runtimes, starting the trace fails; retry with `Drop` (the default).
+  - `Drop` (default): Events are dropped when the buffer overflows.
+  - `Block`: Threads emitting events wait until there is room in the buffer to store them. Events may still be dropped under uncommon error conditions such as memory exhaustion. `Block` requires a .NET 11+ target runtime and can make the traced application slower because event-emitting threads pause while the buffer stays full.
 
 - **`--buffersize <size>`**
 

docs/core/diagnostics/eventpipe.md

@@ -1,7 +1,7 @@
 ---
 title: EventPipe Overview
 description: Learn about EventPipe and how to use it for tracing your .NET applications to diagnose performance issues.
-ms.date: 07/09/2026
+ms.date: 08/24/2026
 ms.topic: overview
 ai-usage: ai-assisted
 ---
@@ -81,13 +81,11 @@ However, you can use the following environment variables to set up an EventPipe
 * `DOTNET_EventPipeCircularMB`: A hexadecimal value that represents the size of EventPipe's internal buffer in megabytes. This configuration value is only used when EventPipe is configured to run via `DOTNET_EnableEventPipe`. The default buffer size is 1024MB which translates to this environment variable being set to `400`, since `0x400` == `1024`.
 
   > [!NOTE]
-  > If the target process writes events too frequently, it can overflow this buffer and some events might be dropped. If too many events are getting dropped, increase the buffer size to see if the number of dropped events reduces. If the number of dropped events does not decrease with a larger buffer size, it may be due to a slow reader preventing the target process' buffers from being flushed.
-  >
-  > As of .NET 11, a streaming session can opt into non-lossy buffering with `DOTNET_EventPipeBufferingMode=1` (or `--buffering-mode Block` in [dotnet-trace](./dotnet-trace.md)) to block the threads emitting events when the buffer is full instead of dropping them. Non-lossy buffering trades application throughput for completeness. It's non-lossy only up to the buffer's capacity, not against host memory exhaustion. Under memory pressure, the runtime can still drop events.
+  > If the target process writes events too frequently, it can overflow this buffer, and some events might be dropped. If the runtime drops too many events, set `DOTNET_EventPipeBufferingMode=1` or increase the buffer size to see if the number of dropped events decreases. If the number of dropped events does not decrease with a larger buffer size, a slow reader might prevent the target process's buffers from being flushed.
 
-* `DOTNET_EventPipeBufferingMode`: Available in .NET 11 and later. Controls how the startup EventPipe session's buffer behaves when it fills faster than it's drained. Set it to `0` (default) for the lossy circular buffer that drops events on overflow, or `1` for non-lossy (Block) buffering, which pauses the threads that emit events when the buffer is full instead of dropping them. Only `0` and `1` are valid, and `1` requires a streaming session (see `DOTNET_EventPipeOutputStreaming`); any other value, or `1` for a non-streaming file session, starts no session.
+* `DOTNET_EventPipeBufferingMode`: Available in .NET 11 and later. This setting controls how the startup EventPipe session handles recording an event when the in-memory buffer is full. Set it to `0` (default) to drop events that would overflow the buffer, or `1` to pause event-writing threads until buffer space becomes available. `1` requires a streaming session (see `DOTNET_EventPipeOutputStreaming`).
 
-* `DOTNET_EventPipeOutputStreaming`: Set this to `1` to stream the startup EventPipe session's events continuously instead of buffering them and writing at process exit. A streaming session is required for `DOTNET_EventPipeBufferingMode=1` (non-lossy) to take effect.
+* `DOTNET_EventPipeOutputStreaming`: Set this to `1` to stream the startup EventPipe session's events to disk as quickly as possible after they occur. By default, events are stored in memory and not written to disk until the application is exiting. A streaming session is required for `DOTNET_EventPipeBufferingMode=1` to take effect.
 
 * `DOTNET_EventPipeProcNumbers`: Set this to `1` to enable capturing processor numbers in EventPipe event headers. The default value is `0`.
 

docs/core/diagnostics/microsoft-diagnostics-netcore-client.md

@@ -1,7 +1,7 @@
 ---
 title: Microsoft.Diagnostics.NETCore.Client API
 description: In this article, you'll learn about the Microsoft.Diagnostics.NETCore.Client APIs.
-ms.date: 07/09/2026
+ms.date: 08/24/2026
 author: tommcdon
 ms.author: tommcdon
 ms.topic: reference
@@ -374,7 +374,7 @@ Represents the configuration for an `EventPipeSession`.
 * `rundownKeyword` : The keyword mask used for rundown events.
 * `bufferingMode` : The [`EventPipeBufferingMode`](#eventpipebufferingmode-enum) for the session. Use `Block` to request non-lossy collection. Passing `Block` requires a .NET 11+ target runtime; on an older runtime, `StartEventPipeSession` throws [`UnsupportedCommandException`](#unsupportedcommandexception).
 
-The `BufferingMode` property returns the buffering mode for the session. The default value, `Drop`, keeps the runtime's lossy circular buffer.
+The `BufferingMode` property returns the buffering mode for the session. The default value, `Drop`, keeps the runtime's lossy buffer.
 
 ## EventPipeProvider class
 
@@ -671,7 +671,7 @@ public enum EventPipeBufferingMode
 
 Controls how the runtime's per-session event buffer behaves when it fills faster than the session drains it.
 
-* `Drop` : The runtime default. The session uses a circular buffer that drops events when it overflows, so collection is lossy.
+* `Drop` : The runtime default. The session uses a buffer that drops events when it overflows, so collection is lossy.
 * `Block` : Non-lossy collection. The runtime blocks event producers when the buffer is full instead of dropping events. Use it for collections that must be complete, such as a heap snapshot on a large heap. `Block` is non-lossy only up to the buffer's capacity, not against host memory exhaustion: if the runtime can't allocate the memory it needs to reserve buffer space, or during session shutdown, it drops the event instead of blocking. `Block` requires a .NET 11+ target runtime; on an older runtime, starting the session throws [`UnsupportedCommandException`](#unsupportedcommandexception).
 
 ## Exceptions