none
pool frees RRS feed

  • Question

  • Hello,

    i'm seeing that there are some cases where a single pool allocation is freed numerous times sequentially. (i've seen something as dramatic as > 100 frees in a row on a single pool block.) Supposedly, certain bugchecks are supposed to catch when this type of error occurs. however, i've noticed the bugchecks only catch the issue if the pool has been allocated first. For instance, if a pool was allocated, and then freed twice, one of the bugchecks will initiate. However, it seems that if drivers continue to free a pool allocation that has never been allocated, no bugchecks will catch the error. Also, such behavior would indicate the drivers are at fault right? If a driver is freeing a pool that was never allocated, such behavior should be considered an error right?

    Thanks!

    p.s. i also asked this question in the windows and windows phone apps, windows phone development > developing for windows phone forum since i wasn't sure which was the appropriate forum.
    Tuesday, August 5, 2014 6:51 PM

Answers

  • Turn on Driver Verifier with the Special Pool Checking and these should be caught.  How are you determining that this is happening. to begin with?


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com

    Tuesday, August 5, 2014 7:09 PM
  • just because the error isn't caught at runtime does not mean it isn't an error. you need to follow the documented behavior, which in this case is

    a) you only free pool you allocated

    b) you only free it once


    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    • Marked as answer by rasberrytoast Tuesday, August 5, 2014 11:34 PM
    Tuesday, August 5, 2014 10:14 PM

All replies

  • Hello,

    i'm seeing that there are some cases where a single pool allocation is freed numerous times sequentially. (i've seen something as dramatic as > 100 frees in a row on a single pool block.) Supposedly, certain bugchecks are supposed to catch when this type of error occurs. however, i've noticed the bugchecks only catch the issue if the pool has been allocated first. For instance, if a pool was allocated, and then freed twice, one of the bugchecks will initiate. However, it seems that if drivers continue to free a pool allocation that has never been allocated, no bugchecks will catch the error. Also, such behavior would indicate the drivers are at fault right? If a driver is freeing a pool that was never allocated, such behavior should be considered an error right?

    Thanks!

    p.s. i also asked this question in the windows desktop development, windows hardware development > windows hardware wdk and driver development forum since i wasn't sure what the appropriate category was. 

    Tuesday, August 5, 2014 6:44 PM
  • Turn on Driver Verifier with the Special Pool Checking and these should be caught.  How are you determining that this is happening. to begin with?


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com

    Tuesday, August 5, 2014 7:09 PM
  • special pool checking is enabled, but it doesn't seem to be catching this error. For a c1 bugcheck, the error seems to occur outside of the current page so i can't tell who wrote to the incorrect section.

    i found this behavior by taking an indirect approach in debugging. i wrote a script to sort the !verifier 0x80 output and see if any driver had freed a pool block multiple times in a row. It seems that the multiple frees always happen on a pool block that has no previous history of an allocation as far as the !verifier 0x80 buffer can remember. What do you think?

    Also, for the !poolused command, it shows usage as far as allocated and used. Is there an option to make it display freed as well? It would be convenient to check if the number of frees is ever greater than the number of allocations.

    Thank you!

    1: kd> !pool b1568fe0
    Pool page b1568fe0 region is Special pool
    Address b1568000 does not belong to any pool
    Data start b1568fe0, block size 0x1c
    Pattern mismatch at b1568c68: expected 0x91, actual 0x1f
    Block b1568fe0 is a corrupted special pool allocation

    b1568c58 91 91 91 91 91 91 91 91 91 91 91 91 91 91 91 91 1f fc  ..................
    b1568c6a 03 c0 00 00 45 00 91 91 91 91 91 91 91 91 91 91 91 91  ....E.............
    b1568c7c 91 91 91 91 91 91 91 91 91 91 91 91 91 91 91 91 91 91  ..................
    b1568c8e 91 91 91 91 91 91 91 91 91 91 91 91 91 91 91 91 91 91  ..................

    Tuesday, August 5, 2014 8:29 PM
  • i should mention that the script results were checked for accuracy by doing a !verifier 0x80 <pool block num at fault> and seeing that the same pool block had in fact been freed numerous times sequentially.
    Tuesday, August 5, 2014 9:05 PM
  • just because the error isn't caught at runtime does not mean it isn't an error. you need to follow the documented behavior, which in this case is

    a) you only free pool you allocated

    b) you only free it once


    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    • Marked as answer by rasberrytoast Tuesday, August 5, 2014 11:34 PM
    Tuesday, August 5, 2014 10:14 PM
  • thanks, the behavior was more common than would be expected so i just wanted to check this. 
    Tuesday, August 5, 2014 11:34 PM