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

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

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:

Combining multiple types of drivers

scotts3l33tscotts3l33t Member Posts: 6

Hello all, new here with a little question. First the scenario:
1. Am have recently been hired to maintain and expand a suite of drivers.
2. The structure of the driver is this: 1 CDO driver that handles the user mode communication and process starts and registry filtering. 1 file system minifilter driver for file systems. 1 Ndis driver for filtering network. and 1 kernel dll to share memory between all three.
3. I am thinking of rewriting all of them, or at least doing any consolidation work I can.

The question: Is it possible to roll all three actual drivers into one driver? I know it is completely possible to do file system, registry, and process notification all in one driver as I have done this before, but can you fit the network stuff in too?


  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 7,886

    I think your plan to consolidate these drivers is likely to be a mistake. It sounds to me, without having all the details you do of course, that the suite of drivers you inherited was pretty well designed.

    Separate drivers, especially when the drivers use very different driver models, are simpler and easier to maintain in the long run. It makes updates easier. It keeps separate functionality separate. Why combine things into a tangled mess?


    Peter Viscarola

  • scotts3l33tscotts3l33t Member Posts: 6
    edited August 2019
    Thanks for the reply. The reason is to do away with the shared memory dll. My gut is to separate the drivers into three separate drivers and create a unified user mode communication layer. Other developers are leaning to the unification, so that’s why I asked that way. The drivers are old and were not written the best way originally (e.g. using extensive c++ before it was supported and similar issues). I am trying to gather all possible remedies and doing research so that I can make a good recommendation on what to do going forward. If we come to the decision not to change the design, it will still require significant refactoring to implement the new functionality i am being requested to implement.
    Also, because the reliance on the shared memory, all drivers are version locked anyway.
  • NtDev_GeekNtDev_Geek Member - All Emails Posts: 111

    Are you looking something like this...

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!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA