Is it possible to use overlapped I/O with an anonymous pipe? CreatePipe() does not have any way of specifying FILE_FLAG_OVERLAPPED, so I assume ReadFile() will block, even if I supply an OVERLAPPED-structure.
3 Answers
Here is an implementation for an anonymous pipe function with the possibility to specify FILE_FLAG_OVERLAPPED:
/******************************************************************************\
* This is a part of the Microsoft Source Code Samples.
* Copyright 1995 - 1997 Microsoft Corporation.
* All rights reserved.
* This source code is only intended as a supplement to
* Microsoft Development Tools and/or WinHelp documentation.
* See these sources for detailed information regarding the
* Microsoft samples programs.
\******************************************************************************/
/*++
Copyright (c) 1997 Microsoft Corporation
Module Name:
pipeex.c
Abstract:
CreatePipe-like function that lets one or both handles be overlapped
Author:
Dave Hart Summer 1997
Revision History:
--*/
#include <windows.h>
#include <stdio.h>
static volatile long PipeSerialNumber;
BOOL
APIENTRY
MyCreatePipeEx(
OUT LPHANDLE lpReadPipe,
OUT LPHANDLE lpWritePipe,
IN LPSECURITY_ATTRIBUTES lpPipeAttributes,
IN DWORD nSize,
DWORD dwReadMode,
DWORD dwWriteMode
)
/*++
Routine Description:
The CreatePipeEx API is used to create an anonymous pipe I/O device.
Unlike CreatePipe FILE_FLAG_OVERLAPPED may be specified for one or
both handles.
Two handles to the device are created. One handle is opened for
reading and the other is opened for writing. These handles may be
used in subsequent calls to ReadFile and WriteFile to transmit data
through the pipe.
Arguments:
lpReadPipe - Returns a handle to the read side of the pipe. Data
may be read from the pipe by specifying this handle value in a
subsequent call to ReadFile.
lpWritePipe - Returns a handle to the write side of the pipe. Data
may be written to the pipe by specifying this handle value in a
subsequent call to WriteFile.
lpPipeAttributes - An optional parameter that may be used to specify
the attributes of the new pipe. If the parameter is not
specified, then the pipe is created without a security
descriptor, and the resulting handles are not inherited on
process creation. Otherwise, the optional security attributes
are used on the pipe, and the inherit handles flag effects both
pipe handles.
nSize - Supplies the requested buffer size for the pipe. This is
only a suggestion and is used by the operating system to
calculate an appropriate buffering mechanism. A value of zero
indicates that the system is to choose the default buffering
scheme.
Return Value:
TRUE - The operation was successful.
FALSE/NULL - The operation failed. Extended error status is available
using GetLastError.
--*/
{
HANDLE ReadPipeHandle, WritePipeHandle;
DWORD dwError;
UCHAR PipeNameBuffer[ MAX_PATH ];
//
// Only one valid OpenMode flag - FILE_FLAG_OVERLAPPED
//
if ((dwReadMode | dwWriteMode) & (~FILE_FLAG_OVERLAPPED)) {
SetLastError(ERROR_INVALID_PARAMETER);
return FALSE;
}
//
// Set the default timeout to 120 seconds
//
if (nSize == 0) {
nSize = 4096;
}
sprintf( PipeNameBuffer,
"\\\\.\\Pipe\\RemoteExeAnon.%08x.%08x",
GetCurrentProcessId(),
InterlockedIncrement(&PipeSerialNumber)
);
ReadPipeHandle = CreateNamedPipeA(
PipeNameBuffer,
PIPE_ACCESS_INBOUND | dwReadMode,
PIPE_TYPE_BYTE | PIPE_WAIT,
1, // Number of pipes
nSize, // Out buffer size
nSize, // In buffer size
120 * 1000, // Timeout in ms
lpPipeAttributes
);
if (! ReadPipeHandle) {
return FALSE;
}
WritePipeHandle = CreateFileA(
PipeNameBuffer,
GENERIC_WRITE,
0, // No sharing
lpPipeAttributes,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL | dwWriteMode,
NULL // Template file
);
if (INVALID_HANDLE_VALUE == WritePipeHandle) {
dwError = GetLastError();
CloseHandle( ReadPipeHandle );
SetLastError(dwError);
return FALSE;
}
*lpReadPipe = ReadPipeHandle;
*lpWritePipe = WritePipeHandle;
return( TRUE );
}

