Debugging Stop 0xC1 - Sloppy Bytes and Special Pool

Another memory corruption related bugcheck, but this time, it related to the use of the Special Pool option available within Driver Verifier. MSDN Blogs (NT Debugging) wrote a excellent article explaining Special Pool, and how it works which I've added to a blog post for this month, so I would highly recommend checking that article out before reading this blog post to have a full understanding of Special Pool and Slop Bytes.

 The first parameter is what we are most interested in, this the address which was attempting to freed, but was picked up by Driver Verifier due to the single bit corruption within the Slop Bytes region.

Firstly, let's examine the pool page in which the address belonged to with the !pool extension.

We can see the pool page is obviously corrupted, but let's investigate further with the !poolval extension on the suggested address provided by the dump file.

Let's look even further with the _POOL_HEADER data structure:

Okay, we can clearly see that the Previous Size for the Pool Header is wrong, it should have been 0 and the PoolType field indicates that the page was Non Paged Pool. 0 = Non-Paged Pool and 1 = Paged Pool. 

So what happened and what do Slop Bytes and Special Pool have to do with this bugcheck?

This bugcheck indicates that a driver has caused a single bit form of memory corruption within the Slop Bytes region of a pool page. The Special Pool option of Driver Verifier gives each driver it's own individual pool page, which is then split into Slop Bytes and then the driver's pool allocation. The next virtual page is a Guard Page to detect Buffer Overflows, although since the problem seems to have occurred within the Slop Bytes, then the error isn't to do with a Buffer Overflow, but a different form of memory corruption. The Slop Bytes are a repeating pattern, and if this pattern is disrupted, then the system will bugcheck with the same error which is present at the moment.