bug check 7e

NTDEV
1

Hi,
I’m writting a driver which has a thread to dequeue a list . When
running always raise the bug check

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 804e3e6c, The address that the exception occurred at
Arg3: f3836cbc, Exception Record Address
Arg4: f38369b8, Context Record Address

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - “0x%08lx”

FAULTING_IP:
nt!ExfInterlockedRemoveHeadList+c
804e3e6c 894a04 mov dword ptr [edx+4],ecx

EXCEPTION_RECORD: f3836cbc – (.exr 0xfffffffff3836cbc)
ExceptionAddress: 804e3e6c (nt!ExfInterlockedRemoveHeadList+0x0000000c)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000001
Parameter[1]: 00000004
Attempt to write to address 00000004

CONTEXT: f38369b8 – (.cxr 0xfffffffff38369b8)
eax=8601ef80 ebx=00000200 ecx=86148d44 edx=00000000 esi=00000000 edi=00000000
eip=804e3e6c esp=f3836d84 ebp=f3836dac iopl=0 nv up di ng nz ac pe cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010097
nt!ExfInterlockedRemoveHeadList+0xc:
804e3e6c 894a04 mov dword ptr [edx+4],ecx ds:0023:00000004=???
Resetting default scope

PROCESS_NAME: System

ERROR_CODE: (NTSTATUS) 0xc0000005 - “0x%08lx”

EXCEPTION_PARAMETER1: 00000001

EXCEPTION_PARAMETER2: 00000004

WRITE_ADDRESS: 00000004

FOLLOWUP_IP:
uSCSIPort!PiDataInWorker+57 [c:\uscsi\uscsiport\data.c @ 410]
f7b3bcc3 8bf0 mov esi,eax

BUGCHECK_STR: 0x7E

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LAST_CONTROL_TRANSFER: from f7b3bcc3 to 804e3e6c

STACK_TEXT:
f3836d84 f7b3bcc3 00000000 85fe78b8 00000000 nt!ExfInterlockedRemoveHeadList+0xc
f3836dac 8057c0df 00000000 00000000 00000000
uSCSIPort!PiDataInWorker+0x57 [c:\uscsi\uscsiport\data.c @ 410]
f3836ddc 804f98fa f7b3bc6c e1dc03e0 00000000 nt!PspSystemThreadStartup+0x34
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: uSCSIPort!PiDataInWorker+57

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: uSCSIPort

IMAGE_NAME: uSCSIPort.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4d15b95e

STACK_COMMAND: .cxr 0xfffffffff38369b8 ; kb

FAILURE_BUCKET_ID: 0x7E_uSCSIPort!PiDataInWorker+57

BUCKET_ID: 0x7E_uSCSIPort!PiDataInWorker+57

Followup: MachineOwner

It seems the currupted LIST_ENTRY raise this bug check but I can’t
find where in my code the LIST_ENTRY got curruptted.
Could someone help me with this? thanks in advance.

2

Looks like you have a null pointer,

the instruction that is failing is

“mov dword ptr [edx+4],ecx”

and edx is 0.

Cheers
/Faik

