Re: BAD_POOL_HEADER - BSOD
- From: Devang <devang.it@xxxxxxxxx>
- Date: Fri, 30 Jan 2009 04:55:46 -0800 (PST)
On Jan 30, 5:33 pm, <dan...@xxxxxxxxxxxxxxxx> wrote:
So that shows you have written beyond the end of the pool allocation.
Carefully check your code to see where you are writing to your ctrack
structure and see if everything is within the range of the allocation.
Of what type is ctrack anyway ? In case this is a unicode string buffer, a
common cause is that you have not (properly) initialized MaximumLength.
Routines such as RtlCopyUnicodeString unexpectedly add a trailing NULL
character regardless of whether that fits withing Length or not.
//Daniel
"Devang" <devang...@xxxxxxxxx> wrote in message
news:01901bcb-2525-40a8-911e-ef4bc4bb63a3@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Jan 30, 2:48 pm, <dan...@xxxxxxxxxxxxxxxx> wrote:
As Doron suggested, put on Driver Verifier and enable pool tracking.
//Daniel
"Devang" <devang...@xxxxxxxxx> wrote in message
news:1843d5d9-4b56-40a7-9dbb-fa05512570ab@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Jan 29, 11:18 pm, <dan...@xxxxxxxxxxxxxxxx> wrote:
Bugcheck code ? Too little info here. Offending source line 451 does not
point to ExFreePool. Of what type is iConnections ? Post output of
!analyze -v
//Daniel
"Devang" <devang...@xxxxxxxxx> wrote in message
news:aefe7676-6f78-4894-b83d-665cb088d3ea@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Hi
Following is a crash dump analysis output.
ExFreePool instruction causes driver to crash (BSOD).
Driver runs fine for a period of time, after some time it causes
crash.
How can I trace this problem?
FAULTING_SOURCE_CODE:
447: }
448:
449: ExFreePool(ctrack);
450:
451: iConnections--;452: }
453: }
454: }
455: }
456: /*
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: Plg1!TCPHashTable::tch_cleanup+e2
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: Plg1
IMAGE_NAME: Plg1.SYS
DEBUG_FLR_IMAGE_TIMESTAMP: 49818b3e
FAILURE_BUCKET_ID: 0x19_20_Plg1!TCPHashTable::tch_cleanup+e2
BUCKET_ID: 0x19_20_Plg1!TCPHashTable::tch_cleanup+e2
Followup: MachineOwner
---------
kd> !pool 8230f878
Pool page 8230f878 region is Unknown
8230f000 size: a0 previous size: 0 (Allocated) Ddk
8230f0a0 size: 28 previous size: a0 (Free) ....
8230f0c8 size: a0 previous size: 28 (Allocated) Ddk
8230f168 size: 8 previous size: a0 (Free) Ddk
8230f170 size: a0 previous size: 8 (Allocated) Process:
85cbc638
8230f210 size: 8 previous size: a0 (Free) .}5.
8230f218 size: a0 previous size: 8 (Allocated) Ddk
8230f2b8 size: 78 previous size: a0 (Free) NDlp
8230f330 size: a0 previous size: 78 (Allocated) Process:
85cbc638
8230f3d0 size: 10 previous size: a0 (Free) Ddk
8230f3e0 size: a0 previous size: 10 (Allocated) Ddk
8230f480 size: b8 previous size: a0 (Allocated) Ddk
8230f538 size: a0 previous size: b8 (Allocated) Ddk
8230f5d8 size: a0 previous size: a0 (Allocated) Process:
85cbc638
8230f678 size: a0 previous size: a0 (Allocated) Process:
85cbc638
8230f718 size: a0 previous size: a0 (Allocated) Ddk
8230f7b8 size: 8 previous size: a0 (Free) NDlp
8230f7c0 size: a0 previous size: 8 (Allocated) Process:
85cbc638
8230f860 size: 18 previous size: a0 (Free) Ddk
*8230f878 size: b8 previous size: 18 (Allocated) *Ddk
Pooltag Ddk : Default for driver allocated memory (user's of
ntddk.h)
GetUlongFromAddress: unable to read from 805637f0
8230f930 is not a valid small pool allocation, checking large pool....
unable to get pool big page table - either wrong symbols or pool
tagging is disabled
8230f930 is freed (or corrupt) pool
Bad previous allocation size @8230f930, last size was 17
***
*** An error (or corruption) in the pool was detected;
*** Pool Region unknown (0xFFFFFFFF8230F930)
***
*** Use !poolval 8230f000 for more details.
***
kd> !poolval 8230f000
Pool page 8230f000 region is Unknown
Validating Pool headers for pool page: 8230f000
Pool page [ 8230f000 ] is __inVALID.
Analyzing linked list...
[ 8230f878 --> 8230f9d0 (size = 0x158 bytes)]: Corrupt region
Scanning for single bit errors...
None found
Thanks,
Regards
D V
I have posted output of "!analyze -v"
I started the Driver verifier with enable pool tracking.
After a period of time driver crashes.
Following is a Crash dump analysis output using WinDbg.
kd> !analyze -v
ERROR: FindPlugIns 8007007b
*******************************************************************************
*
*
* Bugcheck
Analysis *
*
*
*******************************************************************************
DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught.
This is
because the driver was specified in the registry as being suspect (by
the
administrator) and the kernel has enabled substantial checking of this
driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and
0xA will
be among the most commonly seen crashes.
Parameter 1 = 0x1000 .. 0x1020 - deadlock verifier error
codes.
Typically the code is 0x1001 (deadlock detected) and
you can
issue a '!deadlock' KD command to get more information.
Arguments:
Arg1: 00000053, freeing memory where the caller has written past the
end of the
allocation, overwriting our stored virtual address.
Arg2: f8989c40, base address of the allocation,
Arg3: f8989cf0, header,
Arg4: f88f8f48, (reserved)
Debugging Details:
------------------
BUGCHECK_STR: 0xc4_53
WRITE_ADDRESS: f8989c40
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: DRIVER_FAULT
PROCESS_NAME: vmware-vmx.exe
LAST_CONTROL_TRANSFER: from 8066ce8e to 80533806
STACK_TEXT:
f78a6c88 8066ce8e 000000c4 00000053 f8989c40 nt!KeBugCheckEx+0x1b
f78a6cb0 8054c39f f8989c40 000000c0 00000000 nt!ViFreeTrackedPool+0xf5
f78a6cfc f783035e f8989c40 00000000 00000000 nt!ExFreePoolWithTag+0xbf
f78a6d34 f7830f25 00000006 f957bf58 85db444a Plg1!
TCPHashTable::tch_cleanup+0xf1 [d:\vmfw\packetengine\plugins\idsfw
\tcphashtable.cpp @ 460]
f78a6d50 f783173b 85db4436 f957bea8 000000ff Plg1!
TCPSessionHandler::__tcm_new_conn+0x103 [d:\vmfw\packetengine\plugins
\idsfw\tcpsessionhandler.cpp @ 296]
f78a6db0 f78320f1 85db4436 c0a804b6 00000015 Plg1!
TCPSessionHandler::tcm_handle_packet+0x4a2 [d:\vmfw\packetengine
\plugins\idsfw\tcpsessionhandler.cpp @ 703]
f78a6e04 f78326a1 85db4436 00000001 8606e790 Plg1!
CPacketDecoder::tcp_decode+0x521 [d:\vmfw\packetengine\plugins\idsfw
\packetdecoder.cpp @ 766]
f78a6e3c f7832b9b 85db4428 00000001 8606e790 Plg1!
CPacketDecoder::ip_decode+0x1ef [d:\vmfw\packetengine\plugins\idsfw
\packetdecoder.cpp @ 133]
f78a6e5c f789c4ec 86052dd0 85e43008 00000800 Plg1!
PacketHandler::IDSFWRecieveHandler+0x8f [d:\vmfw\packetengine\plugins
\idsfw\packethandler.cpp @ 332]
f78a6eb4 bae63b72 86052dd0 85e43008 eecafce4 Nx!
PNDISXtender::NewRecieveHandler+0xb4 [c:\vmfw\packetengine\ndisext
\pndisxtender.cpp @ 1384]
f78a6ee8 bac7a5d7 85e50b28 85e43008 00000001 NDIS!
EthFilterDprIndicateReceive+0x17c
f78a6f28 bae63ad6 85e4ddb8 85e43008 eecafce4 psched!ClReceiveIndication
+0x21b
f78a6f5c f7777493 85e45b28 85e43008 eecafce4 NDIS!
EthFilterDprIndicateReceive+0xe0
f78a6f8c f7777802 85e43008 0000ffff 85e43008 RTL8139!
RTFast_IndicatePacket+0x85
f78a6f9c f7777889 85e43008 804e4a15 86133130 RTL8139!RTFast_RcvDpc
+0x50
f78a6fb4 bae5c6a5 00e43008 806f02e7 00000000 RTL8139!
RTFast_HandleInterrupt+0x2f
f78a6fd0 804dbbd4 85e43074 85e43060 00000000 NDIS!ndisMDpc+0xff
f78a6ff4 804db89e ee7bfb74 00000000 00000000 nt!KiRetireDpcList+0x46
f78a6ff8 ee7bfb74 00000000 00000000 00000000 nt!KiDispatchInterrupt
+0x2a
WARNING: Frame IP not in any known module. Following frames may be
wrong.
804db89e 00000000 00000009 bb835675 00000128 0xee7bfb74
STACK_COMMAND: kb
FOLLOWUP_IP:
Plg1!TCPHashTable::tch_cleanup+f1 [d:\vmfw\packetengine\plugins\idsfw
\tcphashtable.cpp @ 460]
f783035e 8b55fc mov edx,dword ptr [ebp-4]
FAULTING_SOURCE_CODE:
456: RtlZeroMemory(ctrack,sizeof(tcm_connection));
457:
458: //DbgPrint("%x --- cleanup ",ctrack);
459:> 460: ExFreePool(ctrack);
461:
462: //iConnections--;
463: }
464: }
465: }
SYMBOL_STACK_INDEX: 3
SYMBOL_NAME: Plg1!TCPHashTable::tch_cleanup+f1
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: Plg1
IMAGE_NAME: Plg1.SYS
DEBUG_FLR_IMAGE_TIMESTAMP: 4982c99f
FAILURE_BUCKET_ID: 0xc4_53_W_Plg1!TCPHashTable::tch_cleanup+f1
BUCKET_ID: 0xc4_53_W_Plg1!TCPHashTable::tch_cleanup+f1
Followup: MachineOwner
---------
Thanks
Regards
D V
Thanks
ctrack is declared as
tconnection* ctrack = (tconnection *)ExAllocatePool(NonPagedPool,sizeof
(tconnection));
and tconnection is defined as follows.
typedef struct tconnection
{
conn_basic_info ct_base;
unsigned short fc_action;
unsigned short fc_prev_state;
unsigned short fc_state;
tcm_trans_conn_block conn_tcb[CONNECTION_MAX];
}tconnection;
typedef struct __tcm_trans_conn_block
{
unsigned long ip_address;
unsigned long init_seq;
unsigned long nxt_seq;
unsigned long last_ack;
unsigned int win_scale;
unsigned int port_addr;
unsigned int window_size;
unsigned int max_seg_size;
}tcm_trans_conn_block;
Thanks again
Regards,
D V
.
- Follow-Ups:
- Re: BAD_POOL_HEADER - BSOD
- From: daniel
- Re: BAD_POOL_HEADER - BSOD
- References:
- BAD_POOL_HEADER - BSOD
- From: Devang
- Re: BAD_POOL_HEADER - BSOD
- From: daniel
- Re: BAD_POOL_HEADER - BSOD
- From: Devang
- Re: BAD_POOL_HEADER - BSOD
- From: daniel
- Re: BAD_POOL_HEADER - BSOD
- From: Devang
- Re: BAD_POOL_HEADER - BSOD
- From: daniel
- BAD_POOL_HEADER - BSOD
- Prev by Date: Re: BAD_POOL_HEADER - BSOD
- Next by Date: Re: BAD_POOL_HEADER - BSOD
- Previous by thread: Re: BAD_POOL_HEADER - BSOD
- Next by thread: Re: BAD_POOL_HEADER - BSOD
- Index(es):
Relevant Pages
|
