Changing "WPF Trace Settings" for Visual Studio debugging has no effect

[spadapet]

• .NET Core Version: 3.1.0-preview1.19476.43
• Windows version: Win10 1903
• Does the bug reproduce also in WPF for .NET Framework 4.8?: No

• Is this bug related specifically to tooling in Visual Studio (e.g. XAML Designer, Code editing, etc...)? Yes but I think it's a bug in NetCore

  Problem description: Visual Studio has the dialog "Options | Debugging | Output Window" to change the trace level of certain WPF traces. You can turn off traces, or increase the level of traces per WPF feature. Changing the trace output level has no effect in NetCore, the default trace level is always chosen. For example, Data Binding traces will only ever output errors, which is the default.

Minimal repro:

• Unzip the following project: TestBindings.zip
• In Visual Studio 16.3.1, open the TestBindingsNetCore.sln solution
• In Tools | Options | Debugging | Output Window | Data Binding, change the setting to "All" or "Off"

• Build and run the project in the debugger (F5), which will have many Binding errors

  Actual behavior: Binding errors are shown in the output window

  Expected behavior:

• If you set the output setting to "All" there should be many more Information items in the output window
• If you set the output setting to "Off" there shouldn't be anything in the output window

Try again with the project TestBindingsNetFx.sln and the setting will work fine (.NET Framework's WPF)

[vatsan-madhavan]

/cc @debonte

[vatsan-madhavan]

Looks like the wpf-etw.man was not updated for .NET Core.

• It still refers to wpfgfx_v0400.dll as its provider, like this, which needs to be updated:

    <provider name="Microsoft-Windows-WPF" guid="{E13B77A8-14B6-11DE-8069-001B212B5009}" symbol="MICROSOFT_WINDOWS_WPF_PROVIDER"
          resourceFileName="%CLR_INSTALL_PATH%\wpf\wpfgfx_v0400.dll" messageFileName="%CLR_INSTALL_PATH%\wpf\wpfgfx_v0400.dll">

The .NET Framework manifest can be seen at %windir%\Microsoft.NET\Framework\v4.0.30319\WPF\wpf-etw.man

We need a few things to happen correctly for the trace provider to be registered in .NET Core.

• Build the 'man' file.
  • mc.exe -um -mof -r resources -h native wpf-etw.man (wpf-etw.man is part of the sources).
  • This would generate the following files:
  • [ ] The provider likely needs a new name, and a new GUID.
  • [ ] 'wpf-etw.h, 'wpf-etw.mof, wpf-etw.rc, MSG00001.bin, wpf-etwTEMP.bin
  • [ ] Consume wpf-etw.h in builds correctly (this is already happening)
  • [ ] Generate wpf-etw.rc by embedding MSG00001.bin (already happening)
  • [ ] Embed wpf-etw.rc into wpfgfx_cor3.dll (also happening already).
• Most importantly, the provider needs to be installed.
  • wevtutil im wpf-etw.man is, I think, called by Setup or CBS for .NET Framework.
    • I couldn't find any evidence that Setup/CBS actually does this for .NET Framework.
    • I suspect what might be actually happening is this: Setup/CBS simply puts wpf-etw.man alongside WPF binaries. Interested parties (for e.g., VS) likely register the manifest (by calling wevtutil just prior to listening to our events).
• We need to puzzle out how to accomplish this for .NET Core.
  • If all we need to do is to deliever wpf-etw.man, we should put it along with ref-assemblies.

[vatsan-madhavan]

• Interested parties (for e.g., VS) likely register the manifest (by calling wevtutil just prior to listening to our events).

@debonte, can you help us confirm whether this is true/false?

[debonte]

@vatsan-madhavan I'm not familiar with this feature and unfortunately I'm also not sure who owns it. I can do some detective work if you'd like.

[vatsan-madhavan]

I'm not familiar with this feature and unfortunately I'm also not sure who owns it. I can do some detective work if you'd like.

I'd appreciate that. I'll start some emails re: this as well. with you.

[vatsan-madhavan]

The general problem with wpf-etw.man embedding seems to apply primarily to native events related to the renderer. I'm able to get Data Binding related trace events by just doing this:

<!--   ...    -->
     xmlns:diag="clr-namespace:System.Diagnostics;assembly=WindowsBase"
<!--   ...    -->
    <diag:PresentationTraceSources.TraceLevel>High</diag:PresentationTraceSources.TraceLevel>

But setting the tracing level in VS IDE still doesn't seem to work.

[vatsan-madhavan]

@debonte, I think this has something to do with the IDE ultimately. I haven't been able to puzzle out the exact cause yet, but WPF is generating the right trace events and I can even see it in the IDE if it is enabled in XAML.

It could be that there is some relationship with https://github.com/dotnet/corefx/issues/24829, but I'm doubtful. I'm going to let your team figure this out - let me know if you find that there is something needed from WPF further.

~(should this issue be moved to another repo for better tracking ?)~ on second thoughts, i'd want to keep this issue around to track improvements to the native ETW eventing infrastructure, but i'd sure like to open another issue to track the IDE experience fixups as well.

[debonte]

@vatsan-madhavan Thanks. We already have a Visual Studio bug (989218) filed by @spadapet. Peter, that bug is currently marked as "Blocked by Partner". Sounds like you should be able to investigate based on what Vatsan said above.

[jtbrower]

I probably should have been a better citizen and reported this bug long ago because I began seeing this issue maybe 4-5 months ago. I have always been using the latest VS Previews as well as latest Net Core Pre.

That said, for anyone looking for a half baked work-around, you can use the System.Diagnostics.PresentationTraceSources to change most of the switches through your application code. For example, I have used the following line to silence many of the nuisance binding messages that are usually not binding problems in the first place.

PresentationTraceSources.DataBindingSource.Switch.Level = SourceLevels.Error;

However, the reason I landed on this issue report today was because I am trying to debug one of my own issues and want to see the output for routed events. Using the following line had no effect on the output. So my 'trick' above, must not work with all TraceSource's.

PresentationTraceSources.RoutedEventSource.Switch.Level = SourceLevels.Verbose;

Just another day in the office as a WPF developer. Back to print statements :).