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/
AllocateCommonBuffer fails after reboot on machines with RAM > 128GB
sandilyabhagi
Member Posts: 4
Our driver uses AllocateCommonBuffer() in HwInitialize() function.
When the driver is loaded for the first time, the driver installation is successful and allocates and AllocateCommonBuffer() is also successful.
But, after reboot the AllocateCommonBuffer() function fails to allocate memory.
This is observed on machines with RAM > 138 GB
Used msconfig->boot options to deduce. If the RAM is <= 138GB then the AllocateCommonBuffer() is successful and for RAM > 138GB it fails.
The memory address obtained from AllocateCommonBuffer() are as follows,
First Installation
First allocation : PA:0x7d011000, VA: FFFF8C007F1AC000
Last allocation : PA:0x485e1000, VA: FFFF8C0087AC4000
After Reboot,
First allocation : PA:0x7cfe7000, VA: FFFFCC01D3040000
Last allocation : PA: ** 0x1a5000** , VA: FFFFCC01DEC6B000 (Before failure)
We are allocating chunks of 20K buffers
After reboot, there is huge address difference between the first and last allocation.
Any suggestions to debug and check where are we doing wrong ?
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 | 7 February 2022 | Live, Online |
| Kernel Debugging | 21 March 2022 | Live, Online |
| Developing Minifilters | 23 May 2022 | Live, Online |
| Writing WDF Drivers | 12 September 2022 | Live, Online |
Comments
it in 'chunks' instead of one allocation?
Mark Roddy
In total the whole driver allocated 80MB and in the failing case it fails around after 55MB
These are allocation for each individual entities/queues.
make one 55MB allocation and divide that up on my own.
Mark Roddy
he means 80MB of course
The advantage of multiple allocations would be if you are planning to free some of them sooner than others. Then some other component might be able to make use of that memory once you are finished with it. If they all have the same lifespan in your driver, then there is no value in making many small allocations - only the system overhead of keeping track of them individually
you should expect that the virtual addresses that your allocations are assigned will very dramatically each time your driver runs. That's a feature by design in Windows to make it harder to exploit certain kinds of bugs
Thank you @Mark_Roddy , we will consider implementing as suggested. It's an old driver and I'm not quite sure about the design of allocating smaller chunks. I am only guessing it to support on machines where contiguous allocations for higher memory fails. But, I will try your suggestion if it works in wider testing appears to be the only visible way out at the moment.
Thank you @MBond2, there are few allocation which are freed but majority of them are freed in ScsiStopAdapter. So, I think leaving the few rest of the memory can be allocated in single block.
But, just curious why would AllocateCommonBuffer() fails when there is more than sufficient memory is available ?