Fix typos (#72709)

docs/workflow/ci/coreclr-ci-health.md

@@ -111,7 +111,7 @@ The **Failure Trend** graph attempts to show what is failing in bar graph and gi
 
 The **Failed Runs** graph is the most interesting for finding specific issues. As of writing the `Top 10 failing tasks` are:
 
-*Note* that any one of these buckets can include random one off infrastructure failures or systimatic Azure Dev Ops failures. For example the build bucket can include issues like:
+*Note* that any one of these buckets can include random one off infrastructure failures or systematic Azure Dev Ops failures. For example the build bucket can include issues like:
 
 >  fips.c(143): OpenSSL internal error
 

docs/workflow/debugging/coreclr/debugging-aot-compilers.md

@@ -175,4 +175,4 @@ This will launch the Visual Studio debugger, with a solution setup for debugging
 
 # Debugging compilation graph
 
-The AOT compilation is driven by a dependency graph. If you need to troubleshoot the dependency graph (to figure out why something was or wasn't generated) you can follow [this guide](debuging-compiler-dependency-analysis.md)
+The AOT compilation is driven by a dependency graph. If you need to troubleshoot the dependency graph (to figure out why something was or wasn't generated) you can follow [this guide](debugging-compiler-dependency-analysis.md)

docs/workflow/debugging/coreclr/debugging-compiler-dependency-analysis.md

@@ -34,7 +34,7 @@ Usage instructions:
 
 # Single Node Exploration #
 Once the interesting node(s) have been identified in the dependency graph window, select one of them, and then press Explore.
-  - In the Node Explorer window, the Dependent nodes (the ones which dependend on the current node are the nodes displayed above, and the Dependee nodes (the nodes that this node depends on) are displayed below. Each node in the list is paired with a textual reason as to why that edge in the graph exists.
+  - In the Node Explorer window, the Dependent nodes (the ones which depend on the current node are the nodes displayed above, and the Dependee nodes (the nodes that this node depends on) are displayed below. Each node in the list is paired with a textual reason as to why that edge in the graph exists.
   - Select a node to explore further and press the corresponding button to make it happen.
 
 WhyDGML

docs/workflow/debugging/mono/android-debugging.md

@@ -60,7 +60,7 @@ Since you're debugging an optimized release build, it is likely the debugger wil
 Build the runtime for your android architecture: `ANDROID_NDK_ROOT=<path_to_android_ndk> ./build.sh --os android --arch x86 -c Debug`. See the instructions for [Testing Android](../../testing/libraries/testing-android.md) for details.
 
 
-In the source code for the C# project, add the following to the .csproj (replacing `<RUNTIME_GIT_ROOT>` by the apropriate location):
+In the source code for the C# project, add the following to the .csproj (replacing `<RUNTIME_GIT_ROOT>` by the appropriate location):
 
 ```
   <Target Name="UpdateRuntimePack"

docs/workflow/debugging/mono/wasm-debugging.md

@@ -61,7 +61,7 @@ disassemble wasm executables (.wasm files).
 Wasm execution can be made deterministic by passing the -s DETERMINISTIC=1 option to emcc.
 This will cause the app to always execute the same way, i.e. using the same memory
 addresses, random numbers, etc. This can be used to make random crashes happen reliably.
-Sometimes, hovewer, turning this on will make the problem disappear. In this case, it
+Sometimes, however, turning this on will make the problem disappear. In this case, it
 might be useful to add some controlled indeterminism. For example, to make the
 random number generator mostly deterministic, change `$getRandomDevice` in
 `upstream/emscripten/src/library.js` to:

docs/workflow/testing/coreclr/windows-test-instructions.md

@@ -45,7 +45,7 @@ This will use `crossgen.exe` to precompile test executables before they are exec
 src\tests\build.cmd -priority=1
 ```
 
-The above is an example of requesting that priority '1' and below be built. The default priority value is '0'. If '1' is specified, all tests with `CLRTestPriorty` `0` **and** `1` will be built and run.
+The above is an example of requesting that priority '1' and below be built. The default priority value is '0'. If '1' is specified, all tests with `CLRTestPriority` `0` **and** `1` will be built and run.
 
 ## Generating Core_Root
 

docs/workflow/testing/mono/testing.md

@@ -26,7 +26,7 @@ For example: `./build.sh mono release -test:JIT/opt/InstructionCombining/DivToMu
 
 Run individual test:
 ```
-bash ./artifacts/tests/coreclr/OSX.x64.Release/JIT/opt/InstructionCombining/DivToMul/DivToMul.sh -coreroot=`pwd`/artifacts/tests/coreclr/OSX.x64.Release/Tests/Core_Root 
+bash ./artifacts/tests/coreclr/OSX.x64.Release/JIT/opt/InstructionCombining/DivToMul/DivToMul.sh -coreroot=`pwd`/artifacts/tests/coreclr/OSX.x64.Release/Tests/Core_Root
 ```
 
 Run all built tests:
@@ -118,7 +118,7 @@ make run
 Note that the default configuration of this sample is LLVM JIT.
 
 ## WebAssembly
-To run the WebAssembly sample, cd to `wasm`.  There are two sub-folders `browser` and `console`. One is set up to run the progam in browser, the other is set up to run the program in console. Enter the desirable sub-folder and execute
+To run the WebAssembly sample, cd to `wasm`.  There are two sub-folders `browser` and `console`. One is set up to run the program in browser, the other is set up to run the program in console. Enter the desirable sub-folder and execute
 
 ```
 make build && make run