How to prevent VS2022 Output window from swallowing Trace.Write() messages?

Question

How to prevent VS2022 Output window from swallowing Trace.Write() messages?

AMG 10

I'm running a .NET 7.0 project from VS2022 and I'd like to simply output all Trace messages to DebugView++. Everything works great, but only when there is no debugger attached. If I start debugging the project in VS, Trace.Write() goes only to the Output window. If I detach the debugger, DebugView++ will immediately begin showing the Trace messages. If I reattach the debugger, it will immediately stop writing to DebugTrace and writes in the Output window. I can switch it all day long, so it seems the Output window is redirecting all Trace output to the Output window; all I want is for VS to stop screwing with the Trace output always and forever. Is this even possible?

Here's a simple logger class I'm using to test this.


    public static class Logger
    {
        readonly static TraceListener? listener = null;

        static Logging()
        {
            Trace.Listeners.Clear();

            listener = new DefaultTraceListener();
            Trace.Listeners.Add(listener);

            Trace.AutoFlush = true;
        }

        public static void Trace(string message, [CallerMemberName] string callerName = "")
        {
            var msg = $"[TestProject|{callerName}] {message}";

            System.Diagnostics.Trace.WriteLine(msg);
        }
    }

David Lowndes 2,615 Reputation points MVP

2023-05-31T19:07:39.58+00:00

Have you tried changing the Debugging, Output Windows, "All debug output" setting to off?

AMG 10

Yes, to no avail. There is a small VSIX package (OutputForwarder2022) that is meant to get around this, but it crashes on load on every machine I've tried.

This is the entire extension, and it looks like it's just re-calling Trace.Write()! I'm figuring that it's working because it's actually running inside VS and not my app and so is able to write the messages to DebugView++. I don't know enough about the internals to know if this is a potential fix, but it seems the solution would be to create a create another thread and call Trace.Write() from that. Isn't there a low-level like with p/invoke using the windows API to bypass the debugger? OutputDebugString() seems to have no effect either.

    internal class Forwarder
    {
        Forwarder(AsyncPackage package)
        {
            InstallForwarder(package);
        }

        private void InstallForwarder(AsyncPackage package)
        {
            // Get a reference to the pane in the output window
            IVsOutputWindow outputWindow = Package.GetGlobalService(typeof(SVsOutputWindow)) as IVsOutputWindow;
            Guid paneGuid = VSConstants.GUID_OutWindowDebugPane;    // codenotes: GUID_BuildOutputWindowPane / GUID_OutWindowDebugPane
            IVsOutputWindowPane debugPane;
            outputWindow.GetPane(ref paneGuid, out debugPane);

            IVsUserData userData = debugPane as IVsUserData;
            object o;
            Guid guidViewHost = DefGuidList.guidIWpfTextViewHost;
            userData.GetData(ref guidViewHost, out o);

            IWpfTextViewHost viewHost = o as IWpfTextViewHost;
            m_textView = viewHost.TextView;
            m_textView.TextBuffer.Changed += new EventHandler<Microsoft.VisualStudio.Text.TextContentChangedEventArgs>(TextBuffer_Changed);
            Trace.AutoFlush = true;
        }

        private void TextBuffer_Changed(object sender, Microsoft.VisualStudio.Text.TextContentChangedEventArgs e)
        {
            foreach (var change in e.Changes)
            {
                string text = change.NewText.ToString();
                while (text.Length > 4090)
                {
                    Trace.Write("Following lines exceeded 4090 chars!\n");
                    var part = text.Substring(0, 4090);
                    int nlIndex = part.LastIndexOf("\n", 0);
                    if (nlIndex == -1)
                    {
                        Trace.Write(part);
                        text = text.Substring(4091);
                    }
                    else
                    {
                        Trace.Write(part.Substring(0, nlIndex + 1));
                        text = text.Substring(nlIndex + 1);
                    }
                }
                Trace.Write(text);
            }
        }

        public static Forwarder Instance
        {
            get;
            private set;
        }

        public static void Initialize(AsyncPackage package)
        {
            Instance = new Forwarder(package);
        }

        private IWpfTextView m_textView;
    }

David Lowndes 2,615 Reputation points MVP

2023-05-31T20:18:47.7233333+00:00

Disabling the Program Output category from the Output pane prevents the output of System.Diagnostics.Trace.WriteLine for me. Having said that, it doesn't allow the trace to appear in DebugView :(
David Lowndes 2,615 Reputation points MVP

2023-05-31T20:29:13.89+00:00

If you'd like to submit a suggestion (use the VS Suggest a Feature) that the VS debugger shouldn't prevent other debug viewers from showing the program output, please do so and be sure to post a link to the item back here so others can find it and vote for it.
AMG 10 Reputation points

2023-05-31T21:31:12.3633333+00:00

I just made a simple trace listener that just forwards the Trace message to DebugView++ via UDP. Still doesn't solve the main problem since there's more than just DebugView++ that I need to communicate with. I'm just going to make a separate app that listens for these UDP messages and forward it to the Trace.Write(). Bandaid, but better than nothing.

1 answer

Your answer

David Lowndes 2,615 Reputation points MVP

2023-05-31T19:07:39.58+00:00

Have you tried changing the Debugging, Output Windows, "All debug output" setting to off?
David Lowndes 2,615 Reputation points MVP

2023-05-31T20:18:47.7233333+00:00

Disabling the Program Output category from the Output pane prevents the output of System.Diagnostics.Trace.WriteLine for me. Having said that, it doesn't allow the trace to appear in DebugView :(
David Lowndes 2,615 Reputation points MVP

2023-05-31T20:29:13.89+00:00

If you'd like to submit a suggestion (use the VS Suggest a Feature) that the VS debugger shouldn't prevent other debug viewers from showing the program output, please do so and be sure to post a link to the item back here so others can find it and vote for it.
AMG 10 Reputation points

2023-05-31T21:31:12.3633333+00:00

I just made a simple trace listener that just forwards the Trace message to DebugView++ via UDP. Still doesn't solve the main problem since there's more than just DebugView++ that I need to communicate with. I'm just going to make a separate app that listens for these UDP messages and forward it to the Trace.Write(). Bandaid, but better than nothing.

Answer 1

Hi @AMG,

Welcome to Microsoft Q&A!

I suppose it is designed like this.

If you attach a debugger to the process, the output of Trace.Write() will go to the debugger, not DebugView.

Sincerely,

Anna

If the answer is the right solution, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Share via

How to prevent VS2022 Output window from swallowing Trace.Write() messages?

1 answer

Your answer