Question

请阅读Scott Chamberlain的答案，了解为何与WINAPI有关。

在Visual Studio中创建一个新的WPF应用程序，并在MainWindow.xaml.cs中更改代码，如下所示。运行该应用程序。代码将在第二次调用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);
            }
        }
    }
}

现在在Visual Studio中创建一个新的控制台应用程序，并更改Program.cs中的代码，如下所示。运行该应用程序。它将成功运行，即它不会挂起。

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);
            }
        }
    }
}

问题：

为什么第二次调用Console.Write（）会在WPF应用程序中挂起？
为什么控制台应用程序中的行为有所不同？
为什么只有在字符串为\0的字符串时才会发生？（如果你做1024个空格，它可以正常工作。）

Answer 1

基本说明：它会挂起，因为在显示文本之前写入的缓冲区Console.Write正在变满，并且在传入空字符时不会耗尽WPF应用程序（{{1因为我不知道的原因。

详细说明：当您致电\0时，会创建一个Handle，将其输出并最终调用该句柄上的WriteFile。句柄的另一端需要处理写入它的数据，然后将控制权返回给调用者。 WPF和我能找到的控制台应用程序有两个主要区别：

首先，如果您使用控制台应用程序inspect the handle type获得Console.Write类型的句柄，则从WPF获取FILE_TYPE_CHAR。

FILE_TYPE_PIPE

其次，如何在接收端处理句柄是不同的。在控制台应用程序中，句柄由conhost.exe读入，在WPF中由visual studio读取。

挂起本身来自这样一个事实，即缓冲区中的空间有限，只有在句柄必须阻止新的传入请求之前才能将这么多文本排队，因此现有信息可能会耗尽。看起来控制台应用程序的句柄可以处理大量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();个字符，但WPF生成的句柄却不能。如果这种差异来自它是一种不同类型的手柄，或者来自手柄另一侧的处理器读取数据的方式不同我不知道。

希望通过Windows API调用\0获得更多经验的人可以解释两种句柄类型之间的差异，并且如果这是因为句柄类型或因为接收计划。

Answer 2

这适用于我的机器没有问题（Winodws 8.1 VS2013）。该问题与控制台应用程序无关。斯科特解释说，有一些障碍正在发生。它不在调试器

下运行时有效

作为WPF申请
作为控制台应用程序

当您尝试调试应用程序时，它将挂起。更深层次的原因是你在管道上发送\ 0。管道在阻止进一步写入之前有一个发送缓冲区（大约4 KB）。这是您在kernel32.dll中挂起的WriteFile调用所看到的。为了能够阻止必须有人想要从您的管道读取。在这种情况下，VS试图将您的stdout发送到调试器输出窗口。当没有人在监听时，管道充当空设备，永远不会阻塞。

现在回到问题为什么它适用于除\ 0之外的所有字符串？这有关如何停止从管道读取的事情。当收到\ 0作为唯一消息时，接收器可以停止从管道读取。这是进程退出的信号，不会向其写入更多数据。使用您的\ 0消息违反该隐式合同并通过管道发送更多数据，但您的客户端（VS）已停止收听您。这实际上不是一个API，但似乎是一个共同的协议。在.NET中，您可以获得异步管道读取，例如null作为最后一条消息。其他应用程序（例如VS）似乎以类似的方式处理\ 0消息并假设编写器已退出。

在这种情况下简单地关闭管道句柄是合法的ReadFile返回false。我们也可以向管道写一个0字节长度的消息。或者，您可以将1024 KB空数组写入管道。您的消息的读者可以决定这是否是停止从管道读取的信号。

更新1 由于至少有一位评论者认为逻辑不够，这是调试VS的结果。 VS确实通过ReadFile从管道读取

vsdebug!CReader::ReadPipe

检查第一个字节是否为0然后导致线程终止。如果第一个字节不为0，则将其视为unicode字符串并复制到调试器输出窗口中显示的字符串缓冲区。您可以通过以下方式轻松验证： 1000 c字符将显示在缓冲区中。然后，您可以按照与1000 0字节不同的控制流程进行操作。事实证明，相关的部分是：

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

缓冲区包含数据ebp-410，其中是我们的c字符。在此之前，存储缓冲区大小和文件句柄。

    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

这就是整个魔术。读者只是停止阅读，当发件人缓冲区已满时，您的应用程序将阻止。没有魔法涉及。这完全取决于读者的行为。

Answer 3

因为WPF没有未控制的控制台窗口句柄。我无法看到Write方法的实现，但是您可以看到静态Console类的大多数公共属性返回IO错误“Message =”句柄无效。\ r \ n“。

如果要显示控制台窗口，在WPF应用程序中需要在kernel32.dll非托管库中执行代码。

请参阅No output to console from a WPF application?

Console.Write（）将在WPF中挂起，但在Console应用程序中工作

3 个答案: