Another debugging lesson, with a simple bugcheck, which is very similar to a Stop 0xD1 or Stop 0xA. Although, I’m sure this bugcheck only occurs with the use of Driver Verifier, but I may be wrong about this.

The parameters are very similar to those of the Stop Code mentioned above, for instance we can see the memory address referenced and the type of operation being performed.

This bugcheck is caused by drivers referencing memory addresses which already been freed, and therefore addresses which they do not own. The page fault may have resulted, since the driver has referenced a page which isn’t committed to it’s address space, which in turn would mean a access violation being raised.

We can see that the page fault, resulted upon the memcpy function call, which is used to copy data between two different buffers or memory addresses.

More Documentation Here – memcopy function Windows

From viewing the call stack, we can see the klif.sys driver belongs Kaspersky, which is known to cause BSODs with Windows 7 (I’m not too sure about other operating systems).

 I’ve suggested the driver and program be removed with the Kaspersky Removal Tool.


About 0x14c

I'm currently a Software Developer. My primary interests are Mathematics, Programming and Windows Internals.
This entry was posted in Stop 0xD5. Bookmark the permalink.

2 Responses to Debugging Stop 0xD5 – DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL

  1. Hi, which tools did you use to identify the faulting application or driver? CUrrently trying to debug a similar issue..



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.