Log details of app being launched by dotnet(.exe) to ETW/LTTng

[DamianEdwards]

There is a desire in certain environments to get details about .NET Core apps being launched in order to aid in analysis of issues, distribution of frameworks and dependencies being loaded, etc. (similar to the way that .NET apps log to the Windows Event log when they crash to capture details of failure). This can be particularly useful to discover how many apps are using a given shared framework version (to aid in planning to uninstall that version), or which apps are using a particular dependency (in case there is a security or compliance issue of some kind).

To this end, the host layer should log details about the app being launched to the appropriate sink for the OS (e.g. ETW on Windows, LTTng on Linux). The following details would be helpful:

• Path and version of dotnet host
• Path, name and version of any shared frameworks depended on by the application, including details of whether the app will run on that version or be rolled forward to a newer version
• Path and contents of any additional deps being applied
• Names and versions of any dependencies declared by the application in its deps file
• Name and version of the application assembly
• Path of the application assembly

It might be good to enable configuring which of these details is logged, e.g. via ETW event names or keywords.

[Petermarcu]

@brianrob

[DamianEdwards]

Would like this to be considered for next minor release, or even better, a servicing release 😄

[brianrob]

CoreCLR has the concept of the RuntimeInformation event which does a stripped-down version of this for things that the runtime knows, and it is quite valuable. This is what is logged in the RuntimeInformation event:

• Runtime version
• Path to coreclr.dll/libcoreclr.so
• Startup flags
• Command line (not always populated in the case of CoreCLR)
• COM object GUID

It can be quite useful and I can imagine that the information requested here would also be quite valuable. One thing to note is that amost all of the information requested here is information that the host has but the runtime does not. This complicates things just a bit because the component that knows how to log to the platform-dependent and platform-independent loggers is the runtime. I would recommend designing a mechanism to pass this information from the host to the runtime and let the runtime log it. This will guarantee that the information is exposed in all the right logging mechanisms on each platform (both platform-independent and platform-dependent).

I can help with details on exactly what to do here.

[DamianEdwards]

Sounds great.

Where is the RuntimeInformation event logged today?

[brianrob]

It's logged in a few places:

• Runtime start-up
• During rundown (when stopping trace collection) in case we didn't capture or lost the start-up event.

The code that does the actual logging is here: https://github.com/dotnet/coreclr/blob/86f418f0bd196ba84ab702410500271a4f8b0c33/src/vm/eventtrace.cpp#L4926.

It is called from a few different places.

[DamianEdwards]

@blowdart

[blowdart]

Oh yes, I want this for security scanning, including fingerprinting of assemblies (SHA and signer would be great) loaded during startup, and even better, runtime, for dynamic loaded.

[DamianEdwards]

Curious where this has landed? Are we getting this for 3.0?

[jeffschwMSFT]

We are still gathering details on what should be logged. We should put this on the potential list for .NET Core 3.1

[DamianEdwards]

ping ?

[jeffschwMSFT]

It is on our backlog. @DamianEdwards are you the right person to get the specifics on what is needed? We explored this in late .NET Core 3, but the requirements were not solid enough for us to build something.

cc @vitek-karas @elinor-fung @lpereira

[DamianEdwards]

Right owner would be someone on @glennc's team I think, and I know for sure @blowdart is interested too. I provided a strawman summary up front on this issue and I think it's probably still a good place to start.

[swaroop-sridhar]

@vitek-karas, @shirhatti, and @noahfalk talked about this issue. Here are some notes.

• When the host fails to load the runtime, the error logging is limited, since the apphost is a simple native app that cannot take many dependencies. The tracing is limited to:
  • The error logging to console (or upcoming UI message on windows)
  • Tracing information, when the app is actually run with COREHOST_TRACE turned on
• Once the runtime is loaded, we can send ETW, event-pipes, etc.
• In .net core 3/3.1 the host-runtime interface is limited to the host passing a set of strings to the runtime. In .net 5, this will be replaced with a set of callbacks from the runtime to the host -- and therefore, the runtime can expose APIs to request specific information from the host.

Here is the work we agreed to perform in 3.1:

• If/when the runtime is loaded:
  • Log all properties passed to the runtime
  • Log the set of frameworks loaded, along with requested-version and resolved-version for each framework.
• No change in the case where the host fails to load the runtime

This will be achieved by:

• The host writes a string containing the above information as a new property passed to the runtime
• The runtime will generate an event containing all properties passed to it.
• The values of some of the well-known properties may be well-structured (if it is easy enough to do). Otherwise we log the actual strings passed in.

[vitek-karas]

Based on recent offline discussion with @blowdart the security scanning aspect is a somewhat different ask. In addition it might already be sort of "resolved" by existing assembly loader tracing.