apr_file_pipe_create_ex creates a pipe with a unique name:

file_io/win32/pipe.c :

static unsigned long id = 0;
[...]
sprintf(name, "\\\\.\\pipe\\apr-pipe-%u.%lu", getpid(), id++);

(*in)->filehand = CreateNamedPipe(name,
	dwOpenMode,
	dwPipeMode,
[...]

This code is not reliable in multilthread (id++ is not an atomic operation): two threads can increment id at the same time.
As a result, the second creation fails: CreateNamedPipe returns INVALID_HANDLE_VALUE and sets the error to ERROR_PIPE_BUSY (the first pipe was already created and it still exists in most cases).

The testcase is complicated: the request server must be under heavy load (the error was triggered around the 988000th request to a CGI script (which was checking its stdin validity)).

I think that replacing "id++" by a call to "InterlockedIncrement" fixes the issue.
InterlockedIncrement is available for all the Windows versions from Windows 95 (at least).
InterlockedIncrement is not strictly equivalent to "id++": InterlockedIncrement is equivalent to "++id", but it actually means that no pipe is created with the id 0.