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

Home NTDEV

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: https://www.osr.com/osr-learning-library/


Opening remote device object at IRQL > PASSIVE_LEVEL

LeHackermanLeHackerman Member Posts: 12

Hey,
I'm writing a logging kernel driver that writes its logs to an attached serial port. This is going to log data coming from a minifilter and a wfp filter (I'm not sure if this possible but this is the plan). And from what I understood, callback from minifilters and wfp filters are not guaranteed to be running at IRQL = PASSIVE_LEVEL so I can't use ZwCreateFile and IoGetDeviceObjectPointer. And since I'll be building this as an export driver to be used by the filter drivers, I couldn't used the wdf functions as a KMDF driver can't be an export driver. So, how should I acquire serial port's device object to write to it ?

PS: To conform to the rules, I'm a student and this is for an academic project.

Comments

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,708

    Create a user mode service that does your logging. Your export driver creates a named device object that your service opens for asynchronous operations. The driver and service have a defined IOCTL for passing log messages from the driver to the service. The service opens the serial port, not the driver. The service issues some number of your defined logging IOCTLS and waits for completion. Your driver can complete IO requests at any IRQL <= DISPATCH_LEVEL. The service, on IOCTL completion, writes the log data from the completed IOCTL to the log device (the serial port) and issues another async IOCTL to keep the queue full on the driver side.

  • LeHackermanLeHackerman Member Posts: 12

    I get your idea and I think it would be more robust than my current architecture but I guess It's too complicated for me to implement at this level. In fact, I have already found an open source logging driver I'm going to port to implement my serial port logging which already deals with buffering and synchronisation. So, I'd prefer to figure out a way to open my serial port from this kernel driver.

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,795

    Are you thinking about opening the com port on demand within the logging function? Instead, export an Init() function from the export driver and open the com port from there the first time Init executes. Then use the com port device object as is in the Log() export function.

    d
  • LeHackermanLeHackerman Member Posts: 12

    Oh, I was under the impression all the related functions had the same IRQL constraint. Thank you for the idea I guess this is what I'm going to do then !

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,718

    Doron's advice is key -- open the file once, not every time. The first time you're called, you can always use ExQueueWorkItem to queue up a work item, which is a callback that runs at passive level.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,795
    Roll your own IO (IRP or WDFEQUEST) can be sent at dispatch to a serial port without the work item. The Zw Io APIs require passive.
    d
  • LeHackermanLeHackerman Member Posts: 12

    Yeah but can I use WDFREQUEST outside KMDF ?

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,795
    You cannot.
    d
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

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 13-17 May 2024 Live, Online
Developing Minifilters 1-5 Apr 2024 Live, Online
Internals & Software Drivers 11-15 Mar 2024 Live, Online
Writing WDF Drivers 26 Feb - 1 Mar 2024 Live, Online