0x00000019 0x0000000000000021 when using readyboost

Hi,

SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION (c1)

This indicates that the driver wrote to an invalid section of the special pool.

BugCheck C1, {fffff900ca9acf80, 1873, 80, 21}

Usage:                  

Base Address:           fffff900`00000000

End Address:            fffff960`00020000

Region Size:            00000060`00020000

VA Type:                SessionSpace

VAD Address:            0x0

Commit Charge:          0x100000001

Protection:             0x7ff8d45dff88 []

Memory Usage:           Private

No Change:              yes

6: kd> k

Child-SP          RetAddr           Call Site

fffff88009b306b8 fffff80003be4416 nt!KeBugCheckEx

fffff88009b306c0 fffff80003c0f956 nt!MmFreeSpecialPool+0x196

fffff88009b30800 fffff960000ab195 nt!ExDeferredFreePool+0xf4e

fffff88009b308b0 fffff960000ac5f3 win32k!EXLATEOBJ::vAddToCache+0x75

fffff88009b308f0 fffff960002227d4 win32k!EXLATEOBJ::bInitXlateObj+0x1d7

fffff88009b30970 fffff960000ab807 win32k!NtGdiBitBltInternal+0x994

fffff88009b30b50 fffff80003ad9e53 win32k!NtGdiBitBlt+0x5b

fffff88009b30bc0 000007fefe5425ba nt!KiSystemServiceCopyEnd+0x13

00000000020de768 fffff80003ad2210 0x000007fe`fe5425ba

fffff88009b30e10 0000000000000000 nt!KiCallUserMode

nt!MmFreeSpecialPool+0x196 is trying to free an incorrect special pool memory block that's located in session space.

6: kd> !pte fffff900ca9acf80

                                           VA fffff900ca9acf80

PXE at FFFFF6FB7DBEDF90    PPE at FFFFF6FB7DBF2018    PDE at FFFFF6FB7E4032A0    PTE at FFFFF6FC80654D60

contains 00000001C5E87863  contains 00000001C7094863  contains 000000009EC96863  contains 0000000069E53863

pfn 1c5e87    ---DA--KWEV  pfn 1c7094    ---DA--KWEV  pfn 9ec96     ---DA--KWEV  pfn 69e53     ---DA--KWEV

    [X] (0x00000000) Automatic Checks

    [X] (0x00000001) Special pool

    [ ] (0x00000002) Force IRQL checking

    [X] (0x00000008) Pool tracking

    [ ] (0x00000010) I/O verification

    [ ] (0x00000020) Deadlock detection

    [ ] (0x00000080) DMA checking

    [ ] (0x00000100) Security checks

    [ ] (0x00000800) Miscellaneous checks

Verifier is checking for special pool corruption and tracking pool, so the fact that a driver was behind the bad call tells me you have probably bad SD card or some complication. If there is a complication, it's in my opinion being caused by your card read drivers:

6: kd> lmvm o2sdgx64

start             end                 module name

fffff8800f494000 fffff8800f49e780   o2sdgx64   (deferred)             

    Image path: \SystemRoot\system32\DRIVERS\o2sdgx64.sys

    Image name: o2sdgx64.sys

    Timestamp:        Tue Aug 18 05:00:36 2009

Most card reader drivers are **** regardless of their date. Check for an update on Toshiba's site - http://support.toshiba.com/drivers

If no update available, uninstall the drivers and give it a try without them. If no avail, not much you can do I am afraid.

Regards,

Patrick

Cybot, I've asked Patrick to take a look at the file. Hopefully he will, when he logs back on.

it is 188 Mb. here is the link:

http://1drv.ms/1tapWZr

I may have misstated the natue of the dump... it was a normal dump like the others. I said what I did, because I have seen my pc freeze up during the creation of the stop error dump. in this case no freeze occurred, so a"full" dump was created. this is not a full memory dump as this option is disabled for PC's with more that 2Gb of RAM in windows 7.

I turned on verifier and setup the pool and  special pool options. I then went about my business and waited for the inevitable stop error. this time the stop error was "SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION"

the computer was able to record a full dump, would you like to look at it?

what little analysis I can do seems to indicate win32k.sys, which does not seem like the cause.

I was using the dos prompt when the stop occurred so I doubt win32k.sys is the cause, but I could be wrong

one thing I have noticed with the dumps, is what ever the computer is doing when it stops, is being indicated as the reason for the error. this is obviously not the cause. is there any thing I can do that will generate a more detailed analysis?

Yes, if it is not too large.

I turned on verifier and setup the pool and  special pool options. I then went about my business and waited for the inevitable stop error. this time the stop error was "SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION"

 the computer was able to record a full dump, would you like to look at it?

what little analysis I can do seems to indicate win32k.sys, which does not seem like the cause.

I was using the dos prompt when the stop occurred so I doubt win32k.sys is the cause, but I could be wrong

one thing I have noticed with the dumps, is what ever the computer is doing when it stops, is being indicated as the reason for the error. this is obviously not the cause. is there any thing I can do that will generate a more detailed analysis?