Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results


More Info on Driver Writing and Debugging

The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.

Check out The OSR Learning Library at:

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

Sysvad design decision

kaikai Member Posts: 4

I'm following this article to create a noise cancelling app:

But there is a difference that instead of using ioctl to communicate between user-mode and kernel-mode, I'm using named pipe. Everything seem to be working fine so I wonder if named pipe has any limitation or disadvantage comparing to ioctl?

Thank you.


  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,410

    Named Pipe vs IOCTL

    Well, these are very different mechanisms. An IOCTL will be far less overhead. A named pipe can be opened remotely. It is rather unusual to use a named pipe to communicate to a driver that’s local to the requestor. But... if it works... that’s not something to so quickly dismiss.


    Peter Viscarola

  • MBond2MBond2 Member Posts: 304

    I think that the performance of a local named pipe IO won't be much different than a double buffered IOCTL - but the CreateFile part will be much different as it opens the handle on both ends. also knowing which side operates as the 'server' end of the pipe and knowing when that is available from the 'client' end of the pipe are clear issues that have well defined solutions with standard IOCTLs. Be aware that using a named pipe creates a potential security vulnerability because the network redirector will expose this end point over the network. Without an appropriate security descriptor, that may allow a remote system to either block real data (i.e. calls fail with ERROR_PIPE_BUSY) or to inject synthetic possibly malicious data. The default configuration of windows firewall mitigates this to a large extent for non-AD joined machines, but many features of windows require RPC enabled

    noise cancelation is not something that should generally be performed on a system that is remote from the one actually playing the audio i would think

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Developing Minifilters 24 May 2021 Live, Online
Writing WDF Drivers 14 June 2021 Live, Online
Internals & Software Drivers 2 August 2021 Live, Online
Kernel Debugging 27 Sept 2021 Live, Online