On Sat, Dec 25, 2010 at 2:22 PM, yushang wrote:
> Hi,
> I’m writting a driver which has a thread to dequeue a list . When
> running always raise the bug check
>
> *
> * ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
> * ? ? ? ? ? ? ? ? ? ? ? ?Bugcheck Analysis ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
> * ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>
>
> SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
> This is a very common bugcheck. ?Usually the exception address pinpoints
> the driver/function that caused the problem. ?Always note this address
> as well as the link date of the driver/image that contains this address.
> Arguments:
> Arg1: c0000005, The exception code that was not handled
> Arg2: 804e3e6c, The address that the exception occurred at
> Arg3: f3836cbc, Exception Record Address
> Arg4: f38369b8, Context Record Address
>
> Debugging Details:
> ------------------
>
>
> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - “0x%08lx”
>
> FAULTING_IP:
> nt!ExfInterlockedRemoveHeadList+c
> 804e3e6c 894a04 ? ? ? ? ?mov ? ? dword ptr [edx+4],ecx
>
> EXCEPTION_RECORD: ?f3836cbc – (.exr 0xfffffffff3836cbc)
> ExceptionAddress: 804e3e6c (nt!ExfInterlockedRemoveHeadList+0x0000000c)
> ? ExceptionCode: c0000005 (Access violation)
> ?ExceptionFlags: 00000000
> NumberParameters: 2
> ? Parameter[0]: 00000001
> ? Parameter[1]: 00000004
> Attempt to write to address 00000004
>
> CONTEXT: ?f38369b8 – (.cxr 0xfffffffff38369b8)
> eax=8601ef80 ebx=00000200 ecx=86148d44 edx=00000000 esi=00000000 edi=00000000
> eip=804e3e6c esp=f3836d84 ebp=f3836dac iopl=0 ? ? ? ? nv up di ng nz ac pe cy
> cs=0008 ?ss=0010 ?ds=0023 ?es=0023 ?fs=0030 ?gs=0000 ? ? ? ? ? ? efl=00010097
> nt!ExfInterlockedRemoveHeadList+0xc:
> 804e3e6c 894a04 ? ? ? ? ?mov ? ? dword ptr [edx+4],ecx ds:0023:00000004=???
> Resetting default scope
>
> PROCESS_NAME: ?System
>
> ERROR_CODE: (NTSTATUS) 0xc0000005 - “0x%08lx”
>
> EXCEPTION_PARAMETER1: ?00000001
>
> EXCEPTION_PARAMETER2: ?00000004
>
> WRITE_ADDRESS: ?00000004
>
> FOLLOWUP_IP:
> uSCSIPort!PiDataInWorker+57 [c:\uscsi\uscsiport\data.c @ 410]
> f7b3bcc3 8bf0 ? ? ? ? ? ?mov ? ? esi,eax
>
> BUGCHECK_STR: ?0x7E
>
> DEFAULT_BUCKET_ID: ?NULL_CLASS_PTR_DEREFERENCE
>
> LAST_CONTROL_TRANSFER: ?from f7b3bcc3 to 804e3e6c
>
> STACK_TEXT:
> f3836d84 f7b3bcc3 00000000 85fe78b8 00000000 nt!ExfInterlockedRemoveHeadList+0xc
> f3836dac 8057c0df 00000000 00000000 00000000
> uSCSIPort!PiDataInWorker+0x57 [c:\uscsi\uscsiport\data.c @ 410]
> f3836ddc 804f98fa f7b3bc6c e1dc03e0 00000000 nt!PspSystemThreadStartup+0x34
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> SYMBOL_STACK_INDEX: ?1
>
> SYMBOL_NAME: ?uSCSIPort!PiDataInWorker+57
>
> FOLLOWUP_NAME: ?MachineOwner
>
> MODULE_NAME: uSCSIPort
>
> IMAGE_NAME: ?uSCSIPort.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: ?4d15b95e
>
> STACK_COMMAND: ?.cxr 0xfffffffff38369b8 ; kb
>
> FAILURE_BUCKET_ID: ?0x7E_uSCSIPort!PiDataInWorker+57
>
> BUCKET_ID: ?0x7E_uSCSIPort!PiDataInWorker+57
>
> Followup: MachineOwner
> ---------
>
> It seems the currupted LIST_ENTRY raise this bug check but I can’t
> find where in my code the LIST_ENTRY got curruptted.
> Could someone help me with this? thanks in advance.
>
> —
> 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
>

3

You appear to have passed in NULL as the listhead.
I would add a lot of run time tracing and asserts to my code at this
point, find a reproducible test case, and start narrowing in on how
the list has been mismanaged.

