I too have noticed this problem or a variation of it. I've narrowed it down
to the change in pipe behavior in snapshot cygwin-src-20111023

Specifically in http://cygwin.com/snapshots/winsup-diffs-20111022-20111023
+	 Note that the write side of the pipe is opened as
PIPE_TYPE_MESSAGE.
+	 This *seems* to more closely mimic Linux pipe behavior and is
+	 definitely required for pty handling since fhandler_pty_master
+	 writes to the pipe in chunks, terminated by newline when CANON mode
+	 is specified.  */
     r = CreateNamedPipe (pipename, PIPE_ACCESS_INBOUND | overlapped,
-			   PIPE_TYPE_BYTE | PIPE_READMODE_BYTE, 1, psize,
+			   PIPE_TYPE_MESSAGE | PIPE_READMODE_BYTE, 1, psize,

I took a copy of the 20111023 snapshot source and compiled cygwin1.dll,
copied it to cygwin1.dll-message, patched the source back to the
PIPE_TYPE_BYTE, recompiled and copied cygwin1.dll to cygwin1.dll-byte.

Running a sample test case (attached), the output from any .NET application
that I tried (eg MSBuild.exe) caused the pipe to close and I'd get no
output. Non .NET applications like "cmd.exe /c ver" worked fine with both
dlls.

Importantly for me, if a program such as make is called where the
MSBuild.exe is called from the Makefile not only is there no output from the
MSBuild.exe command but the entire command tree resulting from the pipe
exits immediately without any error or exception.

Workarounds in the other posts to get the .NET application to even run
including piping the output to another command loses the return code from
the application or the output.

My current workaround of recompiling cygwin1.dll from source with
PIPE_TYPE_BYTE currently seems to work but it's probably going to cause
other problems further down the line as this patch included some explanatory
text stating why it is necessary.

Regards

David