You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Move profiler documentation from the runtime repo to the docs repo.
Add description of new possible environment variable names.
Fixes#49963
---------
Co-authored-by: Noah Falk <noahfalk@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Genevieve Warren <24882762+gewarren@users.noreply.github.com>
> Starting in .NET 11, profiler environment variables now support both `DOTNET` and `CORECLR` prefixes. The `DOTNET` prefix is the new standard, while `CORECLR` is maintained for backwards compatibility and might be removed in the future.
14
+
12
15
## Enable diagnostics
13
16
14
17
- Configures whether the debugger, the profiler, and EventPipe diagnostics are enabled or disabled.
@@ -23,11 +26,12 @@ This article details the settings you can use to configure .NET debugging and pr
23
26
24
27
- Configures whether profiling is enabled for the currently running process.
25
28
- If you omit this setting, profiling is disabled. This is equivalent to setting the value to `0`.
29
+
- To load a profiler, in addition to enabling profiling, the profiler GUID and profiler location also need to be configured using these settings.
Once profiling is enabled, the profiler can be loaded in two ways: with environment variables (cross-plat) or through the registry (Windows only). The profiler path environment variables take precedence over any COM library path in the registry if both are specified.
48
+
49
+
### Environment variable (cross-plat)
50
+
43
51
- Specifies the path to the profiler DLL to load into the currently running process (or 32-bit or 64-bit process).
44
52
- If more than one variable is set, the bitness-specific variables take precedence. They specify which bitness of profiler to load.
45
-
- For more information, see [Finding the profiler library](https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/profiling/Profiler%20Loading.md).
|**Environment variable**|`CORECLR_PROFILER_PATH` or `DOTNET_PROFILER_PATH`|*string-path*|
57
+
|**Environment variable**|`CORECLR_PROFILER_PATH_32` or `DOTNET_PROFILER_PATH_32`|*string-path*|
58
+
|**Environment variable**|`CORECLR_PROFILER_PATH_64` or `DOTNET_PROFILER_PATH_64`|*string-path*|
59
+
|**Environment variable**|`CORECLR_PROFILER_PATH_ARM32` or `DOTNET_PROFILER_PATH_ARM32`|*string-path*|
60
+
|**Environment variable**|`CORECLR_PROFILER_PATH_ARM64` or `DOTNET_PROFILER_PATH_ARM64`|*string-path*|
61
+
62
+
### Through the registry (Windows only)
63
+
64
+
When the `DOTNET_PROFILER_PATH*`[environment variables](#environment-variable-cross-plat) aren't set while running on Windows, coreclr looks up the CLSID from `DOTNET_PROFILER` in the registry to find the full path to the profiler's DLL. Just like with any COM server DLL, the profiler's CLSID is looked up under HKEY_CLASSES_ROOT, which merges the classes from HKLM and HKCU.
0 commit comments