(Actually I start with run time tracing and asserts, and add my code
around that framework :slight_smile:

Without your source code we are not going to be able to provide much
insight into how you have gone wrong.

As an aside, I never use the interlocked list operations. Probably
only because they confusingly mis-advertise themselves as
‘interlocked’ when in fact they aren’t. If I need to access a list at
DIRQL I prefer to use the existing interrupt spinlock mechanisms. If I
want to use actual interlocked list operations, there is an open
source lock free library available,

Mark Roddy

On Sat, Dec 25, 2010 at 8:22 AM, yushang wrote:
> 00000000

4

The complete text of ExfInterlockedRemoveHeadList is
pushfd
cli
mov eax,dword ptr [ecx]
cmp eax,ecx
je nt!ExfInterlockedRemoveHeadList+0x11
mov edx,dword ptr [eax]
mov dword ptr [ecx],edx
mov dword ptr [edx+4],ecx
popfd
xor eax,eax
ret

It seems the Flink is null for entry at eax. Which is the entry my
code enqueued and I’m sure the entry is initialized by
InitializeListHead . Is there any chance a LIST_ENTRY’s Flink got
nulled? Firstly , my code will never update it . Secondly , I’ve
inspected ExfInterlockedInsertTailList , this one also won’t. Many
thanks

2010/12/25 Faik Riza :
> Looks like you have a null pointer,
>
> the instruction that is failing is
>
> “mov dword ptr [edx+4],ecx”
>
> and edx is 0.
>
>
>
> Cheers
> /Faik
>
> On Sat, Dec 25, 2010 at 2:22 PM, yushang wrote:
>> Hi,
>> I’m writting a driver which has a thread to dequeue a list . When
>> running always raise the bug check
>>
>> ***
>> *
>> * Bugcheck Analysis
>> *
>>
>>
>> SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
>> This is a very common bugcheck. Usually the exception address pinpoints
>> the driver/function that caused the problem. Always note this address
>> as well as the link date of the driver/image that contains this address.
>> Arguments:
>> Arg1: c0000005, The exception code that was not handled
>> Arg2: 804e3e6c, The address that the exception occurred at
>> Arg3: f3836cbc, Exception Record Address
>> Arg4: f38369b8, Context Record Address
>>
>> Debugging Details:
>> ------------------
>>
>>
>> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - “0x%08lx”
>>
>> FAULTING_IP:
>> nt!ExfInterlockedRemoveHeadList+c
>> 804e3e6c 894a04 mov dword ptr [edx+4],ecx
>>
>> EXCEPTION_RECORD: f3836cbc – (.exr 0xfffffffff3836cbc)
>> ExceptionAddress: 804e3e6c (nt!ExfInterlockedRemoveHeadList+0x0000000c)
>> ExceptionCode: c0000005 (Access violation)
>> ExceptionFlags: 00000000
>> NumberParameters: 2
>> Parameter[0]: 00000001
>> Parameter[1]: 00000004
>> Attempt to write to address 00000004
>>
>> CONTEXT: f38369b8 – (.cxr 0xfffffffff38369b8)
>> eax=8601ef80 ebx=00000200 ecx=86148d44 edx=00000000 esi=00000000 edi=00000000
>> eip=804e3e6c esp=f3836d84 ebp=f3836dac iopl=0 nv up di ng nz ac pe cy
>> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010097
>> nt!ExfInterlockedRemoveHeadList+0xc:
>> 804e3e6c 894a04 mov dword ptr [edx+4],ecx ds:0023:00000004=???
>> Resetting default scope
>>
>> PROCESS_NAME: System
>>
>> ERROR_CODE: (NTSTATUS) 0xc0000005 - “0x%08lx”
>>
>> EXCEPTION_PARAMETER1: 00000001
>>
>> EXCEPTION_PARAMETER2: 00000004
>>
>> WRITE_ADDRESS: 00000004
>>
>> FOLLOWUP_IP:
>> uSCSIPort!PiDataInWorker+57 [c:\uscsi\uscsiport\data.c @ 410]
>> f7b3bcc3 8bf0 mov esi,eax
>>
>> BUGCHECK_STR: 0x7E
>>
>> DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE
>>
>> LAST_CONTROL_TRANSFER: from f7b3bcc3 to 804e3e6c
>>
>> STACK_TEXT:
>> f3836d84 f7b3bcc3 00000000 85fe78b8 00000000 nt!ExfInterlockedRemoveHeadList+0xc
>> f3836dac 8057c0df 00000000 00000000 00000000
>> uSCSIPort!PiDataInWorker+0x57 [c:\uscsi\uscsiport\data.c @ 410]
>> f3836ddc 804f98fa f7b3bc6c e1dc03e0 00000000 nt!PspSystemThreadStartup+0x34
>> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>>
>>
>> SYMBOL_STACK_INDEX: 1
>>
>> SYMBOL_NAME: uSCSIPort!PiDataInWorker+57
>>
>> FOLLOWUP_NAME: MachineOwner
>>
>> MODULE_NAME: uSCSIPort
>>
>> IMAGE_NAME: uSCSIPort.sys
>>
>> DEBUG_FLR_IMAGE_TIMESTAMP: 4d15b95e
>>
>> STACK_COMMAND: .cxr 0xfffffffff38369b8 ; kb
>>
>> FAILURE_BUCKET_ID: 0x7E_uSCSIPort!PiDataInWorker+57
>>
>> BUCKET_ID: 0x7E_uSCSIPort!PiDataInWorker+57
>>
>> Followup: MachineOwner
>> ---------
>>
>> It seems the currupted LIST_ENTRY raise this bug check but I can’t
>> find where in my code the LIST_ENTRY got curruptted.
>> Could someone help me with this? thanks in advance.
>>
>> —
>> 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
>>
>
> —
> 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
>

5

It is pretty obvious what is going on here. Note, for example, that it says
"Attempt to write to address 00000004. That’s a dead giveaway that you
passed in a NULL pointer somewhere.

The ExInterlockedRemoveHeadList attempted to use a NULL pointer. Now there
can be lots of reasons for this, and you will have to figure out what is
going on here. Look at the stack trace. The parameters appear to me to say
that your lock pointer is NULL. Did you properly initialize the spin lock
before using it, for example? Without seeing the code that initializes the
lock (and knowing where it is executed!) there is no way to tell.
Similarly, if the lock is part of your device extension, are you sure you
are picking up the device extension properly? If it is part os some more
complex structure, is that structure being properly initialized, and its
pointer being correctly placed wherever it is supposed to be?

See below for what I think is the interpretation of the stack dump. I’m not
sure what ExfInterlockedRemoveHeadList’s parameters are, but for the moment
I’m assuming they are the same as ExInterlockedRemoveHeadList. If they are
not, it might be that the LIST_ENTRY pointer is NULL.

What I didn’t see here, and expected to, is the IRQL level. But I’ve not
used the very latest versions of /analyze -v, so I don’t know if this
information has been dropped.

Lacking any source context at all, it is really hard to tell what is going
wrong here, so these are at best guesses.

joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of yushang
Sent: Saturday, December 25, 2010 8:22 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] bug check 7e

