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/


BAD_POOL_HEADER solution tip

OSR_Community_UserOSR_Community_User Member Posts: 110,217
To whom it may help!

I was facing random crashes mostly with BAD_POOL_HEADER, but also other bug checks on one of the 32bit test machines. 64bit Windows was fine. Note the kernel driver uses only nonpaged memory.

The crashes were not really reproducible but occurred randomly only when my driver was loaded.

* First assumption was there must be a data type overrun issue. Nope couldn't find anything.
* Crash dump analyses didn't really help as it always pointed to somewhere in the Windows OS, never at our code.
* All double checks against ExAllocatePoolWithTag() and ExFreePoolWithTag() were ok.
* Driver Verifier's special pool didn't help either, no hints, worked fine (even with low resource simulation).

After reading a lot, these pages from ntdev gave me some clues:
* https://www.osronline.com/ShowThread.cfm?link=226497
* http://osronline.com/showThread.CFM?link=196572

I could finally narrow the issue down by making the crash reproducible:
* Use Windows 10 32bit in a VM with only 384 MB of memory.
* Create a restart loop: Use auto login, let it run for a minute and auto restart: Bingo after 1 . .4 restarts it always crashed.

Note: It never crashed in six month on my Windows 64 bit, 32GB production machine as it has enough memory! Make memory low and it will crash eventually!

Now I could narrow the issue down by disabling all code paths and re-enabling one by one and let it run in the VM. After a few cycles I eventually found it. It was a modification of an USB descriptor when the request was not the actual descriptor but getting the memory size of that descriptor. Here we accidentally modified > only one byte < with 16 bytes offset over the valid request buffer.

After the fix the crashes were gone.

Hope this helps somebody out there.
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!
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