Runtime: Fusion Log Viewer (fuslogvw)

[raffaeler]

Where can I find the fuslogvw.exe for .net core?
Is it shipped with netcore sdk, runtime, or whatelse?

Thanks!

[gkhanna79]

There is no such artifact for .NET Core. Set COREHOST_TRACE=1 to get the probe location details.

[danmosemsft]

@raffaeler I think thisi s resolved, if not please reopen?

[SteveL-MSFT]

@danmosemsft COREHOST_TRACE=1 is fine for seeing traces when the exe is starting, but is there another env var I can use to have it save the runtime traces to a logfile. In the case of PSCore6, I need to get more details of why a module isn't finding appropriate assemblies and this is after PSCore6 itself successfully started up

[danmosemsft]

@SteveL-MSFT it is hard coded to stderr/stodout. You could redirect those, or propose a change to write directly to a file. Please open an issue in the dotnet/core-setup repo for that.
https://github.com/dotnet/core-setup/blob/master/src/corehost/common/trace.cpp#L44
https://github.com/dotnet/core-setup/blob/24ba120b0ca1ba60a24a79b7dc95866cd3e9f799/src/corehost/common/pal.h#L132

[saikrishnav]

@SteveL-MSFT - I am using "COREHOST_TRACE = 1", but its printing everything on stdout and even if I use "> 1.log", it still prints on console. Any suggestions?

[SteveL-MSFT]

@saikrishnav the traces actually go to stderr, so you can use "2> 1.log"

[saikrishnav]

ah, thanks

[jzabroski]

How do I set COREHOST_TRACE=1? Where can I read more about COREHOST_TRACE=1?

I did the following and re-ran my dotnet global tool and don't see any fusion log viewer messages.

setx COREHOST_TRACE 1

Running my dotnet global tool, I get the following after setting COREHOST_TRACE = 1, which is NOT as useful as Assembly Fusion Logging - why doesn't COREHOST_TRACE log the ilPath and niPath variables for example - this totally sucks:

!!! Could not load file or assembly 'System.Data.SqlClient, Version=4.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. Could not find or load a specific file. (Exception from HRESULT: 0x80131621)
!!! +- Could not load file or assembly 'System.Data.SqlClient, Version=4.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.

Unhandled Exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.IO.FileLoadException: Could not load file or assembly 'System.Data.SqlClient, Version=4.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. Could not find or load a specific file. (Exception from HRESULT: 0x80131621) ---> System.IO.FileLoadException: Could not load file or assembly 'System.Data.SqlClient, Version=4.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
   at System.Runtime.Loader.AssemblyLoadContext.LoadFromPath(IntPtr ptrNativeAssemblyLoadContext, String ilPath, String niPath, ObjectHandleOnStack retAssembly)
   at System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyPath(String assemblyPath)
   at System.Reflection.Assembly.LoadFrom(String assemblyFile)
   at System.Reflection.Assembly.LoadFromResolveHandler(Object sender, ResolveEventArgs args)
   at System.AppDomain.InvokeResolveEvent(ResolveEventHandler eventHandler, RuntimeAssembly assembly, String name)

[mattwarren]

How do I set COREHOST_TRACE=1? Where can I read more about COREHOST_TRACE=1?

You can read more about the tracing in this doc https://github.com/dotnet/core-setup/blob/master/Documentation/design-docs/host-tracing.md (note that in places that doc is talking about proposed changes for .NET Core 3.0, I don't know which ones are are already available)

[jzabroski]

@mattwarren Ha! I was just about to ask you on Twitter if you knew how to debug dotnet global tools. I feel like this is stuff I should know how to do as a senior developer, but with .NET Core I have no idea what I'm doing and am embarrassed.

[jzabroski]

@mattwar OK, this is interesting: I realized my problem was I needed to open a new shell to use COREHOST_TRACE=1, but since I opened PowerShell 6, which is a .NET Core app, it now takes a long time to start my shell because it spools the Holy Bible of PowerShell assemblies by book, chapter and verse.

[mattwarren]