Hi,
I’m writting a driver which has a thread to dequeue a list . When running
always raise the bug check

****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e) This is a very common bugcheck.
Usually the exception address pinpoints the driver/function that caused the
problem. Always note this address as well as the link date of the
driver/image that contains this address.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 804e3e6c, The address that the exception occurred at
Arg3: f3836cbc, Exception Record Address
Arg4: f38369b8, Context Record Address

Debugging Details:

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - “0x%08lx”

FAULTING_IP:
nt!ExfInterlockedRemoveHeadList+c
804e3e6c 894a04 mov dword ptr [edx+4],ecx

EXCEPTION_RECORD: f3836cbc – (.exr 0xfffffffff3836cbc)
ExceptionAddress: 804e3e6c (nt!ExfInterlockedRemoveHeadList+0x0000000c)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000001
Parameter[1]: 00000004
Attempt to write to address 00000004

CONTEXT: f38369b8 – (.cxr 0xfffffffff38369b8) eax=8601ef80 ebx=00000200
ecx=86148d44 edx=00000000 esi=00000000 edi=00000000
eip=804e3e6c esp=f3836d84 ebp=f3836dac iopl=0 nv up di ng nz ac pe
cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010097
nt!ExfInterlockedRemoveHeadList+0xc:
804e3e6c 894a04 mov dword ptr [edx+4],ecx
ds:0023:00000004=???
Resetting default scope

PROCESS_NAME: System

ERROR_CODE: (NTSTATUS) 0xc0000005 - “0x%08lx”

