Double check the changes

Author: v-phoebh

support/developer/webapps/iis/site-behavior-performance/data-capture-managed-memory-leak.md

@@ -14,7 +14,7 @@ This article outlines the steps to capture memory dumps associated with managed
 
 ## Memory leak issue is easily replicable
 
-If the memory leak issue can be consistently reproduced whenever needed, use one of the following methods to capture data:
+If the memory leak issue can be consistently reproduced whenever needed, use one of the following methods to capture data.
 
 ### Method 1: Using Procdump
 
@@ -35,15 +35,19 @@ If the memory leak issue can be consistently reproduced whenever needed, use one
 
 1. Download and install [Debug Diagnostic Tool v2 Update 3.2](https://www.microsoft.com/download/details.aspx?id=103453).
 1. When a memory leak occurs, open **DebugDiag 2 Collection** from the **Start** menu:  
+   
    :::image type="content" source="media/data-capture-managed-memory-leak/debugdiag-2-collection.png" alt-text="Screenshot of DebugDiag 2 Collection.":::
+
    > [!NOTE]
    > If you need to change the path where dumps are generated, select **Tools** > **Options And Settings** > **Manual Userdump Save Folder** to change it.
 1. Select the **Processes** tab.
 1. Locate the **w3wp** process with the **Process ID** column of the application in question.  
    [!INCLUDE [How to get actual PID](../../../../includes/how-get-pid.md)]
 1. Right-click the **w3wp** process, select **Create Userdump Series**, and set the following options (adjust the numbers as needed). Don't select **Save & Close**.  
+   
    :::image type="content" source="media/data-capture-managed-memory-leak/configure-userdump-series.png" alt-text="Screenshot of Configure UserDump Series.":::
-1. Once the memory consumption of **w3wp.exe** reaches the limit as described in the [Memory limit for different scenarios](high-memory-consumption-issues-overview.md#memory-limit-for-different-scenarios), select **Save & Close**.
+   
+1. Once the memory consumption of **w3wp.exe** reaches the limit as described in the [Memory limits for different scenarios](high-memory-consumption-issues-overview.md#memory-limits-for-different-scenarios), select **Save & Close**.
 
    The dumps will start generating immediately.
 

support/developer/webapps/iis/site-behavior-performance/high-memory-consumption-issues-overview.md

@@ -7,7 +7,7 @@ ms.reviewer: khgupta, v-sidong
 ---
 # Overview of high memory consumption issues
 
-This troubleshooting guide provides steps to diagnose and resolve high memory consumption issues in applications, focusing on scenarios involving memory leaks. It helps you understand typical symptoms, limits related to memory usage in different system configurations, and the tools required for effective diagnosis of the issue.
+This troubleshooting guide provides steps to diagnose and resolve high memory consumption issues in applications, focusing on scenarios involving memory leaks. It helps you understand typical symptoms, limits related to memory usage in different system configurations, and the tools required to diagnose the issue effectively.
 
 ## Data capture tools
 
@@ -21,12 +21,12 @@ This troubleshooting guide provides steps to diagnose and resolve high memory co
 > - Multiple attempts might be needed to get a useful set of memory dumps.
 > - Ensure you have sufficient disk space for memory dumps. Each dump is approximately the size of the process at that time. For instance, if the process is 1 gigabyte (GB), generating three dumps requires about 4 GB of space.
 
-## Memory limit for different scenarios
+## Memory limits for different scenarios
 
 Memory leaks generally result in a steady increase in memory usage, leading to crashes or performance degradation:
 
 > [!NOTE]
-> High memory usage doesn't always indicate a leak; processes might recover if the allocated memory is freed later. A memory leak is caused by a bug or bugs in the application, where allocations are never freed.
+> High memory usage doesn't always indicate a leak; processes might recover if the allocated memory is freed later. A memory leak is caused by one or more bugs in the application where allocations are never freed.
 
 - **32-bit applications**: 32-bit applications might crash and throw an `OutOfMemory` exception when running out of memory, possibly without reporting errors before crashing. They can behave unpredictably if memory allocation failures aren't handled properly in the application code.
 - **64-bit applications**: 64-bit applications rarely fail when trying to allocate virtual memory due to the large address space. However, they can grow to have a very large virtual address space and cause excessive paging of physical memory, which affects the application and other applications that are competing for physical memory.
@@ -35,7 +35,7 @@ Memory leaks generally result in a steady increase in memory usage, leading to c
 | --- | --- | --- |
 | 32-bit applications on 32-bit Windows | 4 GB in total (2 GB in [user mode](/windows-hardware/drivers/gettingstarted/user-mode-and-kernel-mode), 2 GB in [kernel mode](/windows-hardware/drivers/gettingstarted/user-mode-and-kernel-mode))|If you use the **/LARGEADDRESSAWARE** flag in your 32-bit applications and the **/3GB** switch in the **boot.ini** file of the operating system during boot time, it makes the user mode memory 3 GB and the kernel mode 1 GB. |
 | 32-bit applications on 64-bit Windows | 4 GB in total (2 GB in [user mode](/windows-hardware/drivers/gettingstarted/user-mode-and-kernel-mode), 2 GB in [kernel mode](/windows-hardware/drivers/gettingstarted/user-mode-and-kernel-mode)) |If you use the **/LARGEADDRESSAWARE** flag in your 32-bit applications, it makes the user mode memory 4 GB. The kernel doesn't use the 32-bit address space on a 64-bit operating system. It uses only the required space from the 64-bit address space. |
-| 64-bit applications on 64-bit Windows | The theoretical memory limit 16 exabytes (EB). However, the actual memory limit is determined by the operating system and hardware capabilities. The practical limit on 64-bit Windows 10 is 256 terabytes (TB) (128 TB in user mode, 128 TB in kernel mode) |NA|
+| 64-bit applications on 64-bit Windows | The theoretical memory limit is 16 exabytes (EB). However, the actual memory limit is determined by the operating system and hardware capabilities. The practical limit on 64-bit Windows 10 is 256 terabytes (TB) (128 TB in user mode, 128 TB in kernel mode). |NA|
 |64-bit applications on 32-bit Windows |Invalid scenario  |NA|
 
 ## Identify high memory usage
@@ -47,21 +47,21 @@ To monitor **Private Bytes (KB)**, follow these steps:
 1. Open **IIS Manager**.
 1. Select your server name (on the left).
 1. Double-click **Worker Processes**.
-1. Check **Private Bytes (KB)**. Here is a screenshot:
+1. Check **Private Bytes (KB)**. Here's a screenshot:
 
-   :::image type="content" source="media/data-capture-managed-memory-leak/worker-process.png" alt-text="Screenshot of Worker Processes.":::
+   :::image type="content" source="media/data-capture-managed-memory-leak/worker-process.png" alt-text="Screenshot of Worker Processes in which the Private Bytes (KB) column is highlighted.":::
 
-   If the value of **Private Bytes (KB)** for the **w3wp.exe** process (IIS worker process) reaches the memory limit as described in the [Memory limit for different scenarios](#memory-limit-for-different-scenarios), the **w3wp.exe** process has the high memory issue. **Process Id** and **Application Pool Name** are shown next to it. You might need to refresh this view manually.
+   If the **Private Bytes (KB)** value for the **w3wp.exe** process (IIS worker process) reaches the memory limit as described in the [Memory limits for different scenarios](#memory-limits-for-different-scenarios), the **w3wp.exe** process has a high memory issue. The **Process Id** and **Application Pool Name** are shown next to it. You might need to refresh this view manually.
 
-## Identify whether the memory leak is managed or native leak
+## Identify whether the memory leak is managed or native
 
-Once you've confirmed that the **w3wp.exe** process is experiencing high memory usage, the next step is to identify whether it's managed or native memory leak. Follow these steps to identify the type of memory leak:
+Once you've confirmed that the **w3wp.exe** process is experiencing high memory usage, the next step is to identify whether it's a managed or native memory leak. Follow these steps to identify the type of memory leak:
 
 1. Open **Performance Monitor** and select the **+** icon to add counters.
 
    :::image type="content" source="media/high-memory-consumption-issues-overview/performance-monitor.png" alt-text="Screenshot that highlights the plus icon in Performance Monitor." lightbox="media/high-memory-consumption-issues-overview/performance-monitor.png":::
 
-1. Select **# Bytes in all Heaps** under the **.NET CLR Memory** counter, select the target process (here it's **w3wp**), and then select **Add**.
+1. Select **# Bytes in all Heaps** under the **.NET CLR Memory** counter, select the target process (here, it's **w3wp**), and then select **Add**.
 1. Select **Private Bytes** and **Virtual Bytes** under the **Process** counter, select the target process, and then select **Add** (you can ignore the working set).
 
    :::image type="content" source="media/high-memory-consumption-issues-overview/add-counters-performance-monitor.png" alt-text="Screenshot of the Add Counters window.":::
@@ -82,18 +82,18 @@ Once you've confirmed that the **w3wp.exe** process is experiencing high memory
 
 Once you've confirmed the type of memory leak, the next step is to use tools to collect memory dumps of the process during the high memory usage event. These dumps can help you analyze and diagnose the cause of the issue.
 
-- To collect dumps for managed memory leak, see [Data capture for managed memory leaks](data-capture-managed-memory-leak.md).
-- To collect dumps for native memory leak, see [Troubleshoot native memory leak in an IIS 7.x application pool](troubleshoot-native-memory-leak-iis-7x-application-pool.md).
+- To collect dumps for managed memory leaks, see [Data capture for managed memory leaks](data-capture-managed-memory-leak.md).
+- To collect dumps for native memory leaks, see [Troubleshoot native memory leak in an IIS 7.x application pool](troubleshoot-native-memory-leak-iis-7x-application-pool.md).
 
 ## .NET Core applications
 
-If the application in question is .NET Core and hosted on IIS in in-process mode, use the steps for data collection in [Data capture for managed memory leaks](data-capture-managed-memory-leak.md) and [Troubleshoot native memory leak in an IIS 7.x application pool](troubleshoot-native-memory-leak-iis-7x-application-pool.md). However, if the application is hosted on IIS in out-of-process mode, modify the actions to investigate the dotnet process (**dotnet.exe** unless otherwise specified) instead of **w3wp.exe**. The same thing applies to self-hosted .NET Core applications.
+If the application in question is .NET Core and hosted on IIS in in-process mode, use the data collection steps in [Data capture for managed memory leaks](data-capture-managed-memory-leak.md) and [Troubleshoot native memory leak in an IIS 7.x application pool](troubleshoot-native-memory-leak-iis-7x-application-pool.md). However, if the application is hosted on IIS in out-of-process mode, modify the actions to investigate the dotnet process (**dotnet.exe** unless otherwise specified) instead of **w3wp.exe**. The same thing applies to self-hosted .NET Core applications.
 
 ## Troubleshooting example
 
 Assume you have an application hosted on an IIS server and you experience high memory usage (the memory spikes up to around 7 GB by doing a stress test) when accessing a specific URL, follow these steps to diagnose the issue:
 
-1. Check Performance Monitor by following the steps in [Identify whether the memory leak is managed or native leak](#identify-whether-the-memory-leak-is-managed-or-native-leak). If you notice **Private Bytes** and **# Bytes in all Heaps** remain constant, it's a managed memory leak.
+1. Check Performance Monitor by following the steps in [Identify whether the memory leak is managed or native](#identify-whether-the-memory-leak-is-managed-or-native). If you notice **Private Bytes** and **# Bytes in all Heaps** remain constant, it's a managed memory leak.
 1. Collect dump files by following the steps described in [Using DebugDiag](data-capture-managed-memory-leak.md#method-2-using-debugdiag).
 1. Open the dump files in [WinDbg](/windows-hardware/drivers/debugger/) and run the following commands based on your scenario.
 
@@ -333,7 +333,7 @@ Assume you have an application hosted on an IIS server and you experience high m
     16 00000027`987ffd30 00000000`00000000     ntdll!RtlUserThreadStart+0x28
     ```
 
-1. Check the following code snippet in the **Link.cs** file, and then you see that there is an explicit call to `Thread.Sleep`, which is causing high memory usage.
+1. Check the following code snippet in the **Link.cs** file, and you'll see that there's an explicit call to `Thread.Sleep`, which is causing high memory usage.
 
    ```C#
    // BuggyBits.Models.Link 
@@ -352,7 +352,7 @@ Assume you have an application hosted on an IIS server and you experience high m
    } 
    ```
 
-The above step-by-step approach can help you diagnose and address high memory usage issues.
+The preceding step-by-step approach can help you diagnose and address high memory usage issues.
 
 ## More information
 

support/includes/run-command-new-pid-procdump.md

@@ -1,3 +1,3 @@
-After the first memory dump is created, you see confirmation in **Command Prompt**. By default, the memory dump is saved in the same location as **procdump.exe**.
+After the first memory dump is created, you see a confirmation in **Command Prompt**. By default, the memory dump is saved in the same location as **procdump.exe**.
 
 If you're using other Procdump options that rely on specific conditions to trigger a dump, keep an eye on the PID. If it changes, you need to stop the command and run it again with the new PID. Otherwise, no memory dumps will be generated.