- 3,045
- 2
- 25
- 17
-
4Dave Hart's `MyCreatePipeEx` implementation is excellent (essentially lifted from the Windows `CreatePipe` source code itself), but you should change `PipeSerialNumber++` to `InterlockedIncrement(&PipeSerialNumber)` in said implementation to avoid race conditions in MT code. – vladr Oct 09 '12 at 18:49
-
3Wow, that method is amazingly trivial and so is genius :). In brief: it creates a pair of named pipes (read pipe with CreateNamedPipe and write pipe with WriteFile) with all Overlapped options and returns their handles. – Fr0sT Dec 22 '15 at 15:25
-
what if I do: `StringCbPrintfA(pipe_name, MAX_PATH, "\\\\.\\Pipe\\%08x.%08x", rand(), time(nullptr) );` to avoid the InterlockedIncrement? – Adham Zahran Mar 02 '20 at 13:46
-
yeah, nevermind. Tried that and rand() and time() easily collide on multiple threads. It's a psuedo-random number generator after all. – Adham Zahran Mar 03 '20 at 12:20
No. As explained here, anonymous pipes do not support asynchronous I/O. You need to use a named pipe. There's example code to do this on MSDN here and here.

- 16,635
- 9
- 57
- 81
-
From [SetNamedPipeHandleState](https://msdn.microsoft.com/en-us/library/windows/desktop/aa365787(v=vs.85).aspx) docs it looks like non-blocking IO should be supported on anonymous pipes with PIPE_NOWAIT flag. – anatoly techtonik Dec 29 '15 at 05:52
-
@anatolytechtonik unfortunately that's not the same thing as overlapped I/O. – Kenton Varda Nov 06 '16 at 02:03
-
2
first of all need understand - what is Anonymous Pipes and what, are exist difference between anonymous and Named Pipes at all.
really exist only single pipe type (implemented by npfs.sys). no any difference, except name, between named and anonymous pipes at all. both is only pipes.
so called anonymous pipes - this is special/random named pipes before win7 and true unnamed pipes begin from win7.
when msdn write that "anonymous pipe is one-way pipe" - this is lie. as any pipe it can be one-way or duplex. when msdn write that "Asynchronous (overlapped) read and write operations are not supported by anonymous pipes." - this is lie. of course pipes support asynchronous io. the name of pipe not affect this.
before win7 really unnamed pipes even not exist at all. CreatePipe
function use Win32Pipes.%08x.%08x
format for create name of "Anonymous Pipe".
static LONG PipeSerialNumber;
WCHAR name[64];
swprintf(name, L"\\Device\\NamedPipe\\Win32Pipes.%08x.%08x",
GetCurrentProcessId(), InterlockedIncrement(&PipeSerialNumber));
begin from win7 CreatePipe
use another technique (relative file open) for create pipe pair - now it really anonymous.
for example code witch create pipe pair where one pipe is asynchronous and not inheritable. and another pipe is synchronous and inheritable. both pipes is duplex (support both read and write)
ULONG CreatePipeAnonymousPair7(PHANDLE phServerPipe, PHANDLE phClientPipe)
{
HANDLE hNamedPipe;
IO_STATUS_BLOCK iosb;
static UNICODE_STRING NamedPipe = RTL_CONSTANT_STRING(L"\\Device\\NamedPipe\\");
OBJECT_ATTRIBUTES oa = { sizeof(oa), 0, const_cast<PUNICODE_STRING>(&NamedPipe), OBJ_CASE_INSENSITIVE };
NTSTATUS status;
if (0 <= (status = NtOpenFile(&hNamedPipe, SYNCHRONIZE, &oa, &iosb, FILE_SHARE_VALID_FLAGS, 0)))
{
oa.RootDirectory = hNamedPipe;
static LARGE_INTEGER timeout = { 0, MINLONG };
static UNICODE_STRING empty = {};
oa.ObjectName = ∅
if (0 <= (status = ZwCreateNamedPipeFile(phServerPipe,
FILE_READ_ATTRIBUTES|FILE_READ_DATA|
FILE_WRITE_ATTRIBUTES|FILE_WRITE_DATA|
FILE_CREATE_PIPE_INSTANCE,
&oa, &iosb, FILE_SHARE_READ|FILE_SHARE_WRITE,
FILE_CREATE, 0, FILE_PIPE_BYTE_STREAM_TYPE, FILE_PIPE_BYTE_STREAM_MODE,
FILE_PIPE_QUEUE_OPERATION, 1, 0, 0, &timeout)))
{
oa.RootDirectory = *phServerPipe;
oa.Attributes = OBJ_CASE_INSENSITIVE|OBJ_INHERIT;
if (0 > (status = NtOpenFile(phClientPipe, SYNCHRONIZE|FILE_READ_ATTRIBUTES|FILE_READ_DATA|
FILE_WRITE_ATTRIBUTES|FILE_WRITE_DATA, &oa, &iosb,
FILE_SHARE_VALID_FLAGS, FILE_SYNCHRONOUS_IO_NONALERT)))
{
NtClose(oa.RootDirectory);
}
}
NtClose(hNamedPipe);
}
return RtlNtStatusToDosError(status);
}
ULONG CreatePipeAnonymousPair(PHANDLE phServerPipe, PHANDLE phClientPipe)
{
static char flag_supported = -1;
if (flag_supported < 0)
{
ULONG dwMajorVersion, dwMinorVersion;
RtlGetNtVersionNumbers(&dwMajorVersion, &dwMinorVersion, 0);
flag_supported = _WIN32_WINNT_WIN7 <= ((dwMajorVersion << 8)| dwMinorVersion);
}
if (flag_supported)
{
return CreatePipeAnonymousPair7(phServerPipe, phClientPipe);
}
static LONG PipeSerialNumber;
WCHAR name[64];
swprintf(name, L"\\\\?\\pipe\\Win32Pipes.%08x.%08x", GetCurrentProcessId(), InterlockedIncrement(&PipeSerialNumber));
HANDLE hClient, hServer = CreateNamedPipeW(name,
PIPE_ACCESS_DUPLEX|FILE_READ_DATA|FILE_WRITE_DATA|FILE_FLAG_OVERLAPPED,
PIPE_TYPE_BYTE|PIPE_READMODE_BYTE, 1, 0, 0, 0, 0);
if (hServer != INVALID_HANDLE_VALUE)
{
static SECURITY_ATTRIBUTES sa = { sizeof(sa), 0, TRUE };
hClient = CreateFileW(name, FILE_GENERIC_READ|FILE_GENERIC_WRITE,
FILE_SHARE_READ|FILE_SHARE_WRITE, &sa, OPEN_EXISTING, 0, 0);
if (hClient != INVALID_HANDLE_VALUE)
{
*phServerPipe = hServer, *phClientPipe = hClient;
return NOERROR;
}
CloseHandle(hServer);
}
return GetLastError();
}

- 31,280
- 3
- 35
- 56
-
What's the "relative file open" technique? I couldn't find anythin in Google. Please, point to some documentation. – George Sovetov Jul 07 '20 at 19:12
-
3@GeorgeSovetov - if api take as input parameter [`OBJECT_ATTRIBUTES`](https://learn.microsoft.com/en-us/windows/win32/api/ntdef/ns-ntdef-_object_attributes) it support open or create file *relative to the RootDirectory directory*. in my concrete - first we open root folder \ on *\\Device\\NamedPipe*, then we create pipe with empty name. and than pair for it again with empty name but with `oa.RootDirectory = *phServerPipe`. this internally used by code of `CreatePipe` simply this api hardcode synchronous I/O on pipes – RbMm Jul 07 '20 at 19:34
-
Therefore, it's possible to create many pipes in the same `RootDirectory` and refer to them just by their handles? That's how anonymity is achieved? I'm a bit puzzled by the fact that multiple object have same path. As well as by the fact that some part of a name can be empty. – George Sovetov Jul 07 '20 at 20:35
-
3@GeorgeSovetov before win7 all pipes was named, simply random name like `"\\Device\\NamedPipe\\Win32Pipes.%08x.%08x"` was used. begin from win7 was designed this code (it need support from *npfs.sys* driver). so files have no name at all. trick is how create **pair**. assume that we create unnamed pipe. how "connect" to it ? we can not use name (it empty). so and special way designed inside *npfs* - use `RootDirectory` handle from object_attributes for point - to which pipe we want connect – RbMm Jul 07 '20 at 20:44
-
@RbMm Does this still work on Win11? Can you add the header includes for testing? As I understand the docs, `Ntifs.h` is deprecated and one should use `winternl.h`. However, the latter has not several definition. I would like to port your improvement to Zig for better perf (async) pipes https://github.com/ziglang/zig/blob/078037ab9b410fa13a86eabdfc30918fc83cdcf3/lib/std/child_process.zig#L1019 – Jay-Pi Mar 11 '22 at 10:05
-
1@Jay-Pi - of course this work on win11. strange question. *Ntifs.h* not depredecated, but it conflict with *windows.h* and need some tricks for include both. – RbMm Mar 11 '22 at 10:37
-
@Jay-Pi because i dont know zig, i can not comment concrete code (except you not need `SetHandleInformation` - just create it as inherit) and instead `PIPE_ACCESS_INBOUND` i be use `PIPE_ACCESS_DUPLEX` ). here look like you not include direct c header files at all. anyway ntifs.h is actual and not depredecated – RbMm Mar 11 '22 at 10:50
-
@RbMm Thanks, this explains alot why it does not work. Quite annoying that there is no #error for this kind of conditions. I found here that there is no such thing as "async pipes" https://stackoverflow.com/a/40250530/9306292, so perf will be likely lower than the Linux equivalent. – Jay-Pi Mar 11 '22 at 11:04
-
@Jay-Pi all pipes is asynchronous really. synchronous i/o is asynchronous i/o + wait in place for complete i/o – RbMm Mar 11 '22 at 11:26