EXCEPTION_PARAMETER1: 00000001

EXCEPTION_PARAMETER2: 00000004

WRITE_ADDRESS: 00000004

FOLLOWUP_IP:
uSCSIPort!PiDataInWorker+57 [c:\uscsi\uscsiport\data.c @ 410]
f7b3bcc3 8bf0 mov esi,eax

BUGCHECK_STR: 0x7E

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

LAST_CONTROL_TRANSFER: from f7b3bcc3 to 804e3e6c

STACK_TEXT:
************************************
EXInterlockedRemoveHeadList(PLIST_ENTRY, PKSPIN_LOCK)
| |
±-------------------+ |
| |
| ±-----------------------+
| |
v v
f3836d84 f7b3bcc3 00000000 85fe78b8 00000000
nt!ExfInterlockedRemoveHeadList+0xc
f3836dac 8057c0df 00000000 00000000 00000000
uSCSIPort!PiDataInWorker+0x57 [c:\uscsi\uscsiport\data.c @ 410] f3836ddc
804f98fa f7b3bc6c e1dc03e0 00000000 nt!PspSystemThreadStartup+0x34 00000000
00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: uSCSIPort!PiDataInWorker+57

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: uSCSIPort

IMAGE_NAME: uSCSIPort.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4d15b95e

STACK_COMMAND: .cxr 0xfffffffff38369b8 ; kb

FAILURE_BUCKET_ID: 0x7E_uSCSIPort!PiDataInWorker+57

BUCKET_ID: 0x7E_uSCSIPort!PiDataInWorker+57

Followup: MachineOwner

It seems the currupted LIST_ENTRY raise this bug check but I can’t find
where in my code the LIST_ENTRY got curruptted.
Could someone help me with this? thanks in advance.

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

–
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.

6

  1. You’re missing a couple of instructions in the routine below, but that
    doesn’t have anything to do with your problem.

  2. You said “I’m sure the entry is initialized by InitializeListHead.” It
    is not the ENTRY you need to initialize but the ListHead itself. However,
    if you were not initializing the list head, I’d expect the call to
    ExInterlockedInsert(Head/Tail) list to crash.

  3. So it would seem that something in your code clobbered Flink between
    the time you inserted the item and the time you removed it.

yushang
Sent by: xxxxx@lists.osr.com
12/25/2010 09:18 PM
Please respond to
“Windows System Software Devs Interest List”

To
“Windows System Software Devs Interest List”
cc

Subject
Re: [ntdev] bug check 7e

The complete text of ExfInterlockedRemoveHeadList is
pushfd
cli
mov eax,dword ptr [ecx]
cmp eax,ecx
je nt!ExfInterlockedRemoveHeadList+0x11
mov edx,dword ptr [eax]
mov dword ptr [ecx],edx
mov dword ptr [edx+4],ecx
popfd
xor eax,eax
ret

It seems the Flink is null for entry at eax. Which is the entry my
code enqueued and I’m sure the entry is initialized by
InitializeListHead . Is there any chance a LIST_ENTRY’s Flink got
nulled? Firstly , my code will never update it . Secondly , I’ve
inspected ExfInterlockedInsertTailList , this one also won’t. Many
thanks

2010/12/25 Faik Riza :
> Looks like you have a null pointer,
>
> the instruction that is failing is
>
> “mov dword ptr [edx+4],ecx”
>
> and edx is 0.
>
>
>
> Cheers
> /Faik
>
> On Sat, Dec 25, 2010 at 2:22 PM, yushang wrote:
>> Hi,
>> I’m writting a driver which has a thread to dequeue a list . When
>> running always raise the bug check
>>
>>
***
>> *

>> * Bugcheck Analysis

>> *

>>

