Corrupted data in a list

NTDEV
1

My driver saves structures in list and later uses them. But somehow the data get corrupted. From crash dump I get the structure that was corrupted. But I can not find out when the corruption really occured. System bugcheck occures with code 0x50. How can I detect?

Thanks.

2

Quoting xxxxx@yahoo.com:

My driver saves structures in list and later uses them. But somehow the data
get corrupted. From crash dump I get the structure that was corrupted. But I
can not find out when the corruption really occured. System bugcheck occures
with code 0x50. How can I detect?

Thanks.

When I have such problems I add extra fields to the start and end of my structures or part of strucutre and write
known values into them. I then validate them whenever the strucures are touched. This normally highlights where I
am doing something stupid.

I find it easy to miscount a variable length structures and have found a debug version of ExAllocatePoolWithTag
helpful

#pragma warning (disable:28197 28160 6014)
//warning 28160 : Error annotation: Must succeed pool allocations are forbidden
//warning 28197 : Possibly leaking memory ‘p’
//warning 6014 - Leaking memory ‘p’
__checkReturn
PVOID MYAllocatePoolTag(
__in POOL_TYPE PoolType,
__in SIZE_T Size,
__in ULONG Tag)
{
PULONG p;
PULONG pTag;
p = ExAllocatePoolWithTag(PoolType, Size + 20, Tag);
if (p==NULL) return NULL;
*p = (ULONG)Size;
pTag = Add2Ptr(p, Size + 16);
*pTag = CHECK_TAG;
return Add2Ptr(p,16);
}

void MYFreePoolTag(
__in PVOID pMemPtr,
__in ULONG Tag)
{
PULONG BasePtr;
PULONG pTag;
BasePtr = Add2Ptr(pMemPtr, (ULONG_PTR)-16);
pTag = Add2Ptr(pMemPtr, *BasePtr);
if (*pTag != CHECK_TAG)
{
dprintf((“Memory Corrupted”));
dbreak;
}
ExFreePoolWithTag(BasePtr, Tag);
}
#pragma warning (default:28160 28197 6014)

3

Thanks Ian Blake.

I forgot to add that sometimes the pointer that is stored in the list itself is found to be invalid. I have no idea how it happens. If the allocation (from paged pool) was successfull, how could the list contain bad memory pointer. I find the crash weeks after the system boots.

4

That is easy enough to do if your list processing routines have a bug.

“I find the crash weeks after the system boots”

So if I have a bug that takes weeks to reproduce, in addition to the good
steps that Ian suggested I will focus on creating a reproducible test case
that takes hours not weeks to get to the failure point. In addition to
instrumenting your driver so that it self validates, running with driver
verifier turned on will add verifier’s validation tests to your own. Testng
against the checked kernel may also help.

You know what is going bad: your list, so you should be able to validate the
entire list every time it is accessed, and in addition, if that is not
sufficient, you could add background validation to this list either through
a timer or through the entry points to your driver.

On 10/31/07, xxxxx@yahoo.com wrote:
>
> Thanks Ian Blake.
>
> I forgot to add that sometimes the pointer that is stored in the list
> itself is found to be invalid. I have no idea how it happens. If the
> allocation (from paged pool) was successfull, how could the list contain bad
> memory pointer. I find the crash weeks after the system boots.
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

–
Mark Roddy