Subodh,
Early on, I asked if psched was part of the stack and if this still
happened if it was removed. Without going into all the details, there
was a slow corruption issue and ultimately, an IRP passed from a
user-space application to a protocol would have its AuxiliaryBuffer hit
with a value. When that happens, the IO Manager will try to free that
buffer when the IRP completes. Since that isn’t a valid address, the
net result is a bad pool caller trying to do a free.
Bryan S. Burgin
xxxxx@microsoft.com
This posting is provided “AS IS” with no warranties, and confers no
rights.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mats Petersson
Sent: Tuesday, November 25, 2003 6:28 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] RE: BAD_POOL_CALLER on Windows XP
Hi Subodh,
It still looks very much like some driver in your system is corrupting
the
pool. Of course, the most likely candidate is your own driver, but it
could
be all sorts of other things too.
The access in CcGetVirtualAddress is a NULL access, which seems to me
like
something either probably passed in a NULL pointer, or something was
supposed to be a pointer that had been overwritten with zero’s.
I’m not an expert on file systems, and my guess is that it’s actually
not
got anything to do with file systems as such, just the fact that
whatever
driver in your system is corrupting the pool, and the file system is
using
the same pool, which means that something in the file system will crash
at
some random point. When, how and where, depends on what is being
clobbered,
and how much it’s being run. Since the file system is very active during
the
boot phase, this is the most likely to go wrong at that time.
Mark just sent an e-mail reminding you to use driver verifier. I’d add a
strong “Seconded” on that. It will catch whatever driver is at fault.
Just boot the system without your driver (safe-mode for example), and
run
“verifier”. Use custom settings to set the “Special Pool” and “Pool
checking”, and whatever other options you think might be useful. It’s
probably a good idea to leave the fault injection one alone at the
moment,
as that is for when you THINK your driver will be able to handle
“everything”, and not for troubleshooting as such.
Driver verifier will catch anything writing outside it’s own memory
block as
long as it’s a small block (i.e. writing outside anything larger than
4KB
may not get caught). If you’re frequently dealing with “large”
allocations,
add some code to protect those memory blocks by adding a guardband at
the
beginning and end and/or check very carefully with “assert()” in the
code
that the indexes/pointers are in range. Ideally, you’d add the “guard
band”
in the your own memory allocation wrapper, somehting like:
void * MyExAllocatePool(size_t size, char *fname, int lineno)
{
// May need to round to even longwords or some such.
size_t newsize = size + guardbandSize * 2 + sizeof size_t;
void *p;
p = ExAllocatePool(newSize);
if (p == NULL)
{
ASSERTMSG(FALSE, “Memory allocation failed at %s:%d\n”,
fname, lineno);
return NULL;
}
(size_t *)p = size;
p = (void *)((char *)p + sizeof size_t);
memset(p, 0xBA, guardBandSize);
p = (void *)((char *)p + guardBandSize);
memset((char *)p + size, 0xAB, guardBandSize);
return p;
}
void MyExFreePool(void *p, char *fname, int lineno)
{
char *pp;
size_t size;
size_t i;
pp = (char *)p;
pp -= (guardBandSize + sizeof size_t);
size = *(size_t *)pp;
pp += sizeof size_t;
for(i = 0; i < guardBandSize; i++)
{
if (pp[i] != 0xba)
{
ASSERTMSG(FALSE, “Memory corruption when freeing
block %p(%s:%d), byte %d overwritten with %d”,
p, fname, lineno, i, pp[i]);
}
if (pp[i + size + guardbandsize + sizeof size_t] !=
0xab)
{
ASSERTMSG(FALSE, “Memory corruption when freeing
block %p(%s:%d), byte %d overwritten with %d”,
p, fname, lineno, i, pp[i + size +
guardbandsize + sizeof size_t]);
}
}
ExFreePool(pp);
}
#define ExAllocatePool(x) MyExAllocatePool(x, FILE, LINE)
#deifne ExFreePool(x) MyExFreePool(x, FILE, LINE)
Of course, if you use a different memory allocation routine, you need to
replace the names above, and I haven’t event thought about compiling the
above code.
Hope this helps.
Memory corruption can be VERY hard to catch, and trying to comment out
bits
of code to catch it, or adding debug printouts is probably a relatively
difficult method. Using driver verifier and “protective” methods is the
only
workable way. Trying to find it with “simple” debug methods is very
difficult.
–
Mats
-----Original Message-----
From: Subodh Gupta [mailto:xxxxx@softhome.net]
Sent: Tuesday, November 25, 2003 1:48 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] RE: BAD_POOL_CALLER on Windows XP
Hi mats,
thanks for your valuable suggestions,I just have one Sr.sys
on the system
and that is the system restore driver. As a short cut i first tried to
disable the System Restore Feature of XP, and commented the ExFreePool
calls in my driver just for testing it.By doing this i am
able to get rid
of the Bug Check when AutoChk.exe is running.But this brings
in a new bug
again from file system which is DRIVER_IRQL_NOT_LESS_OR_EQUAL
when system
is showing welcome screen, please take a look at the stack.
it shows that
a call to nt!CcGetVirtualAddress generated the bug check.I am
working on
NOP method and buffer checking but for the time being this
results i have
in hand for posting.
kd> !analyze -v
**************************************************************
*****************
*
*
* Bugcheck Analysis
*
*
*
**************************************************************
*****************
IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pagable (or completely
invalid) address at
an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 00000000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 804f03fb, address which referenced memory
Debugging Details:
READ_ADDRESS: 00000000
CURRENT_IRQL: 2
FAULTING_IP:
nt!CcGetVirtualAddress+7b
804f03fb 8b3c81 mov edi,[ecx+eax*4]
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xA
LAST_CONTROL_TRANSFER: from 805808d9 to 804f03fb
TRAP_FRAME: fc171960 – (.trap fffffffffc171960)
ErrCode = 00000000
eax=00000000 ebx=810c37a8 ecx=00000000 edx=00000000 esi=00000000
edi=810c3878
eip=804f03fb esp=fc1719d4 ebp=fc1719f4 iopl=0 nv up
ei pl zr na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00000246
nt!CcGetVirtualAddress+7b:
804f03fb 8b3c81 mov edi,[ecx+eax*4]
Resetting default context
STACK_TEXT:
fc1719f4 805808d9 000c37a8 00000000 00000000
nt!CcGetVirtualAddress+0x7b
fc171a5c fc3f6ba3 811c8028 fc171a88 00001000 nt!CcMapData+0x8b
fc171a90 fc3f66a9 811f4008 e15b4840 00000000
Fastfat!FatReadDirectoryFile+0x90
fc171b60 fc3f7317 811f4008 e15b4840 e18be608
Fastfat!FatLocateDirent+0xf0
fc171c98 fc3f6285 811f4008 8117a008 fc3f7706
Fastfat!FatQueryDirectory+0x4ab
fc171ca4 fc3f7706 811f4008 8117a008 811cb230
Fastfat!FatCommonDirectoryControl+0x3d
fc171ce8 804eca36 81250be8 8117a008 806c9190
Fastfat!FatFsdDirectoryControl+0x65
fc171cf8 8058b076 fc171d64 00f0f894 805951e4 nt!IopfCallDriver+0x31
fc171d0c 8059523f 81250be8 8117a008 810e5c40
nt!IopSynchronousServiceTail+0x5e
fc171d30 804da140 00000488 00000000 00000000
nt!NtQueryDirectoryFile+0x5b
fc171d30 7ffe0304 00000488 00000000 00000000 nt!KiSystemService+0xc4
00f0f85c 77f75fba 77e7eb29 00000488 00000000
SharedUserData!SystemCallStub+0x4
00f0f860 77e7eb29 00000488 00000000 00000000
ntdll!ZwQueryDirectoryFile+0xc
WARNING: Stack unwind information not available. Following
frames may be
wrong.
00f0fb54 77e7eb75 00528260 00000488 00f0fb8c
kernel32!FindFirstFileExW+0x1b8
00f0fea4 00000000 00000000 00000000 00000484
kernel32!FindFirstFileW+0x13
FOLLOWUP_IP:
nt!CcGetVirtualAddress+7b
804f03fb 8b3c81 mov edi,[ecx+eax*4]
FOLLOWUP_NAME: MachineOwner
SYMBOL_NAME: nt!CcGetVirtualAddress+7b
MODULE_NAME: nt
IMAGE_NAME: ntoskrnl.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 3d6de35c
STACK_COMMAND: .trap fffffffffc171960 ; kb
BUCKET_ID: 0xA_nt!CcGetVirtualAddress+7b
Followup: MachineOwner
kd> .trap fffffffffc171960
ErrCode = 00000000
eax=00000000 ebx=810c37a8 ecx=00000000 edx=00000000 esi=00000000
edi=810c3878
eip=804f03fb esp=fc1719d4 ebp=fc1719f4 iopl=0 nv up
ei pl zr na po
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00000246
nt!CcGetVirtualAddress+7b:
804f03fb 8b3c81 mov edi,[ecx+eax*4]
kd> kb
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr Args to Child
fc1719f4 805808d9 000c37a8 00000000 00000000
nt!CcGetVirtualAddress+0x7b
fc171a5c fc3f6ba3 811c8028 fc171a88 00001000 nt!CcMapData+0x8b
fc171a90 fc3f66a9 811f4008 e15b4840 00000000
Fastfat!FatReadDirectoryFile+0x90
fc171b60 fc3f7317 811f4008 e15b4840 e18be608
Fastfat!FatLocateDirent+0xf0
fc171c98 fc3f6285 811f4008 8117a008 fc3f7706
Fastfat!FatQueryDirectory+0x4ab
fc171ca4 fc3f7706 811f4008 8117a008 811cb230
Fastfat!FatCommonDirectoryControl+0x3d
fc171ce8 804eca36 81250be8 8117a008 806c9190
Fastfat!FatFsdDirectoryControl+0x65
fc171cf8 8058b076 fc171d64 00f0f894 805951e4 nt!IopfCallDriver+0x31
fc171d0c 8059523f 81250be8 8117a008 810e5c40
nt!IopSynchronousServiceTail+0x5e
fc171d30 804da140 00000488 00000000 00000000
nt!NtQueryDirectoryFile+0x5b
fc171d30 7ffe0304 00000488 00000000 00000000 nt!KiSystemService+0xc4
00f0f85c 77f75fba 77e7eb29 00000488 00000000
SharedUserData!SystemCallStub+0x4
00f0f860 77e7eb29 00000488 00000000 00000000
ntdll!ZwQueryDirectoryFile+0xc
WARNING: Stack unwind information not available. Following
frames may be
wrong.
00f0fb54 77e7eb75 00528260 00000488 00f0fb8c
kernel32!FindFirstFileExW+0x1b8
00f0fea4 00000000 00000000 00000000 00000484
kernel32!FindFirstFileW+0x13
Regards
Subodh
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com