Console.Write() will hang in WPF, but works in Console application

Question

Please read the answer by Scott Chamberlain to see why is it related to WINAPI.

Create a new WPF application in Visual Studio and change the code in MainWindow.xaml.cs as below. Run the application. The code will hang on second call to Console.Write().

MainWindow.xaml.cs

using System;
using System.Text;
using System.Windows;

namespace TestWpf
{
    /// <summary>
    /// Interaction logic for MainWindow.xaml
    /// </summary>
    public partial class MainWindow : Window
    {
        public MainWindow()
        {
            InitializeComponent();

            byte[] msg = new byte[1024];

            string msgStr = Encoding.Default.GetString(msg);

            for (int i = 0; i < 10; i++)
            {
                Console.Write(msgStr);
            }
        }
    }
}

Now create a new Console application in Visual Studio and change the code in Program.cs as below. Run the application. It will run successfully i.e. it will not hang.

Program.cs

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            byte[] msg = new byte[1024];

            string msgStr = Encoding.Default.GetString(msg);

            for (int i = 0; i < 100; i++)
            {
                Console.Write(msgStr);
            }
        }
    }
}

Questions:

Why the second call to Console.Write() hangs in the WPF application?
Why the behavior is different in console application?
Why does it only happen if the string is a string of \0? (It works fine if you do 1024 spaces.)

