Merge pull request #2352 from iRaindrop/vbruham_debugger_d

Visual Studio Debugger CATS QA: M - end

Author: TrishaMc

docs/debugger/macros-for-reporting.md

@@ -26,16 +26,16 @@ ms.workload:
   - "multiple"
 ---
 # Macros for Reporting
-You can use the **_RPTn**, and **_RPTFn** macros, defined in CRTDBG.H, to replace the use of `printf` statements for debugging. These macros automatically disappear in your release build when **_DEBUG** is not defined, so there is no need to enclose them in **#ifdef**s.  
+For debugging, you can use the **_RPTn** and **_RPTFn** macros, defined in CRTDBG.H, to replace the use of `printf` statements. You don't need to inclose them in **#ifdef**s, because they automatically disappear in your release build when **_DEBUG** isn't defined.  
 
 |Macro|Description|  
 |-----------|-----------------|  
 |**_RPT0**, **_RPT1**, **_RPT2**, **_RPT3**, **_RPT4**|Outputs a message string and zero to four arguments. For _RPT1 through **_RPT4**, the message string serves as a printf-style formatting string for the arguments.|  
-|**_RPTF0**, **_RPTF1**, **,_RPTF2**, **_RPTF4**|Same as **_RPTn**, but these macros also output the file name and line number where the macro is located.|  
+|**_RPTF0**, **_RPTF1**, **_RPTF2**, **_RPTF4**|Same as **_RPTn**, but these macros also output the file name and line number where the macro is located.|  
 
  Consider the following example:  
 