>>
>> SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
>> This is a very common bugcheck. Usually the exception address
pinpoints
>> the driver/function that caused the problem. Always note this address
>> as well as the link date of the driver/image that contains this
address.
>> Arguments:
>> Arg1: c0000005, The exception code that was not handled
>> Arg2: 804e3e6c, The address that the exception occurred at
>> Arg3: f3836cbc, Exception Record Address
>> Arg4: f38369b8, Context Record Address
>>
>> Debugging Details:
>> ------------------
>>
>>
>> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - “0x%08lx”
>>
>> FAULTING_IP:
>> nt!ExfInterlockedRemoveHeadList+c
>> 804e3e6c 894a04 mov dword ptr [edx+4],ecx
>>
>> EXCEPTION_RECORD: f3836cbc – (.exr 0xfffffffff3836cbc)
>> ExceptionAddress: 804e3e6c (nt!ExfInterlockedRemoveHeadList+0x0000000c)
>> ExceptionCode: c0000005 (Access violation)
>> ExceptionFlags: 00000000
>> NumberParameters: 2
>> Parameter[0]: 00000001
>> Parameter[1]: 00000004
>> Attempt to write to address 00000004
>>
>> CONTEXT: f38369b8 – (.cxr 0xfffffffff38369b8)
>> eax=8601ef80 ebx=00000200 ecx=86148d44 edx=00000000 esi=00000000
edi=00000000
>> eip=804e3e6c esp=f3836d84 ebp=f3836dac iopl=0 nv up di ng nz ac
pe cy
>> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010097
>> nt!ExfInterlockedRemoveHeadList+0xc:
>> 804e3e6c 894a04 mov dword ptr [edx+4],ecx
ds:0023:00000004=???
>> Resetting default scope
>>
>> PROCESS_NAME: System
>>
>> ERROR_CODE: (NTSTATUS) 0xc0000005 - “0x%08lx”
>>
>> EXCEPTION_PARAMETER1: 00000001
>>
>> EXCEPTION_PARAMETER2: 00000004
>>
>> WRITE_ADDRESS: 00000004
>>
>> FOLLOWUP_IP:
>> uSCSIPort!PiDataInWorker+57 [c:\uscsi\uscsiport\data.c @ 410]
>> f7b3bcc3 8bf0 mov esi,eax
>>
>> BUGCHECK_STR: 0x7E
>>
>> DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE
>>
>> LAST_CONTROL_TRANSFER: from f7b3bcc3 to 804e3e6c
>>
>> STACK_TEXT:
>> f3836d84 f7b3bcc3 00000000 85fe78b8 00000000
nt!ExfInterlockedRemoveHeadList+0xc
>> f3836dac 8057c0df 00000000 00000000 00000000
>> uSCSIPort!PiDataInWorker+0x57 [c:\uscsi\uscsiport\data.c @ 410]
>> f3836ddc 804f98fa f7b3bc6c e1dc03e0 00000000
nt!PspSystemThreadStartup+0x34
>> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>>
>>
>> SYMBOL_STACK_INDEX: 1
>>
>> SYMBOL_NAME: uSCSIPort!PiDataInWorker+57
>>
>> FOLLOWUP_NAME: MachineOwner
>>
>> MODULE_NAME: uSCSIPort
>>
>> IMAGE_NAME: uSCSIPort.sys
>>
>> DEBUG_FLR_IMAGE_TIMESTAMP: 4d15b95e
>>
>> STACK_COMMAND: .cxr 0xfffffffff38369b8 ; kb
>>
>> FAILURE_BUCKET_ID: 0x7E_uSCSIPort!PiDataInWorker+57
>>
>> BUCKET_ID: 0x7E_uSCSIPort!PiDataInWorker+57
>>
>> Followup: MachineOwner
>> ---------
>>
>> It seems the currupted LIST_ENTRY raise this bug check but I can’t
>> find where in my code the LIST_ENTRY got curruptted.
>> Could someone help me with this? thanks in advance.
>>
>> —
>> 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
>>
>
> —
> 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
>

—
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

7

Yes. I do InitializeListHead the list head

2010/12/26
>
> You said “I’m sure the entry is initialized by InitializeListHead.” It is not the ENTRY you need to initialize but the ListHead itself

8

Did you mean ExfInterlockedRemoveHeadList ? I’m sure that’s the
complete text . I’m running on an UP system.

2010/12/26
>
> You’re missing a couple of instructions in the routine below

9

following are my code patterns