I have done similar thing but its not blocking call. Debug your code. May be error is something else. — Muhammad Umar, Mar 27 '14 at 05:34
@MuhammadUmar This is the only code I have. Just checked once again and it blocks. What version of .NET are you testing? — Roman Byshko, Mar 27 '14 at 05:37
@MuhammadUmar did you run his WPF example exactly, I can re-create the issue. The write call works fine once but hangs on the 2nd call. Changing it from 1024 nulls to 1024 spaces causes it to not hang. — Scott Chamberlain, Mar 27 '14 at 05:47
I found out what it is hanging on (it blocks on the native call to WriteFile) but I have yet to figure out *why* it hangs (it is because the buffer is full, but I don't know what is causing it to happen). Still looking. — Scott Chamberlain, Mar 27 '14 at 06:09
@ScottChamberlain It seems to hang when debugging only. Running without the debugger attached and it finishes the loop. — Walt Ritscher, Mar 27 '14 at 06:21
@ScottChamberlain I concur that its seems to be hanging during the call to WriteFile — Walt Ritscher, Mar 27 '14 at 06:23
It also hangs in a WinForms app, but it makes it through 4 loops before stopping. — Walt Ritscher, Mar 27 '14 at 06:35

score 6 · Answer 1 · edited May 23 '17 at 10:30

Basic Explanation: It hangs because the buffer Console.Write writes to before the text is displayed is getting full and is not draining out for WPF applications when passing in null characters (\0) for reasons beyond my knowledge.

Detailed Explanation: When you call Console.Write it creates a Handle to output it's data to and eventually calls WriteFile on that handle. The other end of the handle needs to process the data that was written to it then return control to the caller. There are two major differences between WPF and a console application I could find:

First, if you inspect the handle type with a console application you get a handle of type FILE_TYPE_CHAR, from WPF you get FILE_TYPE_PIPE.

Console.Write(msgStr);

var cOut = Console.OpenStandardOutput();
var handle = cOut.GetType().GetField("_handle", BindingFlags.NonPublic | BindingFlags.Instance).GetValue(cOut);
var method = Type.GetType("Microsoft.Win32.Win32Native").GetMethod("GetFileType", BindingFlags.Static | BindingFlags.Public | BindingFlags.NonPublic);
var type = method.Invoke(null, new object[] { handle });
Debugger.Break();

Second, how the handle is processed on the receiving end is different. In a console application the handle is read in by conhost.exe, in WPF it is read in by visual studio.

The hang itself comes from the fact that there is limited space in the buffer and only so much text can be queued up before the handle has to block new incoming requests so the existing information can drain out. It appears that the handle for the console application can process large numbers of \0 characters but the handle that WPF generates can not. If that difference is from it being a different kind of handle or from the processor on the other side of the handle reading in data differently I don't know.

Hopefully someone who has more experience than me with the Windows API call WriteFile that can explain the differences between the two handle types and will give us a better idea if this is because of the handle type or because of the receiving program.

Alois Kraus · Answer 2 · 2014-03-29T08:21:31.727

This works on my machine without issues (Winodws 8.1 VS2013). The problem has nothing to do with the console application. As Scott explained there is some blocking going on. It works when not run under a debugger

As WPF Application
As Console Application

It will hang when you are trying to debug the application. The deeper reason is that you are sending \0 over the pipe. A pipe has a send buffer (ca. 4 KB) before it blocks further writes to it. This is what you are seeing as a hanging WriteFile call in kernel32.dll. To be able to block there must be someone who wants to read from your pipe. In that case it is VS trying to get your stdout to the debugger output window. When no one is listening the pipe acts as null device which will never block.

Now back to the question why it does work with all strings except \0? This has something to do how to stop reading from a a pipe. The receiver can stop reading from the pipe when it receives \0 as the only message. This is the signal that the process has exited and no further data will be written to it. With your \0 messages you violate that implicit contract and send further data over the pipe but your client (VS) has stopped listening to you. That is not actually an API but seems to be a common agreement. In .NET yout get for async pipe reads e.g. null as last message back. Other applications (e.g. VS) seem to handle \0 messages in a similar way and assume the writer has exited.

It is legal to simply close the pipe handle in that case ReadFile returns false. Our you can also write a message of 0 bytes length to the pipe. Or you can write a 1024 KB null array to the pipe. It is up the reader of your messages to decide if this is the signal to stop reading from your pipe.

Update 1 Since at least one commenter was thinking that logic is not enough here is the result of debugging VS. VS does read from the pipe via ReadFile

vsdebug!CReader::ReadPipe

There is a check if the first byte is 0 which then leads to thread termination. If the first byte is not 0 it is treated as unicode string and copied to a string buffer which is displayed in the debugger output window. You can verify this easily by sending instead e.g. 1000 c chars which will show up in the buffer. Then you can follow the control flow where it differs from 1000 0 bytes. It turns out that the relevant piece is:

0:048> db ebp-420
1973f794  00 00 00 00 38 63 71 10-fe 03 00 00 92 82 b5 45  ....8cq........E
1973f7a4  63 63 63 63 63 63 63 63-63 63 63 63 63 63 63 63  cccccccccccccccc
1973f7b4  63 63 63 63 63 63 63 63-63 63 63 63 63 63 63 63  cccccccccccccccc
1973f7c4  63 63 63 63 63 63 63 63-63 63 63 63 63 63 63 63  cccccccccccccccc
1973f7d4  63 63 63 63 63 63 63 63-63 63 63 63 63 63 63 63  cccccccccccccccc
1973f7e4  63 63 63 63 63 63 63 63-63 63 63 63 63 63 63 63  cccccccccccccccc
1973f7f4  63 63 63 63 63 63 63 63-63 63 63 63 63 63 63 63  cccccccccccccccc
1973f804  63 63 63 63 63 63 63 63-63 63 63 63 63 63 63 63  cccccccccccccccc

Buffer contains data a ebp-410 where are our c characters. Before that there is the buffer size and file handle stored.

    0:048> u 5667dd48  L50
    vsdebug!ReaderThreadStart+0x72:
    **5667dd48 80bdf0fbffff00  cmp     byte ptr [ebp-410h],0**  check if first byte is 0 
    5667dd4f 7446            je      vsdebug!ReaderThreadStart+0xc1 (5667dd97)
    5667dd51 899decfbffff    mov     dword ptr [ebp-414h],ebx
    5667dd57 897dfc          mov     dword ptr [ebp-4],edi
    5667dd5a 8d85f0fbffff    lea     eax,[ebp-410h]
    5667dd60 53              push    ebx
    5667dd61 53              push    ebx
    5667dd62 50              push    eax
    5667dd63 8d8decfbffff    lea     ecx,[ebp-414h]
    5667dd69 e8f5960200      call    vsdebug!CVSUnicodeString::CopyString (566a7463)
    5667dd6e c745fc02000000  mov     dword ptr [ebp-4],2
    5667dd75 8b4e30          mov     ecx,dword ptr [esi+30h]
    5667dd78 6aff            push    0FFFFFFFFh
    5667dd7a ffb5ecfbffff    push    dword ptr [ebp-414h]
    5667dd80 e84453f6ff      call    vsdebug!CMinimalStreamEx::AddStringW (565e30c9)
    5667dd85 834dfcff        or      dword ptr [ebp-4],0FFFFFFFFh
    5667dd89 8d8decfbffff    lea     ecx,[ebp-414h]
    5667dd8f 53              push    ebx
    5667dd90 e86339f5ff      call    vsdebug!CVSVoidPointer::Assign (565d16f8)
    5667dd95 eb03            jmp     vsdebug!ReaderThreadStart+0xc4 (5667dd9a)
   ** 5667dd97 897e28          mov     dword ptr [esi+28h],edi ** When 0 go here and sleep 200ms
    5667dd9a 68c8000000      push    0C8h
    5667dd9f ff151c228056    call    dword ptr [vsdebug!_imp__Sleep (5680221c)]
    5667dda5 e978caf9ff      jmp     vsdebug!ReaderThreadStart+0xd4 (5661a822)
    5667ddaa e87ffc0d00      call    vsdebug!__report_rangecheckfailure (5675da2e)
    5667ddaf cc              int     3
    5667ddb0 b9fe030000      mov     ecx,3FEh
    5667ddb5 899de4fbffff    mov     dword ptr [ebp-41Ch],ebx
    5667ddbb 3bc1            cmp     eax,ecx
    5667ddbd 7702            ja      vsdebug!CReader::Stop+0x84 (5667ddc1)
    5667ddbf 8bc8            mov     ecx,eax
    5667ddc1 53              push    ebx
    5667ddc2 8d85e4fbffff    lea     eax,[ebp-41Ch]
    5667ddc8 50              push    eax
    5667ddc9 51              push    ecx
    5667ddca 8d85f0fbffff    lea     eax,[ebp-410h]
    5667ddd0 50              push    eax
    5667ddd1 ff762c          push    dword ptr [esi+2Ch]
    5667ddd4 ff1590218056    call    dword ptr [vsdebug!_imp__ReadFile (56802190)]
    5667ddda 85c0            test    eax,eax
    5667dddc 0f845a80f9ff    je      vsdebug!CReader::Stop+0x117 (56615e3c)
    5667dde2 8b85e4fbffff    mov     eax,dword ptr [ebp-41Ch]
    5667dde8 85c0            test    eax,eax
    5667ddea 0f844c80f9ff    je      vsdebug!CReader::Stop+0x117 (56615e3c)
    5667ddf0 b900040000      mov     ecx,400h
    5667ddf5 3bc1            cmp     eax,ecx
    5667ddf7 736c            jae     vsdebug!CReader::Stop+0x125 (5667de65)
    5667ddf9 889c05f0fbffff  mov     byte ptr [ebp+eax-410h],bl
    5667de00 40              inc     eax
    5667de01 3bc1            cmp     eax,ecx
    5667de03 7360            jae     vsdebug!CReader::Stop+0x125 (5667de65)
    5667de05 889c05f0fbffff  mov     byte ptr [ebp+eax-410h],bl
    5667de0c 389df0fbffff    cmp     byte ptr [ebp-410h],bl
    5667de12 0f842480f9ff    je      vsdebug!CReader::Stop+0x117 (56615e3c)
    5667de18 899decfbffff    mov     dword ptr [ebp-414h],ebx
    5667de1e c745fc01000000  mov     dword ptr [ebp-4],1
    5667de25 8d85f0fbffff    lea     eax,[ebp-410h]
    5667de2b 53              push    ebx
    5667de2c 53              push    ebx
    5667de2d 50              push    eax
    5667de2e 8d8decfbffff    lea     ecx,[ebp-414h]
    5667de34 e82a960200      call    vsdebug!CVSUnicodeString::CopyString (566a7463)
    5667de39 c745fc02000000  mov     dword ptr [ebp-4],2
    5667de40 8b4e30          mov     ecx,dword ptr [esi+30h]
    5667de43 6aff            push    0FFFFFFFFh
    5667de45 ffb5ecfbffff    push    dword ptr [ebp-414h]
    5667de4b e87952f6ff      call    vsdebug!CMinimalStreamEx::AddStringW (565e30c9)
    5667de50 834dfcff        or      dword ptr [ebp-4],0FFFFFFFFh
    5667de54 8d8decfbffff    lea     ecx,[ebp-414h]
    5667de5a 53              push    ebx
    5667de5b e89838f5ff      call    vsdebug!CVSVoidPointer::Assign (565d16f8)
    5667de60 e9d77ff9ff      jmp     vsdebug!CReader::Stop+0x117 (56615e3c)
    5667de65 e8c4fb0d00      call    vsdebug!__report_rangecheckfailure (5675da2e)
    5667de6a cc              int     3
    5667de6b b81a7e5d56      mov     eax,offset vsdebug!ATL::CAtlMap<unsigned long,CScriptNode *,ATL::CElementTraits<unsigned long>,ATL::CElementTraits<CScriptNode *> >::~CAtlMap<unsigned long,CScriptNode *,ATL::CElementTraits<unsigned long>,ATL::CElementTraits<CScriptNode *> >+0x15 (565d7e1a)
    5667de70 c3              ret
    5667de71 b84c8e5d56      mov     eax,offset vsdebug!ATL::CAtlMap<unsigned long,ATL::CComPtr<IVsHierarchyEvents>,ATL::CElementTraits<unsigned long>,ATL::CElementTraits<ATL::CComPtr<IVsHierarchyEvents> > >::~CAtlMap<unsigned long,ATL::CComPtr<IVsHierarchyEvents>,ATL::CElementTraits<unsigned long>,ATL::CElementTraits<ATL::CComPtr<IVsHierarchyEvents> > >+0x15 (565d8e4c)
    5667de76 c3              ret
    5667de77 6857000780      push    80070057h
    5667de7c e8df0af6ff      call    vsdebug!treegrid::IGridView::CleanupItems (565de960)
**    0:048> u 5661a822  ** Jump here
    vsdebug!ReaderThreadStart+0xd4:
    5661a822 395e28          cmp     dword ptr [esi+28h],ebx
    5661a825 74d0            je      vsdebug!ReaderThreadStart+0x26 (5661a7f7)
    5661a827 ff7624          push    dword ptr [esi+24h]
    5661a82a ff157c228056    call    dword ptr [vsdebug!_imp__SetEvent (5680227c)]
    5661a830 53              push    ebx
**    5661a831 ff1508218056    call    dword ptr [vsdebug!_imp__ExitThread (56802108)]  ** Stop reading

That is the whole magic around that. The reader simply stops reading and you your application will block when the sender buffer is full. No magic involved. It is all depends on the behaviour of the reader.

First part of your answer can be found in comments and was there already. AND: If you just send "\0" it will not block... So please do not guess. — Roman Byshko, Mar 28 '14 at 22:35
There is no guess. I have updated the answer to show it is solely dependant on how the reader behaves. — Alois Kraus, Mar 29 '14 at 08:23
In my WinForms app, adding the line Console.WriteLine("\0"); will reliably cause subsequent calls to Console.Writeline to do nothing. Sounds like a bug to me. — Tom Bushell, Jun 12 '14 at 22:46

score 0 · Answer 3 · edited May 23 '17 at 11:55

0

Because WPF has no unamanged handle to a Console window. I am unable to see the implementation of the Write method, but you can see on most public properties of static Console class return an IO Error with "Message = "The handle is invalid.\r\n".

If you want to display a console window, in a WPF application you need to execute code in the kernel32.dll unmanaged library.

See No output to console from a WPF application?

edited May 23 '17 at 11:55

Community

1
1

answered Mar 27 '14 at 14:35

Michal Ciechan

13,492
11
76
118

It does have a unmanged handle, replace the 1024 nulls with the word "Test" then look at the `Output` window in visual studio, you will see "Test" printed there. – Scott Chamberlain Mar 27 '14 at 14:38
@ScottChamberlain I still get a large number of System.IO.IIOException with the No Handle Message for most public properties of console class, before or after any Console.Write happens. But if I run ConsoleManager.Show(), Console gets handles and properties are filled with data. And then can display 1024 nulls as normal. I guessing Console.Write tried to marshall code to an unmanaged thread which tried to access the Console window, but as it does not exist, it hangs. Hard to say why without seeing implementation of Console.Write – Michal Ciechan Mar 27 '14 at 14:43
Where you looking at `Console.Out` which is a [`TextWriter`](http://msdn.microsoft.com/en-us/library/system.io.textwriter.aspx) or where you looking at `Console.OpenStandardOutput();` which is the underlying stream `Console.Out` uses. Also you can see the implementation of `Console.Write` by using the [Microsoft Reference Source](http://referencesource.microsoft.com/mscorlib/system/console.cs.html#7f651102bd2b5927) and even step in to the .NET source code while debugging if you [set up visual studio correctly](http://referencesource.microsoft.com/setup.html) (that is how I posted my answer) – Scott Chamberlain Mar 27 '14 at 15:24

Console.Write() will hang in WPF, but works in Console application

3 Answers3