Merge pull request #6861 from v-kents/policheck-0714

update for policheck scan

Author: denrea

docs/cross-platform/troubleshooting-and-known-issues-visual-studio-tools-for-unity.md

@@ -44,9 +44,9 @@ This should fix your issue. In case you are still experiencing the problem, run
  devenv /setup
 ```
 
-## Visual Studio hangs
+## Visual Studio stops responding
 
-Several Unity plugins like Parse, FMOD, UMP (Universal Media Player), ZFBrowser, or Embedded Browser are using native threads. It’s an issue when a plugin ends up attaching a native thread to the runtime, which then does blocking calls to the OS. This means Unity can't interrupt that thread for the debugger (or domain reload) and hang.
+Several Unity plugins like Parse, FMOD, UMP (Universal Media Player), ZFBrowser, or Embedded Browser are using native threads. It’s an issue when a plugin ends up attaching a native thread to the runtime, which then does blocking calls to the OS. This means Unity can't interrupt that thread for the debugger (or domain reload) and stop responding.
 
 For FMOD, there is a workaround, you can pass `FMOD_STUDIO_INIT_SYNCHRONOUS_UPDATE` initialization [flag](https://www.fmod.com/resources/documentation-studio?version=2.0&page=https://fmod.com/resources/documentation-api?version=2.0&page=studio-api-system.html#fmod_studio_initflags) to disable asynchronous processing and perform all processing on the main thread.
 

docs/cross-platform/troubleshooting-the-visual-studio-emulator-for-android.md

@@ -39,7 +39,7 @@ This topic contains information to help you resolve issues that you may experien
 
 - [Visual Studio gets stuck trying to deploy the app to the emulator or the emulator does not appear as a debug target in other IDEs](#ADB)
 
-- [Emulator hangs because it couldn't set up the UDP port](#XamarinPlayer)
+- [Emulator stops responding because it couldn't set up the UDP port](#XamarinPlayer)
 
 - [Cannot attach debugger to a Xamarin project](#Skylake)
 
@@ -263,8 +263,8 @@ This topic contains information to help you resolve issues that you may experien
 
   Restart the emulator and you should now be able to see the emulator connected to ADB and associated Android tools.
 
-## <a name="XamarinPlayer"></a> Emulator hangs because it couldn't set up the UDP port
- You may experience this issue due to incompatibility with Xamarin Player. If the emulator appears to hang or if you see this error message, "The emulator is unable to connect to the device operating system: Couldn't set up the UDP port.  Some functionality might be disabled", you may be experiencing this issue. Take the following steps.
+## <a name="XamarinPlayer"></a> Emulator stops responding because it couldn't set up the UDP port
+ You may experience this issue due to incompatibility with Xamarin Player. If the emulator appears to stop responding or if you see this error message, "The emulator is unable to connect to the device operating system: Couldn't set up the UDP port.  Some functionality might be disabled", you may be experiencing this issue. Take the following steps.
 
 1. Uninstall Xamarin Player.
 

docs/debugger/debug-64-bit-applications.md

@@ -44,7 +44,7 @@ You can debug a 64-bit application that is running on the local computer or on a
 
 - You have networking security software installed on your computer that has caused the networking stack to be unreliable, and it has dropped packets going over localhost. Try disabling all network security software and see if this resolves it. If so, report to your network security software vendor that the software is interfering with localhost traffic.
 
-- You are running into a hang or performance problem with Visual Studio. If the problem happens regularly, you can collect dumps of Visual Studio (devenv.exe) and the worker process (msvsmon.exe) and send them to Microsoft. For information about reporting a problem, see [How to Report a Problem with Visual Studio](../ide/how-to-report-a-problem-with-visual-studio.md).
+- You are running into an issue where Visual Studio becomes unresponsive, or other performance problem. If the problem happens regularly, you can collect dumps of Visual Studio (devenv.exe) and the worker process (msvsmon.exe) and send them to Microsoft. For information about reporting a problem, see [How to Report a Problem with Visual Studio](../ide/how-to-report-a-problem-with-visual-studio.md).
 
 ## See also
 

docs/debugger/error-evaluating-the-function-function-timed-out-and-needed-to-be-aborted-in-an-unsafe-way.md

@@ -14,7 +14,7 @@ ms.workload:
 
 Full message text: Evaluating the function 'function' timed out and needed to be aborted in an unsafe way. This may have corrupted the target process.
 
-To make it easier to inspect the state of .NET objects, the debugger will automatically force the debugged process to run additional code (typically property getter methods and ToString functions). In most all scenarios, these functions complete quickly and make debugging much easier. However, the debugger doesn't run the application in a sandbox. As a result, a property getter or ToString method that calls into a native function that hangs can lead to long timeouts that may not be recoverable. If you encounter this error message, this has occurred.
+To make it easier to inspect the state of .NET objects, the debugger will automatically force the debugged process to run additional code (typically property getter methods and ToString functions). In most all scenarios, these functions complete quickly and make debugging much easier. However, the debugger doesn't run the application in a sandbox. As a result, a property getter or ToString method that calls into a native function that stops responding can lead to long timeouts that may not be recoverable. If you encounter this error message, this has occurred.
 
 One common reason for this problem is that when the debugger evaluates a property, it only allows the thread being inspected to execute. So if the property is waiting on other threads to run inside the debugged application, and if it is waiting in a way that the .NET Runtime isn't able to interrupt, this problem will happen.
 

docs/debugger/just-in-time-debugging-in-visual-studio.md

@@ -37,4 +37,4 @@ If you don't have Visual Studio installed, you can prevent Just-In-Time debuggin
 
 After you disable Just-In-Time debugging, the app may be able to handle the error and run normally.
 
-If the app still has an unhandled error, you may see an error message, or the app may crash or hang. The app won't run normally until the error is fixed. You can try to contact the owner of the app and ask them to fix it.
+If the app still has an unhandled error, you may see an error message, or the app may crash or stop responding. The app won't run normally until the error is fixed. You can try to contact the owner of the app and ask them to fix it.

docs/debugger/using-dump-files.md

@@ -30,7 +30,7 @@ A *dump file* is a snapshot that shows the process that was executing and module
 
 Opening a dump file with a heap in Visual Studio is something like stopping at a breakpoint in a debug session. Although you can't continue execution, you can examine the stacks, threads, and variable values of the app at the time of the dump.
 
-Dumps are mostly used to debug issues from machines that developers don't have access to. You can use a dump file from a customer's machine when you can't reproduce a crash or hang on your own machine. Testers also create dumps to save crash or hang data to use for more testing.
+Dumps are mostly used to debug issues from machines that developers don't have access to. You can use a dump file from a customer's machine when you can't reproduce a crash or unresponsive program on your own machine. Testers also create dumps to save crash or unresponsive program data to use for more testing.
 
 The Visual Studio debugger can save dump files for managed or native code. It can debug dump files created by Visual Studio or by other apps that save files in the *minidump* format.
 

docs/extensibility/debugger/control-of-execution.md

@@ -51,7 +51,7 @@ The debug engine (DE) typically sends one of the following events as the last st
 
    If the debug package is to ignore a particular stopping event, the debug package calls the SDM, which calls [IDebugProgram2::Continue](../../extensibility/debugger/reference/idebugprogram2-continue.md). If the program was stepping into, over, or out of a function when it encountered the stopping condition, it continues the step. This implies that the program maintains a stepping state, so that it knows how to continue.
 
-   The calls the SDM makes to `Step`, **Execute**, and **Continue** are asynchronous, which means that the SDM expects the call to return quickly. If the DE sends the SDM a stopping event on the same thread before `Step`, **Execute**, or **Continue** returns, the SDM hangs.
+   The calls the SDM makes to `Step`, **Execute**, and **Continue** are asynchronous, which means that the SDM expects the call to return quickly. If the DE sends the SDM a stopping event on the same thread before `Step`, **Execute**, or **Continue** returns, the SDM stops responding.
 
 ## See also
 - [Debug tasks](../../extensibility/debugger/debugging-tasks.md)

docs/extensibility/debugger/reference/idebugprocess3-continue.md

@@ -46,7 +46,7 @@ int Continue(
 ## Remarks
  This method is called on this process regardless of how many processes are being debugged, or which process generated the stopping event. The implementation must retain the previous execution state (such as a step) and continue execution as though it had never stopped before completing its prior execution. That is, if a thread in this process was doing a step-over operation and was stopped because some other process stopped, and then `Continue` was called, the specified thread must complete the original step-over operation.
 
- **Warning** Do not send a stopping event or an immediate (synchronous) event to [Event](../../../extensibility/debugger/reference/idebugeventcallback2-event.md) while handling this call; otherwise the debugger may hang.
+ **Warning** Do not send a stopping event or an immediate (synchronous) event to [Event](../../../extensibility/debugger/reference/idebugeventcallback2-event.md) while handling this call; otherwise the debugger may stop responding.
 
 ## See also
 - [IDebugProcess3](../../../extensibility/debugger/reference/idebugprocess3.md)

docs/extensibility/debugger/reference/idebugprocess3-execute.md

@@ -47,7 +47,7 @@ int Execute(
  When the user starts execution from a stopped state in some other process's thread, this method is called on this process. This method is also called when the user selects the **Start** command from the **Debug** menu in the IDE. The implementation of this method may be as simple as calling the [Resume](../../../extensibility/debugger/reference/idebugthread2-resume.md) method on the current thread in the process.
 
 > [!WARNING]
-> Do not send a stopping event or an immediate (synchronous) event to [Event](../../../extensibility/debugger/reference/idebugeventcallback2-event.md) while handling this call; otherwise the debugger may hang.
+> Do not send a stopping event or an immediate (synchronous) event to [Event](../../../extensibility/debugger/reference/idebugeventcallback2-event.md) while handling this call; otherwise the debugger may stop responding.
 
 ## See also
 - [IDebugProcess3](../../../extensibility/debugger/reference/idebugprocess3.md)

docs/extensibility/debugger/reference/idebugprocess3-step.md

@@ -56,7 +56,7 @@ int Step(
 ## Remarks
  In case there is any thread synchronization or communication between threads, other threads in the process should run when a particular thread is stepping.
 
- **Warning** Do not send a stopping event or an immediate (synchronous) event to [Event](../../../extensibility/debugger/reference/idebugeventcallback2-event.md) while handling this call; otherwise the debugger may hang.
+ **Warning** Do not send a stopping event or an immediate (synchronous) event to [Event](../../../extensibility/debugger/reference/idebugeventcallback2-event.md) while handling this call; otherwise the debugger may stop responding.
 
 ## See also
 - [IDebugProcess3](../../../extensibility/debugger/reference/idebugprocess3.md)

docs/extensibility/debugger/reference/idebugprogram2-continue.md

@@ -47,7 +47,7 @@ int Continue( 
  This method is called on this program regardless of how many programs are being debugged, or which program generated the stopping event. The implementation must retain the previous execution state (such as a step) and continue execution as though it had never stopped before completing its prior execution. That is, if a thread in this program was doing a step-over operation and was stopped because some other program stopped, and then this method was called, the program must complete the original step-over operation.
 
 > [!WARNING]
-> Do not send a stopping event or an immediate (synchronous) event to [Event](../../../extensibility/debugger/reference/idebugeventcallback2-event.md) while handling this call; otherwise the debugger may hang.
+> Do not send a stopping event or an immediate (synchronous) event to [Event](../../../extensibility/debugger/reference/idebugeventcallback2-event.md) while handling this call; otherwise the debugger may stop responding.
 
 ## See also
 - [IDebugEngineProgram2](../../../extensibility/debugger/reference/idebugengineprogram2.md)

docs/extensibility/debugger/reference/idebugprogram2-execute.md

@@ -41,7 +41,7 @@ int Execute();
  When the user starts execution from a stopped state in some other program's thread, this method is called on this program. This method is also called when the user selects the **Start** command from the **Debug** menu in the IDE. The implementation of this method may be as simple as calling the [Resume](../../../extensibility/debugger/reference/idebugthread2-resume.md) method on the current thread in the program.
 
 > [!WARNING]
-> Do not send a stopping event or an immediate (synchronous) event to [Event](../../../extensibility/debugger/reference/idebugeventcallback2-event.md) while handling this call; otherwise the debugger may hang.
+> Do not send a stopping event or an immediate (synchronous) event to [Event](../../../extensibility/debugger/reference/idebugeventcallback2-event.md) while handling this call; otherwise the debugger may stop responding.
 
 ## See also
 - [IDebugProgram2](../../../extensibility/debugger/reference/idebugprogram2.md)

docs/extensibility/debugger/reference/idebugprogram2-step.md

@@ -57,7 +57,7 @@ int Step( 
  In case there is any thread synchronization or communication between threads, other threads in the program should run when a particular thread is stepping.
 
 > [!WARNING]
-> Do not send a stopping event or an immediate (synchronous) event to [Event](../../../extensibility/debugger/reference/idebugeventcallback2-event.md) while handling this call; otherwise the debugger may hang.
+> Do not send a stopping event or an immediate (synchronous) event to [Event](../../../extensibility/debugger/reference/idebugeventcallback2-event.md) while handling this call; otherwise the debugger may stop responding.
 
 ## See also
 - [IDebugProgram2](../../../extensibility/debugger/reference/idebugprogram2.md)

docs/extensibility/how-to-roundtrip-VSIXs.md

@@ -207,5 +207,4 @@ At this point, your project should be ready to build a VSIXv3 that can install o
 ![Find a VSIX](media/finding-a-VSIX-example.png)
 
 > [!NOTE]
-> If your project hangs with the message **opening the file**, force shut down Visual Studio, navigate to your project directory, show hidden folders, and delete the *.vs* folder.
- 
+> If your project stops responding with the message **opening the file**, force shut down Visual Studio, navigate to your project directory, show hidden folders, and delete the *.vs* folder.

docs/extensibility/managing-multiple-threads-in-managed-code.md

@@ -10,7 +10,7 @@ ms.workload:
 - vssdk
 ---
 # How to: Manage multiple threads in managed code
-If you have a managed VSPackage extension that calls asynchronous methods or has operations that execute on threads other than the Visual Studio UI thread, you should follow the guidelines given below. You can keep the UI thread responsive because it doesn't need to wait for work on another thread to complete. You can make your code more efficient, because you don't have extra threads that take up stack space, and you can make it more reliable and easier to debug because you avoid deadlocks and hangs.
+If you have a managed VSPackage extension that calls asynchronous methods or has operations that execute on threads other than the Visual Studio UI thread, you should follow the guidelines given below. You can keep the UI thread responsive because it doesn't need to wait for work on another thread to complete. You can make your code more efficient, because you don't have extra threads that take up stack space, and you can make it more reliable and easier to debug because you avoid deadlocks and unresponsive code.
 
  In general, you can switch from the UI thread to a different thread, or vice versa. When the method returns, the current thread is the thread from which it was originally called.
 

docs/ide/diagnostic-data-collection.md

@@ -14,11 +14,11 @@ Visual Studio collects system-generated logs to fix problems and improve the qua
 
 ## Types of collected data
 
-Visual Studio collects system-generated logs for crashes, hangs, UI unresponsiveness, and high CPU or memory usage. We also collect information about errors encountered during product installation or usage. The collected data varies based on the error, and may include stack traces, memory dumps, and exception information:
+Visual Studio collects system-generated logs for crashes, UI unresponsiveness, and high CPU or memory usage. We also collect information about errors encountered during product installation or usage. The collected data varies based on the error, and may include stack traces, memory dumps, and exception information:
 
 - For high CPU usage and unresponsiveness, stack traces of relevant Visual Studio threads are collected.
 
-- For cases where stack traces of some threads aren't enough to determine the root cause of the issue, for example, crashes, hangs or high memory usage, we collect a memory *dump*. The dump represents the state of the process when the error occurred.
+- For cases where stack traces of some threads aren't enough to determine the root cause of the issue, for example, crashes, unresponsiveness or high memory usage, we collect a memory *dump*. The dump represents the state of the process when the error occurred.
 
 - For unexpected error conditions, for example, an exception while trying to write to a file on disk, we collect information about the exception. The information includes the name of the exception, the stack trace of the thread where the exception occurred, the message associated with the exception, and other information relevant to the specific exception.
 

docs/ide/find-and-fix-code-errors.md

@@ -114,7 +114,7 @@ Now that you've successfully built your code and performed a little clean up, ru
 
 Stop your app by pressing **Shift**+**F5** or by clicking the **Stop** button. Or, you can just close the app's main window (or command-line dialog).
 
-If your code ran perfectly and exactly as expected, congratulations! However, if it hung, or crashed, or gave you some strange results, you'll need to find the source of those problems and fix the bugs.
+If your code ran perfectly and exactly as expected, congratulations! However, if it stops responding, or crashed, or gave you some strange results, you'll need to find the source of those problems and fix the bugs.
 
 ### Set simple breakpoints
 
@@ -126,7 +126,7 @@ Set a breakpoint by clicking in the far margin of the line where you want the br
 
 Common uses for breakpoints include:
 
-- To narrow down the source of a crash or hang, scatter breakpoints throughout and around the code of the method call you think is causing the failure. As you run code in the debugger, remove and then reset the breakpoints closer together until you find the offending line of code. See the next section to learn how to run code in the debugger.
+- To narrow down the source of a crash or unresponsive program, scatter breakpoints throughout and around the code of the method call you think is causing the failure. As you run code in the debugger, remove and then reset the breakpoints closer together until you find the offending line of code. See the next section to learn how to run code in the debugger.
 
 - When you introduce new code, set a breakpoint at the beginning of it, and run the code to make sure it is behaving as expected.