the dequeue worker (a system thread)
while(TRUE)
{
KeWaitForSingleObject ( &Ctx->DataInEvent ,
Executive ,
KernelMode ,
FALSE ,
NULL );
while( DataInEnt = ExInterlockedRemoveHeadList ( &Ctx->DataIns ,
&Ctx->DataInLock ) )
{
…
DataIn = CONTAINING_RECORD ( DataInEnt , PDU , PDUList );
InitializeListHead ( &DataIn->PDUList);
…
}
}

the enqueue worker(a system thread)
…
ExInterlockedInsertTailList ( &Ctx->DataIns , &Pdu->PDUList, &Ctx->DataInLock );
KeSetEvent( &Ctx->DataInEvent , IO_NO_INCREMENT , FALSE );
…
Where Ctx reside in NonPagedPool . Is any wrong with these ?

2010/12/25 Mark Roddy :
> Without your source code we are not going to be able to provide much
> insight into how you have gone wrong

10

Even I changed the dequeue to the following lines:

KeAcquireSpinLock(&Ctx->DataInLock,&OldIrq);
DataInEnt = RemoveHeadList(&Ctx->DataIns);
KeReleaseSpinLock(&Ctx->DataInLock,OldIrq);

which expand to these assembly lines

call dword ptr [uSCSIPort!_imp_KfAcquireSpinLock (f7b34900)]
mov esi,dword ptr [ebx] ;esi = (&Ctx->DataIns)->Flink
mov ecx,dword ptr [esi] ;sometime ecx is null
mov dword ptr [ebx],ecx
mov dword ptr [ecx+4],ebx ;bug check at this
line occasionlly
mov ecx,dword ptr [ebp-0Ch]
mov dl,al
call dword ptr [uSCSIPort!_imp_KfReleaseSpinLock (f7b34904)]

I will get bugchek d1 but the root cause is the same . Strangely this
happen occasionlly.

11

Well you may have introduced a new bug as removeheadlist behaves badly
on an empty list.

To get back to your original problem: your listhead was null. Assuming
that the list head is in your device extension, you have managed to
zero out the section of your device extension that contains the
listhead.

What data structure is defined adjacent (and ‘above’) your list?

On Sunday, December 26, 2010, yushang wrote:
> Even I changed the dequeue to the following lines:
>
> KeAcquireSpinLock(&Ctx->DataInLock,&OldIrq);
> DataInEnt = RemoveHeadList(&Ctx->DataIns);
> KeReleaseSpinLock(&Ctx->DataInLock,OldIrq);
>
> which expand to these assembly lines
>
> call ? ?dword ptr [uSCSIPort!_imp_KfAcquireSpinLock (f7b34900)]
> mov ? ? esi,dword ptr [ebx] ? ? ? ? ? ? ? ? ? ? ? ?;esi = (&Ctx->DataIns)->Flink
> mov ? ? ecx,dword ptr [esi] ? ? ? ? ? ? ? ? ? ? ? ?;sometime ecx is null
> mov ? ? dword ptr [ebx],ecx
> mov ? ? dword ptr [ecx+4],ebx ? ? ? ? ? ? ? ? ? ;bug check at this
> line occasionlly
> mov ? ? ecx,dword ptr [ebp-0Ch]
> mov ? ? dl,al
> call ? ?dword ptr [uSCSIPort!_imp_KfReleaseSpinLock (f7b34904)]
>
> I will get bugchek d1 but the root cause is the same . Strangely this
> happen occasionlly.
>
> —
> 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

12

Thanks Roddy. In fact I’m passing the listhead as the thread context
and the listhead is allocated from NonPagedPool

2010/12/27 Mark Roddy
>
> Assuming
> that the list head is in your device extension

13

The listhead is a member of following structure
typedef struct _uCON_CTX
{
…
LIST_ENTRY DataIns;
KSPIN_LOCK DataInLock;
…
}uCON_CTX , *PuCON_CTX;
it’s not the first member of the structure

2010/12/27 Mark Roddy :
> What data structure is defined adjacent (and ‘above’) your list?

14

> I’m writting a driver which has a thread to dequeue a list

