Debugging Stop 0xC2 - BAD_POOL_CALLER

Generally, a Stop 0xC2, indicates that a thread was making a bad pool request, this request is dependent upon the parameters. In this example (currently still be debugged), the parameters indicated that the thread was attempting to free a region of pool which was already freed.

The usual causes are either device drivers or memory.

Firstly, I checked for any pool corruption with the !pooval extension with the address of the pool block from parameter 4.

There didn't seem to be any possible pool corruption within the page of non-paged pool which was good, thereby I believed memory isn't likely to be an issue as of yet.

Using the !pool extension, I was able to investigate further if there was any possible pool corruption, the right column indicates the pool tags and the left column indicates the if the pool was free or allocated. The Previous Sizes all matched, which lead to me believing that this pool page wasn't corrupted. 

The * next to the Pool Tag Even indicates that the debugger found the address matching the address used with the !pool extension. The Protected is a check to ensure that the allocation being freed is the intentional one. 

From the other information I could gather, the ExFreePoolWithTag routine was present, which then indicates that a pool address was being freed, since the Even tag was the pool tag being freed and was Protected. I believe that the Even tag wasn't supposed to be freed, hence the bugcheck.

The Even tag, from some searching, appears to be linked to Event Viewer.

References:

http://msmvps.com/blogs/windrvr/archive/2007/06/15/tag-you-re-it.aspx

http://analyze-v.com/?p=734