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: https://www.osr.com/osr-learning-library/
Spin Lock
Howdy, Stranger!
| 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! | ||
| Internals & Software Drivers | 19-23 June 2023 | Live, Online |
| Writing WDF Drivers | 10-14 July 2023 | Live, Online |
| Kernel Debugging | 16-20 October 2023 | Live, Online |
| Developing Minifilters | 13-17 November 2023 | Live, Online |
Comments
you should queue multiple IRPs at the same time. after one is completed, data that arrives will have another one ready
thank You. Mr. MBond2. I have done it. But I wanted to send with one Irp. Because for splitting to many NBs and sending every NB separatory will decrease the speed.
There may be a limit on the total length of the entire payload. I mean all NBs from all NBLs. Perhaps this is a property of the network card. How can I request a card
yes, you can find out the MTU on the interface and make sure your buffer is larger than that. For most hardware, the largest jumbo frame is around 9,000 bytes
but what I mean is not that you should split the data for a single packet into multiple buffers, but that you should use OVERLAPPED IO and send multiple buffers to the driver when there is no data. Then as data arrives, fill the first buffer and send it back to UM. After the UM code runs, send another buffer back to the driver. the point is that because the speed at which the KM code can detect packets, and the speed at which UM code can process them mismatch, you want a queue of pending buffers to even out spikes
Thank You.
Great thank you. Mr Mbond. But what I'm trying to tell you is that everything you say I've already released in the last 6 months. Please help me solve a more difficult problem. I want to free the buffer assigned to Irp->mdlAddress when the total length of the entire network payload from the NDISFilterDriver send path is greater than this buffer, allocate a new one with enough length and attach it to the Irp instead of the old buffer.
May be to allocate extra buffer and add it to the Irp->mdlAddress as a new PFN. And provide access to it from user mode.
That buffer does not belong to you. You can create a NEW buffer to send down below you, but you'll need to restore the original during completion.
You'll copy the data into a pending request that the UM sent down to you earlier.
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.
Well, Mr. Tim_Roberts. But UM sent me the buffer described by IRP->MDLAddress, which did not have enough space for the entire payload. Sometimes I need to increase this space.
Somewhere I red that it is possible to add new mdl to the already existing one(to build mdl chain). But I cant imagine, how I/O manager will convert it to user mode buffer, when it returns to user.
Yes. I can split to many NBs and return them via the many IRPs but it is not very good solution for me.
Well, that's simply impossible. Surely that must be obvious. The UM app allocated that space from its heap and has the address stored in its own pointers. You can't arbitrarily extend that space, because there is almost certainly no room in his heap, and you can't allocate your own space at a new address, because you don't know where they might have stored the pointer. The IRP is merely telling you where the buffer is. Changes to the IRP are not reflected back to UM.
If there's not enough room, you need to fail the IRP and have the app send you a larger buffer. There are NTSTATUS codes specifically for this condition.
Yes, you can allocate a new MDL and replace the one in the IRP, but that's only for requests that are travelling DOWN the stack towards the hardware. In that case, YOU become the client, so you are in control. You do not have the option of modifying the request on the way back up. No one is looking at that.
Tim Roberts, [email protected]
Providenza & Boekelheide, Inc.
Thank you Mr. Tim_Roberts. I now will split it into many NBs and return from driver with multiple IRPs. Thanks for your many helpful tips.