Are you deallocating the structure which is still on the list?

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

15

This is the trap context

kd> .trap 0xfffffffff3b52d1c
ErrCode = 00000002
eax=00000000 ebx=85feff04 ecx=00000000 edx=8055ba00 esi=85fa40e8 edi=86238e7c
eip=f7b3bd17 esp=f3b52d90 ebp=f3b52dac iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
uSCSIPort!PiDataInWorker+0x39:
f7b3bd17 895904 mov dword ptr [ecx+4],ebx ds:0023:00000004=???
kd> dd 85feff04 ;[ebx] this is the list
head DataIns
85feff04 00000000 85fa40e8 ;Flink and Blink
kd> dd 85fa40e8 ;[esi]
85fa40e8 00000000 85feff04 ;Flink and Blink entry on DataIns.
Flink is corrupted
;which cause
DataIns’s Flink also corrupted
It’s strange how did Flink get corrupted

2010/12/26 yushang :
> Even I changed the dequeue to the following lines:
>
> KeAcquireSpinLock(&Ctx->DataInLock,&OldIrq);
> DataInEnt = RemoveHeadList(&Ctx->DataIns);
> KeReleaseSpinLock(&Ctx->DataInLock,OldIrq);
>
> which expand to these assembly lines
>
> call dword ptr [uSCSIPort!_imp_KfAcquireSpinLock (f7b34900)]
> mov esi,dword ptr [ebx] ;esi = (&Ctx->DataIns)->Flink
> mov ecx,dword ptr [esi] ;sometime ecx is null
> mov dword ptr [ebx],ecx
> mov dword ptr [ecx+4],ebx ;bug check at this
> line occasionlly
> mov ecx,dword ptr [ebp-0Ch]
> mov dl,al
> call dword ptr [uSCSIPort!_imp_KfReleaseSpinLock (f7b34904)]
>
> I will get bugchek d1 but the root cause is the same . Strangely this
> happen occasionlly.
>

16

Hi Maxim , If I deallocate a piece of memory the first 4 bytes will get zeroed ?

2010/12/27 Maxim S. Shatskih :
>
> Are you deallocating the structure which is still on the list?

17

If you deallocate memory you have no control of what will happen to its
contents, it can be reused immediately or placed into the pool with
changes to the contents.

Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“yushang” wrote in message news:xxxxx@ntdev:

> Hi Maxim , If I deallocate a piece of memory the first 4 bytes will get zeroed ?
>
> 2010/12/27 Maxim S. Shatskih :
> >
> > Are you deallocating the structure which is still on the list?

18

But every time I got the bug check it’s always the first 4 bytes got
corrupted . I think it should behave randomly , right ? But it not

2010/12/27 Don Burn :
> If you deallocate memory you have no control of what will happen to its
> contents, it can be reused immediately or placed into the pool with changes
> to the contents.

19

If the memory is from pool you can use the debugger to see who ‘owns’
the memory. See all the !pool* commands in windbg.

Also, if this is a buffer overwrite bug driver verifier can be very useful.

Mark Roddy

On Mon, Dec 27, 2010 at 10:25 AM, yushang wrote:
> But every time I got the bug check it’s always the first 4 bytes got
> corrupted . I think it should behave randomly , right ? But it not
>
> 2010/12/27 Don Burn :
>> If you deallocate memory you have no control of what will happen to its
>> contents, it can be reused immediately or placed into the pool with changes
>> to the contents.
>
> —
> 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
>

20

Hi Roddy, does the folllowing line mean 85fa40e is freed ?

kd> !pool 85feff04 0x2
Pool page 85feff04 region is Nonpaged pool
*85fef558 size: aa8 previous size: 198 (Allocated) *ICSu
Owning component : Unknown (update pooltag.txt)

kd> !pool 85fa40e8 0x2
Pool page 85fa40e8 region is Nonpaged pool
*85fa40e0 size: 88 previous size: 30 (Free ) *ICSu
Owning component : Unknown (update pooltag.txt)

It seems I should check my code , right?
2010/12/28 Mark Roddy :
> See all the !pool* commands in windbg