PeekNamedPipe unexpected behaviour (bug?)

Question

PeekNamedPipe unexpected behaviour (bug?)

x33 1

I was recently scratching my head for some time while i was working with named pipes.

So in my setup, i had the "reader" and the "writer" ends of a pipe created in "PIPE_TYPE_MESSAGE | PIPE_READMODE_BYTE" mode. The writer called twice the WriteFile api to send some data to the reader. After the second call to WriteFile by the writer, the reader used the PeekNamedPipe to peek at the data written by the writer. To my surprise, i was always getting only the data of the first WriteFile call even though the peek length included both writes.

After reading more carefully the documentation, i noticed the following paragraph in the remarks: "The data is read in the mode specified with CreateNamedPipe. For example, create a pipe with PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE. If you change the mode to PIPE_READMODE_BYTE with SetNamedPipeHandleState, ReadFile will read in byte mode, but PeekNamedPipe will continue to read in message mode."

So this appears to be related with my problem, it looks like the peek operation tries to read the data in message mode. The only issue is that i had the pipe opened with "PIPE_TYPE_MESSAGE | PIPE_READMODE_BYTE" which based on the documentation, should have allowed the peek operation to read all the data of the pipe.

Am i missing something? Is this a bug of the implementation, documentation or do i have a flaw in my thinking process?

I am also curious to hear the logic behind this design decision of peek operation, as it doesn't look like it makes much sense.

It is noted that i was using Windows 21H1, but the same behaviour was observed in all the versions i have experimented with.

Thanks

0 comments

2 answers

Your answer

Answer 1

Xiaopo Yang - MSFT 12,736 Microsoft External Staff

Hello, we have opened a feedback at https://aka.ms/AAdn3v1 about PeekNamedPipe unexpected behaviour. You can track the feedback progress.

x33 1 Reputation point

2021-08-27T12:36:48.44+00:00

thanks, i wasn't aware of that platform
btw, when i open the link i get the error "your account doesn't have permissions to access this feedback"

Answer 2

Xiaopo Yang - MSFT 12,736 Microsoft External Staff

I have tested the condition based on The Pipe Sample. After WriteFile twice, There is no problem on ReadFile, but on PeekNamedPipe although lpTotalBytesAvail of PeekNamedPipe indicates there is more data.
Edit: It seems that PeekNamedPipe is related to PIPE_TYPE_MESSAGE and PIPE_TYPE_BYTE.

x33 1 Reputation point

2021-08-23T12:51:49.407+00:00

thanks for looking into this. So the actual peek implementation depends on the type mode to decide whether it should treat the pipe as a stream of bytes or messages. (you are also correct that ReadFile depends on the read mode)

Nevertheless, by reading the documentation of PeekNamedPipe, i would expect PeekNamedPipe to use the read mode specified in the CreateNamedPipe and continue using that even if the read mode of the pipe changes with SetNamedPipeHandleState.

I am not sure if the current implementation is the one intented, but if it is, then it might be useful to reword the documentation of the peek operation to better reflect its operations: "The way data is read depends on the type mode specified with CreateNamedPipe. For example, create a pipe in PIPE_TYPE_MESSAGE mode. Regardless of the read mode of the current end of the pipe, PeekNamedPipe will always read in message mode. Nevertheless, ReadFile will read in either byte mode or message mode depending on the current read mode of the pipe which could be changed with SetNamedPipeHandleState."

i am not sure if i managed to make myself a bit more clear.
RLWA32 52,441 Reputation points

2021-08-23T13:16:56.873+00:00

Keep in mind that the read mode specified in the call to CreateNamedPipe is applicable to the handle returned to the pipe server. The handle returned to the pipe client always has an initial read mode of PIPE_READMODE_BYTE. Perhaps that's another reason why the type mode of the pipe determines the behavior of PeekNamedPipe.
Another way to look at it would be that the behavior of PeekNamedPipe always corresponds to the write mode of the pipe.
x33 1 Reputation point

2021-08-23T14:18:26.557+00:00

good observation, but what's really important here is to answer the question:
Is the behavior described here of the PeekNamedPipe the expected one?

If yes then I think the documentation of the PeekNamedPipe has to be reworded because as is it might be confusing. (so it would be documentation issue)

If not, then the implementation of PeekNamedPipe has to be fixed (so it would be implementation bug)

In either case i would be curious to know some of the reasons that driven this design decision for peek.
RLWA32 52,441 Reputation points

2021-08-23T14:23:49.263+00:00

I don't work for Microsoft so I can't give you a definitive answer. However, all things considered, my feeling is that it's just some badly worded and ambiguous documentation.

Share via

PeekNamedPipe unexpected behaviour (bug?)

2 answers

Your answer