Yep! The 'Future investments' section talks about improving this, but I don't know what the current status is https://github.com/dotnet/core-setup/blob/master/Documentation/design-docs/host-tracing.md#future-investments

[jzabroski]

Thank you! I am now able to debug this. It's not perfect, but I'm in a 1000x better spot than I was 30 minutes ago feeling _stoopid_...

[IanKemp]

@jzabroski I would love to know how you managed to debug this, because in my case setting COREHOST_TRACE=1 simply makes the process spew out thousands of lines of junk, none of which involves the actual assembly that's failing to load (which makes it actually less useful than fuslogvw).

[jzabroski]

@IanKemp Hey man - I can hear your frustration in this comment and in the related issue https://github.com/dotnet/coreclr/issues/24035#issuecomment-527042535

To be honest, my issue is not fully solved, but I definitely was able to get very far (and then realize I needed a different approach to my problem).

You can read my debugging steps here, in a project I'm co-maintainer of: https://github.com/fluentmigrator/fluentmigrator/issues/1014

In my case, the issue was that I was using the new .NET SDK project system, which, on pack, does not pack transitive dependencies. However, even when you manually pack your core assembly and its transitive dependencies into a "Fat package" (e.g., via OctoPack), you can still end up in situations where a .NET Global Tool is registered with one version of the runtime and your DLLs injected into that Global Tool are from a different runtime version. This is because there is no way to specify how to fallback. - Binding Redirects are effectively gone in .NET Core and replaced with AssemblyLoadContext API.

Now, in my opinion (and this might throw you for a real loop!), the crux of the problem is two-fold:

1. There is no clean API for dynamically loading assemblies in .NET Core (or even .NET Framework).
   
   
   
   1. For this problem, I am working with Nate McMaster of the ASP.NET Core team on his project, DotNetCorePlugins, to attempt to define such an API
   
   
2. Assembly Fusion Logger in itself is a bug, in my opinion - it only existed in .NET Framework because my prior point (need for clean API to load assemblies) didn't exist. Arbitrary assembly loading is a bug, and frankly does not jive with Bill Gates' Trustworthy Computing Initiative (email from 2002!).

I reserve the right to change my highly opinionated opinions in the future, as more information comes available, but for now, this is where I stand. I've omitted more annoying (and orthogonal) edge cases in this discussion, like loading an AnyCPU assembly into a 64 bit context, but the AnyCPU assembly itself tries to load a 32 bit context assembly.

If you squint harder, you'll note that I'm also telling a small, white lie: In the most general case, you do need some kind of arbirary assembly loader. That's effectively what the "Out of Process" model of dotnet-fm is: You can install a .NET Global Tool that loads DLLs that will use our default "convention over configuration" processing pipeline for database migrations. The same goes for our MSBuild Task plug-in. Corollary to white lie: In order for a lie to exist, it requires a listener! So, to side step the problem, avoid the out of process model altogether. This is the trick employed by most large scale .NET Global Tools, like BenchmarkDotNet. Except no one really articulates this trick, anywhere. It's just out there in the Aether. In .NET Core, this has become known as "In-process Toolchains" by 'Softies and a few MVPs. See our FluentMigrator issue, External runners are unreliable, for further discussion.

[jzabroski]

@IanKemp Was that at all helpful to you?

[heaths]

Why doesn't this use EventSource, giving developers flexibility where to send bind logs?

[jzabroski]

@heaths I believe @brianrob worked on the EventPipe standard as part of .NET Core 2.0. I don't know the details of CoreCLR to know why it had to be done this way.

That said, the general issue remains: Opening PowerShell v6 (written in .NET Core) with these flags enabled causes the shell to print a ton of debug messages (regardless of the logging location). This simply can't be how it was intended.

I had argued to Vance Morrison and Brian Robbins that EventPipe should implement RAII and the previous EventListener API should be deprecated in favor of an RAII design pattern that supports a "super-fold" filter on all outgoing events, which would allow EventPipe to not just be about destination format, but also destination targeting and filtering.