-```  
+```cpp
 #ifdef _DEBUG  
     if ( someVar > MAX_SOMEVAR )  
         printf( "OVERFLOW! In NameOfThisFunc( ),  
@@ -46,13 +46,13 @@ You can use the **_RPTn**, and **_RPTFn** macros, defined in CRTDBG.H, to replac
 
  This code outputs the values of `someVar` and `otherVar` to **stdout**. You can use the following call to `_RPTF2` to report these same values and, additionally, the file name and line number:  
 
-```  
+```cpp
 if (someVar > MAX_SOMEVAR) _RPTF2(_CRT_WARN, "In NameOfThisFunc( ), someVar= %d, otherVar= %d\n", someVar, otherVar );  
 ```  
 
- If you find that a particular application needs debug reporting that the macros supplied with the C run-time library do not provide, you can write a macro designed specifically to fit your own requirements. In one of your header files, for example, you could include code like the following to define a macro called **ALERT_IF2**:  
+You might find that a particular application needs debug reporting that the macros supplied with the C run-time library do not provide. For these cases, you can write a macro designed specifically to fit your own requirements. In one of your header files, for example, you could include code like the following to define a macro called **ALERT_IF2**:  
 
-```  
+```cpp
 #ifndef _DEBUG                  /* For RELEASE builds */  
 #define  ALERT_IF2(expr, msg, arg1, arg2)  do {} while (0)  
 #else                           /* For DEBUG builds   */  
@@ -66,14 +66,14 @@ if (someVar > MAX_SOMEVAR) _RPTF2(_CRT_WARN, "In NameOfThisFunc( ), someVar= %d,
 #endif  
 ```  
 
- One call to **ALERT_IF2** could perform all the functions of the **printf** code at the start of this topic:  
+ One call to **ALERT_IF2** could do all the functions of the **printf** code:  
 
-```  
+```cpp
 ALERT_IF2(someVar > MAX_SOMEVAR, "OVERFLOW! In NameOfThisFunc( ),   
 someVar=%d, otherVar=%d.\n", someVar, otherVar );  
 ```  
   
- Because a custom macro can easily be changed to report more or less information to different destinations (depending on what is more convenient), this approach can be particularly useful as your debugging requirements evolve.  
+ You can easily change a custom macro to report more or less information to different destinations. This approach is particularly useful as your debugging requirements evolve.  
   
 ## See Also  
- [CRT Debugging Techniques](../debugger/crt-debugging-techniques.md)
+ [CRT Debugging Techniques](../debugger/crt-debugging-techniques.md)

docs/debugger/managing-exceptions-with-the-debugger.md

@@ -87,7 +87,7 @@ If you select an exception in the **Exception Settings** window, debugger execut
 
      If you have **AccessViolationException** checked in **Exception Settings**, when you run this code in the debugger execution will break on the `throw` line. You can then continue execution. The console should display both lines:  
 
-    ```  
+    ```cmd
     caught exception  
     goodbye  
     ```  
@@ -191,4 +191,4 @@ To add conditional exceptions, choose the **Edit condition** icon in the Excepti
  [How to: Examine System Code After an Exception](../debugger/how-to-examine-system-code-after-an-exception.md)   
  [How to: Use Native Run-Time Checks](../debugger/how-to-use-native-run-time-checks.md)   
  [Using Run-Time Checks Without the C Run-Time Library](../debugger/using-run-time-checks-without-the-c-run-time-library.md)   
- [Debugger Basics](../debugger/debugger-basics.md)
+ [Debugger Basics](../debugger/debugger-basics.md)

docs/debugger/mfc-debugging-techniques.md

@@ -59,14 +59,14 @@ If you are debugging an MFC program, these debugging techniques may be useful.
 ##  <a name="BKMK_AfxDebugBreak"></a> AfxDebugBreak  
  MFC provides a special [AfxDebugBreak](/cpp/mfc/reference/diagnostic-services#afxdebugbreak) function for hard-coding breakpoints in source code:  
 
-```  
+```cpp
 AfxDebugBreak( );  
 
 ```  
   
  On Intel platforms, `AfxDebugBreak` produces the following code, which breaks in source code rather than kernel code:  
   
-```  
+```cpp
 _asm int 3  
 ```  
 
@@ -81,7 +81,7 @@ _asm int 3
 
  The following examples show some of the ways you can use the **TRACE** macro. Like `printf`, the **TRACE** macro can handle a number of arguments.  
 
-```  
+```cpp
 int x = 1;  
 int y = 16;  
 float z = 32.0;  
@@ -96,7 +96,7 @@ TRACE( "x = %d and y = %x and z = %f\n", x, y, z );
   
  The TRACE macro appropriately handles both char* and wchar_t\* parameters. The following examples demonstrate the use of the TRACE macro together with different types of string parameters.  
   
-```  
+```cpp
 TRACE( "This is a test of the TRACE macro that uses an ANSI string: %s %d\n", "The number is:", 2);  
   
 TRACE( L"This is a test of the TRACE macro that uses a UNICODE string: %s %d\n", L"The number is:", 2);  
@@ -117,7 +117,7 @@ TRACE( _T("This is a test of the TRACE macro that uses a TCHAR string: %s %d\n")
 
  If you do not want to rewrite your entire program to use `DEBUG_NEW` in place of **new**, you can define this macro in your source files:  
 
-```  
+```cpp
 #define new DEBUG_NEW  
 ```  
   
@@ -162,7 +162,7 @@ TRACE( _T("This is a test of the TRACE macro that uses a TCHAR string: %s %d\n")
   
      This example shows what the code looks like:  
   
-    ```  
+    ```cpp
     // Declare the variables needed  
     #ifdef _DEBUG  
         CMemoryState oldMemState, newMemState, diffMemState;  
@@ -194,7 +194,7 @@ TRACE( _T("This is a test of the TRACE macro that uses a TCHAR string: %s %d\n")
   
  Consider the following example:  
   
-```  
+```cpp  
 if( diffMemState.Difference( oldMemState, newMemState ) )  
 {  
    TRACE( "Memory leaked!\n" );  
@@ -204,7 +204,7 @@ if( diffMemState.Difference( oldMemState, newMemState ) )
 
  A sample dump from the example looks like this:  
 
-```  
+```cpp
 0 bytes in 0 Free Blocks  
 22 bytes in 1 Object Blocks  
 45 bytes in 4 Non-Object Blocks  
@@ -235,7 +235,7 @@ Total allocations: 67 bytes
   
  The following code tests for a memory leak by comparing two memory states and dumps all objects if a leak is detected.  
 
-```  
+```cpp
 if( diffMemState.Difference( oldMemState, newMemState ) )  
 {  
    TRACE( "Memory leaked!\n" );  
@@ -245,7 +245,7 @@ if( diffMemState.Difference( oldMemState, newMemState ) )
 
  The contents of the dump look like this:  
 
-```  
+```cmd
 Dumping objects ->  
   
 {5} strcore.cpp(80) : non-object block at $00A7521A, 9 bytes long  
@@ -273,7 +273,7 @@ Phone #: 581-0215
 ####  <a name="BKMK_Interpreting_memory_dumps"></a> Interpreting memory dumps  
  Look at this object dump in more detail:  
 
-```  
+```cmd
 {5} strcore.cpp(80) : non-object block at $00A7521A, 9 bytes long  
 {4} strcore.cpp(80) : non-object block at $00A751F8, 5 bytes long  
 {3} strcore.cpp(80) : non-object block at $00A751D6, 6 bytes long  
@@ -288,7 +288,7 @@ Phone #: 581-0215
 
  The program that generated this dump had only two explicit allocations—one on the stack and one on the heap:  
 
-```  
+```cpp
 // Do your memory allocations and deallocations.  
 CString s("This is a frame variable");  
 // The next object is a heap object.  
@@ -305,7 +305,7 @@ CPerson* p = new CPerson( "Smith", "Alan", "581-0215" );
   
  In general, you should not worry about heap objects associated with frame variables because they are automatically deallocated when the frame variables go out of scope. To avoid clutter in your memory diagnostic dumps, you should position your calls to `Checkpoint` so that they are outside the scope of frame variables. For example, place scope brackets around the previous allocation code, as shown here:  
   
-```  
+```cpp
 oldMemState.Checkpoint();  
 {  
     // Do your memory allocations and deallocations ...  
@@ -318,7 +318,7 @@ newMemState.Checkpoint();
 
  With the scope brackets in place, the memory dump for this example is as follows:  
 
-```  
+```cmd 
 Dumping objects ->  
   
 {5} strcore.cpp(80) : non-object block at $00A7521A, 9 bytes long  
@@ -341,7 +341,7 @@ Phone #: 581-0215
 
  For objects allocated on the heap, however, you must explicitly delete the object to prevent a memory leak. To clean up the last memory leak in the previous example, delete the `CPerson` object allocated on the heap, as follows:  
 
-```  
+```cpp  
 {  
     // Do your memory allocations and deallocations.  
     CString s("This is a frame variable");  
@@ -362,7 +362,7 @@ Phone #: 581-0215
 
  The declaration of the `Dump` function looks like this:  
 
-```  
+```cpp  
 class CPerson : public CObject  
 {  
 public:  
@@ -380,7 +380,7 @@ public:
 
  In the following example, the `Dump` function first calls the `Dump` function for its base class. It then writes a short description of each member variable along with the member's value to the diagnostic stream.  
 
-```  
+```cpp  
 #ifdef _DEBUG  
 void CPerson::Dump( CDumpContext& dc ) const  
 {  
@@ -396,7 +396,7 @@ void CPerson::Dump( CDumpContext& dc ) const
 
  You must supply a `CDumpContext` argument to specify where the dump output will go. The Debug version of MFC supplies a predefined `CDumpContext` object named `afxDump` that sends output to the debugger.  
 
-```  
+```cpp 
 CPerson* pMyPerson = new CPerson;  
 // Set some fields of the CPerson object.  
 //...  

docs/debugger/pseudovariables.md

@@ -26,9 +26,7 @@ Pseudovariables are terms used to display certain information in a variable wind
 ## Example  
  Suppose you are writing a native code application and want to see the number of handles allocated in your application. In the **Watch** window, you can enter the following pseudovariable in the **Name** column, then press Return to evaluate it:  
 
-```  
-$handles  
-```  
+`$handles`
 
  In native code, you can use the pseudovariables shown in this table:  
 

docs/debugger/remote-debugger-port-assignments.md

@@ -46,9 +46,8 @@ The Visual Studio Remote Debugger can run as an application or as a background s
 ## Remote Debugger Ports on Azure  
  The following ports are used by the remote debugger on Azure. The ports on the cloud service are mapped to the ports on the individual VM. All ports are TCP.  
 
-||||  
+|Connection|Port on Cloud Service|Port on VM|
 |-|-|-|  
-|**Connection**|**Port on Cloud Service**|**Port on VM**|  
 |Microsoft.WindowsAzure.Plugins.RemoteDebugger.Connector|30400|30398|  
 |Microsoft.WindowsAzure.Plugins.RemoteDebugger.Forwarder|31400|31398|  
 |Microsoft.WindowsAzure.Plugins.RemoteDebugger.FileUpload|32400|32398|  

docs/debugger/remote-debugging-aspnet-on-a-remote-iis-7-5-computer.md

@@ -209,7 +209,7 @@ For information on running the remote debugger as a service, see [Run the remote
 In most setups, required ports are opened by the installation of ASP.NET and the remote debugger. However, you may need to verify that ports are open.
 
 > [!NOTE]
-> On an Azure VM, you must open ports through the [Network security group](/azure/virtual-machines/virtual-machines-windows-hero-role#open-port-80). 
+> On an Azure VM, you must open ports through the [Network security group](/azure/virtual-machines/virtual-machines-windows-hero-role#open-port-80-for-web-traffic). 
 
 Required ports:
 

docs/debugger/remote-debugging-aspnet-on-a-remote-iis-computer.md

@@ -193,7 +193,7 @@ For information on running the remote debugger as a service, see [Run the remote
 In most setups, required ports are opened by the installation of ASP.NET and the remote debugger. However, you may need to verify that ports are open.
 
 > [!NOTE]
-> On an Azure VM, you must open ports through the [Network security group](/azure/virtual-machines/virtual-machines-windows-hero-role#open-port-80). 
+> On an Azure VM, you must open ports through the [Network security group](/azure/virtual-machines/virtual-machines-windows-hero-role#open-port-80-for-web-traffic).
 
 Required ports:
 

docs/debugger/remote-debugging-azure.md

@@ -57,7 +57,7 @@ Debugging between two computers connected through a proxy is not supported. Debu
 
 ## <a name="remote_debug_azure_app_service"></a> Remote Debug ASP.NET Core on an Azure App Service
 
-From Visual Studio, you can quickly publish and debug your app to a fully provisioned instance of IIS. However, the configuration of IIS is preset and you cannot customize it. For more detailed instructions, see [Deploy an ASP.NET Core web app to Azure using Visual Studio](/aspnet/core/tutorials/publish-to-azure-webapp-using-vs). (If you need the ability to customize IIS, try debugging on an [Azure VM](#BKMK_azure_vm).) 
+From Visual Studio, you can quickly publish and debug your app to a fully provisioned instance of IIS. However, the configuration of IIS is preset and you cannot customize it. For more detailed instructions, see [Deploy an ASP.NET Core web app to Azure using Visual Studio](/aspnet/core/tutorials/publish-to-azure-webapp-using-vs). (If you need the ability to customize IIS, try debugging on an [Azure VM](#remote_debug_azure_vm).) 
 
 #### To deploy the app and remote debug using Server Explorer
 
@@ -227,7 +227,7 @@ If you have trouble opening the page with the remote debugger download, see [Unb
 
 In most setups, required ports are opened by the installation of ASP.NET and the remote debugger. However, if you are troubleshooting deployment issues and the app is hosted behind a firewall, you may need to verify that the correct ports are open.
 
-On an Azure VM, you must open ports through the [Network security group](/azure/virtual-machines/virtual-machines-windows-hero-role#open-port-80). 
+On an Azure VM, you must open ports through the [Network security group](/azure/virtual-machines/virtual-machines-windows-hero-role#open-port-80-for-web-traffic). 
 
 Required ports:
 

docs/debugger/remote-debugging-csharp.md

@@ -95,7 +95,7 @@ The debugger cannot deploy Visual C# or Visual Basic desktop applications to a r
 
 15. On the Visual Studio machine, you should see that execution has stopped at the breakpoint.
 
- If you have non-code files that need to be used by the application, you need to include them in the Visual Studio project. Create a project folder for the additional files (in the **Solution Explorer**, click **Add > New Folder**). Then add the files to the folder (in the **Solution Explorer**, click **Add > Existing Item**, then select the files). On the **Properties** page for each file, set **Copy to Output Directory** to **Copy always**.
+ If you have any non-code files that need to be used by the application, you need to include them in the Visual Studio project. Create a project folder for the additional files (in the **Solution Explorer**, click **Add > New Folder**). Then add the files to the folder (in the **Solution Explorer**, click **Add > Existing Item**, then select the files). On the **Properties** page for each file, set **Copy to Output Directory** to **Copy always**.
 
 ## Set Up Debugging with Remote Symbols 
 

docs/debugger/remote-debugging.md

@@ -95,7 +95,7 @@ You can find the remote debugger (*msvsmon.exe*) on a computer with Visual Studi
 
 2. Share the **Remote Debugger** folder on the Visual Studio computer.
 
-3. On the remote computer, run *msvsmon.exe*. Follow the [setup instructions](#bkmk_setup).
+3. On the remote computer, run *msvsmon.exe*. Follow the [Set up the remote debugger](#Requirements).
 
 > [!TIP]
 > For command line installation and command line reference, see the Help page for *msvsmon.exe* by typing ``msvsmon.exe /?`` in the command line on the computer with Visual Studio installed (or go to **Help > Usage** in the remote debugger).

docs/debugger/report-hook-functions.md

@@ -29,13 +29,13 @@ ms.workload:
 # Report Hook Functions
 A report hook function, installed using [_CrtSetReportHook](/cpp/c-runtime-library/reference/crtsetreporthook), is called every time [_CrtDbgReport](/cpp/c-runtime-library/reference/crtdbgreport-crtdbgreportw) generates a debug report. You can use it, among other things, for filtering reports to focus on specific types of allocations. A report hook function should have a prototype like the following:  
 
-```  
+```cpp
 int YourReportHook(int nRptType, char *szMsg, int *retVal);  
 ```  
   
  The pointer that you pass to **_CrtSetReportHook** is of type **_CRT_REPORT_HOOK**, as defined in CRTDBG.H:  
   
-```  
+```cpp
 typedef int (__cdecl *_CRT_REPORT_HOOK)(int, char *, int *);  
 ```  
 
@@ -45,4 +45,4 @@ typedef int (__cdecl *_CRT_REPORT_HOOK)(int, char *, int *);
 
 ## See Also  
  [Debug Hook Function Writing](../debugger/debug-hook-function-writing.md)   
- [crt_dbg2 Sample](http://msdn.microsoft.com/en-us/21e1346a-6a17-4f57-b275-c76813089167)
+ [crt_dbg2 Sample](http://msdn.microsoft.com/en-us/21e1346a-6a17-4f57-b275-c76813089167)

docs/debugger/stop-statements-in-visual-basic.md

@@ -33,7 +33,7 @@ The Visual Basic Stop statement provides a programmatic alternative to setting a
 
  To avoid the necessity of removing Stop statements, you can use conditional compilation:  
 
-```  
+```cpp
 #If DEBUG Then  
    Stop  
 #Else  
@@ -43,17 +43,17 @@ The Visual Basic Stop statement provides a programmatic alternative to setting a
 
  Another alternative is to use an Assert statement instead of the Stop statement. A Debug.Assert statement breaks execution only when a specified condition is not met and is automatically removed when you build a Release version. For more information, see [Assertions in Managed Code](../debugger/assertions-in-managed-code.md). If you want an Assert statement that always breaks execution in the Debug version, you can do this:  
 
-```  
+```csharp
 Debug.Assert(false)  
 ```  
 
  Yet another alternative is to use the Debug.Fail method:  
 
-```  
+```csharp
 Debug.Fail("a clever output string goes here")  
 ```  
 
 ## See Also  
  [Debugger Security](../debugger/debugger-security.md)   
  [C#, F#, and Visual Basic Project Types](../debugger/debugging-preparation-csharp-f-hash-and-visual-basic-project-types.md)   
- [Debugging Managed Code](../debugger/debugging-managed-code.md)
+ [Debugging Managed Code](../debugger/debugging-managed-code.md)

docs/debugger/unable-to-connect-to-the-microsoft-visual-studio-remote-debugging-monitor.md

@@ -78,7 +78,7 @@ Visual Studio could not connect to the remote debugger. This message may occur f
 - The remote debugger version does not match Visual Studio. To get the correct version of the remote debugger, see [Remote Debugging](../debugger/remote-debugging.md)
 
 
-## <a name="#valid_name"></a> The requested name was valid, but no data of the requested type was found
+## <a name="valid_name"></a> The requested name was valid, but no data of the requested type was found
 
 The remote computer exists, but Visual Studio could not connect to the remote debugger. This message may occur for several reasons: