Make it easy to determine entry assembly path when debugging CoreCLR

[vitek-karas]

When debugging for example crash dumps of .NET applications, it is often helpful to be able to quickly identify the entry assembly for the process/dump. Currently this information is easily accessible from managed code via Assembly.GetEntryAssembly().Location but it's very difficult to get to when in the debugger without ability to invoke methods or run managed code in general. For example, if the process was started via dotnet app.dll, it's difficult to determine the app.dll from a dump.

The proposal is to add a new static global variable into coreclr module, which will contain the path of the entry assembly once that information is known.

In detail:

• Add static global variable with the full path to the entry assembly
• The variable would be a WCHAR * type - UTF16 encoded string stored on the heap
• Modify EnumMemRegions such that string on the heap is stored in a dump even if the dump will not contain the full heap
• The variable is only initialized if the runtime "executes an assembly", so not if the runtime was started via native hosting APIs and is invoked using get_delegate or similar mechanisms.
• The variable is left NULL until it can be initialized, or for the lifetime of the runtime if there's no entry assembly defined (native hosting scenarios).
• The variable doesn't change its value once it's set to some path

To be figured out:

• The name of the variable
• Interaction with startup hooks - when exactly we would set the value (before or after startup hooks)

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

When debugging for example crash dumps of .NET applications, it is often helpful to be able to quickly identify the entry assembly for the process/dump. Currently this information is easily accessible from managed code via Assembly.GetEntryAssembly().Location but it's very difficult to get to when in the debugger without ability to invoke methods or run managed code in general. For example, if the process was started via dotnet app.dll, it's difficult to determine the app.dll from a dump.

The proposal is to add a new static global variable into coreclr module, which will contain the path of the entry assembly once that information is known.

In detail:

• Add static global variable with the full path to the entry assembly
• The variable would be a WCHAR * type - UTF16 encoded string stored on the heap
• Modify EnumMemRegions such that string on the heap is stored in a dump even if the dump will not contain the full heap
• The variable is only initialized if the runtime "executes an assembly", so not if the runtime was started via native hosting APIs and is invoked using get_delegate or similar mechanisms.
• The variable is left NULL until it can be initialized, or for the lifetime of the runtime if there's no entry assembly defined (native hosting scenarios).
• The variable doesn't change its value once it's set to some path

To be figured out:

• The name of the variable
• Interaction with startup hooks - when exactly we would set the value (before or after startup hooks)

Author:	vitek-karas
Assignees:	-
Labels:	area-AssemblyLoader-coreclr
Milestone:	-