Strange exception with my driver

Hi,
I have a driver which uses two threads per device to send and receive frames
with TCP/IP.
I have three devices on the computer.
The driver works fine for a while (10 minutes to 2 hours) then I get the
following exception (see below).
However the exception doesn’t happen in my driver’s code and I cannot find
what could be wrong.

EXWORKER: exception in worker routine EB0D10A3(EA9F1600)
exception record at EB43F690
context record at EB43F6E0
Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPoint:
804aab38 cc int 3
kd> !analyze -v
Connected to Windows 2000 2195 x86 compatible target, ptr64 FALSE
Loading Kernel Symbols

.
Loading unloaded module list

Loading User Symbols
*** ERROR: Module load completed but symbols could not be loaded for
CesaCtrlAltSup.SYS
*** ERROR: Symbol file could not be found. Defaulted to export symbols for
dump_WMILIB.SYS -
*** ERROR: Module load completed but symbols could not be loaded for
dump_atapi.sys
****************************************************************************
***
*
*
* Bugcheck Analysis
*
*
*
****************************************************************************
***

Unknown bugcheck code (0)
Unknown bugcheck description
Arguments:
Arg1: 00000000
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Debugging Details:

FAULTING_IP:
nt!DbgBreakPoint+0
804aab38 cc int 3

EXCEPTION_RECORD: ffffffff – (.exr ffffffffffffffff)
ExceptionAddress: 804aab38 (nt!DbgBreakPoint)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 3
Parameter[0]: 00000000
Parameter[1]: eb43f6e0
Parameter[2]: 00000000

ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Point d’arr t Un point
d’arr t a t atteint.

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x0

LAST_CONTROL_TRANSFER: from 8041c8f5 to 804aab38

STACK_TEXT:
eb43f570 8041c8f5 804010a0 00000000 eb43fd98 nt!DbgBreakPoint
eb43f59c 8041c81f eb0d10a3 ea9f1600 eb43f5cc nt!ExpWorkerThreadFilter+0x61
eb43fda8 804aa09a 00000001 00000000 00000000 nt!ExpWorkerThread+0x191
eb43fddc 804c526a 8041c68e 00000001 00000000 nt!PspSystemThreadStartup+0x54
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
nt!DbgBreakPoint+0
804aab38 cc int 3

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nt!DbgBreakPoint+0

MODULE_NAME: nt

IMAGE_NAME: ntoskrnl.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 3ee650a8

STACK_COMMAND: kb

BUCKET_ID: 0x0_nt!DbgBreakPoint+0

Followup: MachineOwner

You are running the checked build of the w2k OS, right? This is a checked
build worker thread debug monitor.

You should use .exr and .cxr windbg commands to process the exception and
context records printed out on the debug console. This will get you inside
the stack frame for the worker thread that barfed, and perhaps give you some
better clues as to the cause of the barfage.

Exception handlers run outside of the faulting stack frame (that’s the whole
point, right.) So you rarely get an interesting stack frame from the handler
itself. Instead you have to use the debugger to process the exception record
information to recreate the offending stack. The good news is that as this
is the checked build, you are likely to find all local variables on the
stack and one stack frame per function call.

=====================
Mark Roddy

-----Original Message-----
From: Nicolas Mugnier [mailto:xxxxx@cesa.fr]
Sent: Thursday, December 11, 2003 9:23 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Strange exception with my driver

Hi,
I have a driver which uses two threads per device to send and
receive frames with TCP/IP.
I have three devices on the computer.
The driver works fine for a while (10 minutes to 2 hours)
then I get the following exception (see below).
However the exception doesn’t happen in my driver’s code and
I cannot find what could be wrong.

EXWORKER: exception in worker routine EB0D10A3(EA9F1600)
exception record at EB43F690
context record at EB43F6E0
Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPoint:
804aab38 cc int 3
kd> !analyze -v
Connected to Windows 2000 2195 x86 compatible target, ptr64
FALSE Loading Kernel Symbols


.
Loading unloaded module list

Loading User Symbols
*** ERROR: Module load completed but symbols could not be
loaded for CesaCtrlAltSup.SYS
*** ERROR: Symbol file could not be found. Defaulted to
export symbols for dump_WMILIB.SYS -
*** ERROR: Module load completed but symbols could not be
loaded for dump_atapi.sys
**************************************************************
**************
***
*
*
* Bugcheck Analysis
*
*
*
**************************************************************
**************
***

Unknown bugcheck code (0)
Unknown bugcheck description
Arguments:
Arg1: 00000000
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000

Debugging Details:

FAULTING_IP:
nt!DbgBreakPoint+0
804aab38 cc int 3

EXCEPTION_RECORD: ffffffff – (.exr ffffffffffffffff)
ExceptionAddress: 804aab38 (nt!DbgBreakPoint)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 3
Parameter[0]: 00000000
Parameter[1]: eb43f6e0
Parameter[2]: 00000000

ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Point d’arr
t Un point d’arr t a t atteint.

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0x0

LAST_CONTROL_TRANSFER: from 8041c8f5 to 804aab38

STACK_TEXT:
eb43f570 8041c8f5 804010a0 00000000 eb43fd98 nt!DbgBreakPoint
eb43f59c 8041c81f eb0d10a3 ea9f1600 eb43f5cc
nt!ExpWorkerThreadFilter+0x61
eb43fda8 804aa09a 00000001 00000000 00000000
nt!ExpWorkerThread+0x191 eb43fddc 804c526a 8041c68e 00000001
00000000 nt!PspSystemThreadStartup+0x54 00000000 00000000
00000000 00000000 00000000 nt!KiThreadStartup+0x16

FOLLOWUP_IP:
nt!DbgBreakPoint+0
804aab38 cc int 3

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: nt!DbgBreakPoint+0

MODULE_NAME: nt

IMAGE_NAME: ntoskrnl.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 3ee650a8

STACK_COMMAND: kb

BUCKET_ID: 0x0_nt!DbgBreakPoint+0

Followup: MachineOwner


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

You are currently subscribed to ntdev as:
xxxxx@stratus.com To unsubscribe send a blank email to
xxxxx@lists.osr.com

OK, here is what I did and what I get:

EXWORKER: exception in worker routine EB0D10A3(EA9F1600)
exception record at EB43B690
context record at EB43B6E0
Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPoint:
804aab38 cc int 3
kd> .exr EB43B690
ExceptionAddress: 8043d5c1 (nt!KeReleaseMutant+0x00000092)
ExceptionCode: c0000046
ExceptionFlags: 00000001
NumberParameters: 0
kd> .cxr EB43B6E0
eax=c0000046 ebx=00000002 ecx=00000002 edx=00000000 esi=8141fba0
edi=814983a0
eip=8043d5c1 esp=eb43b9bc ebp=eb43b9cc iopl=0 nv up ei ng nz na pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00200282
nt!KeReleaseMutant+0x92:
8043d5c1 ff4604 inc dword ptr [esi+0x4]

I can deduce it’s KeReleaseMutant which is causing trouble. If I 'm not
wrong, KeReleaseMutant is used in KeReleaseMutex(), right ?
My KeReleaseMutex() functions are either called in worker threads, or in a
DispatchClose()/DispatchRead() routine or in a TDI event. So I don’t think
one of these KeReleaseMutex() functions are called at IRQL greater than
Dispatch Level and my Mutex pointer is not wrong.

Well I’m not enough experienced in driver programming to understand what is
causing the BSOD, so any help would be welcome. :->

“Roddy, Mark” a écrit dans le message de
news:xxxxx@ntdev…
>
> You are running the checked build of the w2k OS, right? This is a checked
> build worker thread debug monitor.
>
> You should use .exr and .cxr windbg commands to process the exception and
> context records printed out on the debug console. This will get you inside
> the stack frame for the worker thread that barfed, and perhaps give you
some
> better clues as to the cause of the barfage.
>
> Exception handlers run outside of the faulting stack frame (that’s the
whole
> point, right.) So you rarely get an interesting stack frame from the
handler
> itself. Instead you have to use the debugger to process the exception
record
> information to recreate the offending stack. The good news is that as this
> is the checked build, you are likely to find all local variables on the
> stack and one stack frame per function call.
>
>
> =====================
> Mark Roddy
>
>
> > -----Original Message-----
> > From: Nicolas Mugnier [mailto:xxxxx@cesa.fr]
> > Sent: Thursday, December 11, 2003 9:23 AM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] Strange exception with my driver
> >
> > Hi,
> > I have a driver which uses two threads per device to send and
> > receive frames with TCP/IP.
> > I have three devices on the computer.
> > The driver works fine for a while (10 minutes to 2 hours)
> > then I get the following exception (see below).
> > However the exception doesn’t happen in my driver’s code and
> > I cannot find what could be wrong.
> >
> >
> > EXWORKER: exception in worker routine EB0D10A3(EA9F1600)
> > exception record at EB43F690
> > context record at EB43F6E0
> > Break instruction exception - code 80000003 (first chance)
> > nt!DbgBreakPoint:
> > 804aab38 cc int 3
> > kd> !analyze -v
> > Connected to Windows 2000 2195 x86 compatible target, ptr64
> > FALSE Loading Kernel Symbols
> > …
> > …
> > .
> > Loading unloaded module list
> > …
> > Loading User Symbols
> > ERROR: Module load completed but symbols could not be
> > loaded for CesaCtrlAltSup.SYS
> >
ERROR: Symbol file could not be found. Defaulted to
> > export symbols for dump_WMILIB.SYS -
> > ERROR: Module load completed but symbols could not be
> > loaded for dump_atapi.sys
> >
***********************************************************
> > ***********
> >

> > *
> > *
> > * Bugcheck Analysis
> > *
> > *
> > *
> > ************************************************
> >

> > ***
> >
> > Unknown bugcheck code (0)
> > Unknown bugcheck description
> > Arguments:
> > Arg1: 00000000
> > Arg2: 00000000
> > Arg3: 00000000
> > Arg4: 00000000
> >
> > Debugging Details:
> > ------------------
> >
> >
> > FAULTING_IP:
> > nt!DbgBreakPoint+0
> > 804aab38 cc int 3
> >
> > EXCEPTION_RECORD: ffffffff – (.exr ffffffffffffffff)
> > ExceptionAddress: 804aab38 (nt!DbgBreakPoint)
> > ExceptionCode: 80000003 (Break instruction exception)
> > ExceptionFlags: 00000000
> > NumberParameters: 3
> > Parameter[0]: 00000000
> > Parameter[1]: eb43f6e0
> > Parameter[2]: 00000000
> >
> > ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Point d’arr
> > t Un point d’arr t a t atteint.
> >
> > DEFAULT_BUCKET_ID: DRIVER_FAULT
> >
> > BUGCHECK_STR: 0x0
> >
> > LAST_CONTROL_TRANSFER: from 8041c8f5 to 804aab38
> >
> > STACK_TEXT:
> > eb43f570 8041c8f5 804010a0 00000000 eb43fd98 nt!DbgBreakPoint
> > eb43f59c 8041c81f eb0d10a3 ea9f1600 eb43f5cc
> > nt!ExpWorkerThreadFilter+0x61
> > eb43fda8 804aa09a 00000001 00000000 00000000
> > nt!ExpWorkerThread+0x191 eb43fddc 804c526a 8041c68e 00000001
> > 00000000 nt!PspSystemThreadStartup+0x54 00000000 00000000
> > 00000000 00000000 00000000 nt!KiThreadStartup+0x16
> >
> >
> > FOLLOWUP_IP:
> > nt!DbgBreakPoint+0
> > 804aab38 cc int 3
> >
> > FOLLOWUP_NAME: MachineOwner
> >
> > SYMBOL_NAME: nt!DbgBreakPoint+0
> >
> > MODULE_NAME: nt
> >
> > IMAGE_NAME: ntoskrnl.exe
> >
> > DEBUG_FLR_IMAGE_TIMESTAMP: 3ee650a8
> >
> > STACK_COMMAND: kb
> >
> > BUCKET_ID: 0x0_nt!DbgBreakPoint+0
> >
> > Followup: MachineOwner
> > ---------
> >
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> > xxxxx@stratus.com To unsubscribe send a blank email to
> > xxxxx@lists.osr.com
> >
>
>

STATUS_MUTANT_NOT_OWNED = c0000046 this ought to be a whopping big clue. See
the ddk, which in my version spake thusly:

“A mutex object can be released only by the thread currently holding the
mutex. If an attempt is made to release a mutex not held by the thread, a
bug check occurs. An attempt to release a mutex object whose current state
is signaled also causes a bug check to occur.”

You need to rethink your design. Did I ever mention that NT mutexes are evil
mutants? Consider an event lock instead.

=====================
Mark Roddy

-----Original Message-----
From: Nicolas Mugnier [mailto:xxxxx@cesa.fr]
Sent: Tuesday, December 16, 2003 9:42 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: Strange exception with my driver

OK, here is what I did and what I get:

EXWORKER: exception in worker routine EB0D10A3(EA9F1600)
exception record at EB43B690
context record at EB43B6E0
Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPoint:
804aab38 cc int 3
kd> .exr EB43B690
ExceptionAddress: 8043d5c1 (nt!KeReleaseMutant+0x00000092)
ExceptionCode: c0000046
ExceptionFlags: 00000001
NumberParameters: 0
kd> .cxr EB43B6E0
eax=c0000046 ebx=00000002 ecx=00000002 edx=00000000
esi=8141fba0 edi=814983a0
eip=8043d5c1 esp=eb43b9bc ebp=eb43b9cc iopl=0 nv up
ei ng nz na pe
nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00200282
nt!KeReleaseMutant+0x92:
8043d5c1 ff4604 inc dword ptr [esi+0x4]

I can deduce it’s KeReleaseMutant which is causing trouble.
If I 'm not wrong, KeReleaseMutant is used in
KeReleaseMutex(), right ?
My KeReleaseMutex() functions are either called in worker
threads, or in a
DispatchClose()/DispatchRead() routine or in a TDI event. So
I don’t think one of these KeReleaseMutex() functions are
called at IRQL greater than Dispatch Level and my Mutex
pointer is not wrong.

Well I’m not enough experienced in driver programming to
understand what is causing the BSOD, so any help would be welcome. :->

“Roddy, Mark” a ?crit dans le
> message de news:xxxxx@ntdev…
> >
> > You are running the checked build of the w2k OS, right? This is a
> > checked build worker thread debug monitor.
> >
> > You should use .exr and .cxr windbg commands to process the
> exception
> > and context records printed out on the debug console. This will get
> > you inside the stack frame for the worker thread that barfed, and
> > perhaps give you
> some
> > better clues as to the cause of the barfage.
> >
> > Exception handlers run outside of the faulting stack frame
> (that’s the
> whole
> > point, right.) So you rarely get an interesting stack frame from the
> handler
> > itself. Instead you have to use the debugger to process the
> exception
> record
> > information to recreate the offending stack. The good news
> is that as
> > this is the checked build, you are likely to find all local
> variables
> > on the stack and one stack frame per function call.
> >
> >
> > =====================
> > Mark Roddy
> >
> >
> > > -----Original Message-----
> > > From: Nicolas Mugnier [mailto:xxxxx@cesa.fr]
> > > Sent: Thursday, December 11, 2003 9:23 AM
> > > To: Windows System Software Devs Interest List
> > > Subject: [ntdev] Strange exception with my driver
> > >
> > > Hi,
> > > I have a driver which uses two threads per device to send and
> > > receive frames with TCP/IP.
> > > I have three devices on the computer.
> > > The driver works fine for a while (10 minutes to 2 hours) then I
> > > get the following exception (see below).
> > > However the exception doesn’t happen in my driver’s code and I
> > > cannot find what could be wrong.
> > >
> > >
> > > EXWORKER: exception in worker routine EB0D10A3(EA9F1600)
> > > exception record at EB43F690
> > > context record at EB43F6E0
> > > Break instruction exception - code 80000003 (first chance)
> > > nt!DbgBreakPoint:
> > > 804aab38 cc int 3
> > > kd> !analyze -v
> > > Connected to Windows 2000 2195 x86 compatible target, ptr64 FALSE
> > > Loading Kernel Symbols
> > > …
> > > …
> > > .
> > > Loading unloaded module list
> > > …
> > > Loading User Symbols
> > > ERROR: Module load completed but symbols could not be
> loaded for
> > > CesaCtrlAltSup.SYS
> > >
ERROR: Symbol file could not be found. Defaulted to export
> > > symbols for dump_WMILIB.SYS -
> > > ERROR: Module load completed but symbols could not be
> loaded for
> > > dump_atapi.sys
> > >
***********************************************************
> > > ***********
> > >

> > > *
> > > *
> > > * Bugcheck Analysis
> > > *
> > > *
> > > *
> > > ************************************************
> > >

> > > ***
> > >
> > > Unknown bugcheck code (0)
> > > Unknown bugcheck description
> > > Arguments:
> > > Arg1: 00000000
> > > Arg2: 00000000
> > > Arg3: 00000000
> > > Arg4: 00000000
> > >
> > > Debugging Details:
> > > ------------------
> > >
> > >
> > > FAULTING_IP:
> > > nt!DbgBreakPoint+0
> > > 804aab38 cc int 3
> > >
> > > EXCEPTION_RECORD: ffffffff – (.exr ffffffffffffffff)
> > > ExceptionAddress: 804aab38 (nt!DbgBreakPoint)
> > > ExceptionCode: 80000003 (Break instruction exception)
> > > ExceptionFlags: 00000000
> > > NumberParameters: 3
> > > Parameter[0]: 00000000
> > > Parameter[1]: eb43f6e0
> > > Parameter[2]: 00000000
> > >
> > > ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Point
> d’arr t Un
> > > point d’arr t a t atteint.
> > >
> > > DEFAULT_BUCKET_ID: DRIVER_FAULT
> > >
> > > BUGCHECK_STR: 0x0
> > >
> > > LAST_CONTROL_TRANSFER: from 8041c8f5 to 804aab38
> > >
> > > STACK_TEXT:
> > > eb43f570 8041c8f5 804010a0 00000000 eb43fd98 nt!DbgBreakPoint
> > > eb43f59c 8041c81f eb0d10a3 ea9f1600 eb43f5cc
> > > nt!ExpWorkerThreadFilter+0x61
> > > eb43fda8 804aa09a 00000001 00000000 00000000
> > > nt!ExpWorkerThread+0x191 eb43fddc 804c526a 8041c68e 00000001
> > > 00000000 nt!PspSystemThreadStartup+0x54 00000000 00000000
> 00000000
> > > 00000000 00000000 nt!KiThreadStartup+0x16
> > >
> > >
> > > FOLLOWUP_IP:
> > > nt!DbgBreakPoint+0
> > > 804aab38 cc int 3
> > >
> > > FOLLOWUP_NAME: MachineOwner
> > >
> > > SYMBOL_NAME: nt!DbgBreakPoint+0
> > >
> > > MODULE_NAME: nt
> > >
> > > IMAGE_NAME: ntoskrnl.exe
> > >
> > > DEBUG_FLR_IMAGE_TIMESTAMP: 3ee650a8
> > >
> > > STACK_COMMAND: kb
> > >
> > > BUCKET_ID: 0x0_nt!DbgBreakPoint+0
> > >
> > > Followup: MachineOwner
> > > ---------
> > >
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as:
> > > xxxxx@stratus.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@stratus.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>

Where did you find the corresponding message for c0000046 ? MSDN is so
vast…
Anyway thanks ! I found a case where I don’t check return code from
KeWaitForMutexObject() and I might indeed call KeReleaseMutex() without
owning it .

“Roddy, Mark” a écrit dans le message de
news:xxxxx@ntdev…

STATUS_MUTANT_NOT_OWNED = c0000046 this ought to be a whopping big clue. See
the ddk, which in my version spake thusly:

“A mutex object can be released only by the thread currently holding the
mutex. If an attempt is made to release a mutex not held by the thread, a
bug check occurs. An attempt to release a mutex object whose current state
is signaled also causes a bug check to occur.”

You need to rethink your design. Did I ever mention that NT mutexes are evil
mutants? Consider an event lock instead.

=====================
Mark Roddy

> -----Original Message-----
> From: Nicolas Mugnier [mailto:xxxxx@cesa.fr]
> Sent: Tuesday, December 16, 2003 9:42 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Re: Strange exception with my driver
>
> OK, here is what I did and what I get:
>
> EXWORKER: exception in worker routine EB0D10A3(EA9F1600)
> exception record at EB43B690
> context record at EB43B6E0
> Break instruction exception - code 80000003 (first chance)
> nt!DbgBreakPoint:
> 804aab38 cc int 3
> kd> .exr EB43B690
> ExceptionAddress: 8043d5c1 (nt!KeReleaseMutant+0x00000092)
> ExceptionCode: c0000046
> ExceptionFlags: 00000001
> NumberParameters: 0
> kd> .cxr EB43B6E0
> eax=c0000046 ebx=00000002 ecx=00000002 edx=00000000
> esi=8141fba0 edi=814983a0
> eip=8043d5c1 esp=eb43b9bc ebp=eb43b9cc iopl=0 nv up
> ei ng nz na pe
> nc
> cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> efl=00200282
> nt!KeReleaseMutant+0x92:
> 8043d5c1 ff4604 inc dword ptr [esi+0x4]
>
> I can deduce it’s KeReleaseMutant which is causing trouble.
> If I 'm not wrong, KeReleaseMutant is used in
> KeReleaseMutex(), right ?
> My KeReleaseMutex() functions are either called in worker
> threads, or in a
> DispatchClose()/DispatchRead() routine or in a TDI event. So
> I don’t think one of these KeReleaseMutex() functions are
> called at IRQL greater than Dispatch Level and my Mutex
> pointer is not wrong.
>
> Well I’m not enough experienced in driver programming to
> understand what is causing the BSOD, so any help would be welcome. :->
>
>
> “Roddy, Mark” a écrit dans le
> message de news:xxxxx@ntdev…
> >
> > You are running the checked build of the w2k OS, right? This is a
> > checked build worker thread debug monitor.
> >
> > You should use .exr and .cxr windbg commands to process the
> exception
> > and context records printed out on the debug console. This will get
> > you inside the stack frame for the worker thread that barfed, and
> > perhaps give you
> some
> > better clues as to the cause of the barfage.
> >
> > Exception handlers run outside of the faulting stack frame
> (that’s the
> whole
> > point, right.) So you rarely get an interesting stack frame from the
> handler
> > itself. Instead you have to use the debugger to process the
> exception
> record
> > information to recreate the offending stack. The good news
> is that as
> > this is the checked build, you are likely to find all local
> variables
> > on the stack and one stack frame per function call.
> >
> >
> > =====================
> > Mark Roddy
> >
> >
> > > -----Original Message-----
> > > From: Nicolas Mugnier [mailto:xxxxx@cesa.fr]
> > > Sent: Thursday, December 11, 2003 9:23 AM
> > > To: Windows System Software Devs Interest List
> > > Subject: [ntdev] Strange exception with my driver
> > >
> > > Hi,
> > > I have a driver which uses two threads per device to send and
> > > receive frames with TCP/IP.
> > > I have three devices on the computer.
> > > The driver works fine for a while (10 minutes to 2 hours) then I
> > > get the following exception (see below).
> > > However the exception doesn’t happen in my driver’s code and I
> > > cannot find what could be wrong.
> > >
> > >
> > > EXWORKER: exception in worker routine EB0D10A3(EA9F1600)
> > > exception record at EB43F690
> > > context record at EB43F6E0
> > > Break instruction exception - code 80000003 (first chance)
> > > nt!DbgBreakPoint:
> > > 804aab38 cc int 3
> > > kd> !analyze -v
> > > Connected to Windows 2000 2195 x86 compatible target, ptr64 FALSE
> > > Loading Kernel Symbols
> > > …
> > > …
> > > .
> > > Loading unloaded module list
> > > …
> > > Loading User Symbols
> > > ERROR: Module load completed but symbols could not be
> loaded for
> > > CesaCtrlAltSup.SYS
> > >
ERROR: Symbol file could not be found. Defaulted to export
> > > symbols for dump_WMILIB.SYS -
> > > ERROR: Module load completed but symbols could not be
> loaded for
> > > dump_atapi.sys
> > >
***********************************************************
> > > ***********
> > >

> > > *
> > > *
> > > * Bugcheck Analysis
> > > *
> > > *
> > > *
> > > ************************************************
> > >

> > > ***
> > >
> > > Unknown bugcheck code (0)
> > > Unknown bugcheck description
> > > Arguments:
> > > Arg1: 00000000
> > > Arg2: 00000000
> > > Arg3: 00000000
> > > Arg4: 00000000
> > >
> > > Debugging Details:
> > > ------------------
> > >
> > >
> > > FAULTING_IP:
> > > nt!DbgBreakPoint+0
> > > 804aab38 cc int 3
> > >
> > > EXCEPTION_RECORD: ffffffff – (.exr ffffffffffffffff)
> > > ExceptionAddress: 804aab38 (nt!DbgBreakPoint)
> > > ExceptionCode: 80000003 (Break instruction exception)
> > > ExceptionFlags: 00000000
> > > NumberParameters: 3
> > > Parameter[0]: 00000000
> > > Parameter[1]: eb43f6e0
> > > Parameter[2]: 00000000
> > >
> > > ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Point
> d’arr t Un
> > > point d’arr t a t atteint.
> > >
> > > DEFAULT_BUCKET_ID: DRIVER_FAULT
> > >
> > > BUGCHECK_STR: 0x0
> > >
> > > LAST_CONTROL_TRANSFER: from 8041c8f5 to 804aab38
> > >
> > > STACK_TEXT:
> > > eb43f570 8041c8f5 804010a0 00000000 eb43fd98 nt!DbgBreakPoint
> > > eb43f59c 8041c81f eb0d10a3 ea9f1600 eb43f5cc
> > > nt!ExpWorkerThreadFilter+0x61
> > > eb43fda8 804aa09a 00000001 00000000 00000000
> > > nt!ExpWorkerThread+0x191 eb43fddc 804c526a 8041c68e 00000001
> > > 00000000 nt!PspSystemThreadStartup+0x54 00000000 00000000
> 00000000
> > > 00000000 00000000 nt!KiThreadStartup+0x16
> > >
> > >
> > > FOLLOWUP_IP:
> > > nt!DbgBreakPoint+0
> > > 804aab38 cc int 3
> > >
> > > FOLLOWUP_NAME: MachineOwner
> > >
> > > SYMBOL_NAME: nt!DbgBreakPoint+0
> > >
> > > MODULE_NAME: nt
> > >
> > > IMAGE_NAME: ntoskrnl.exe
> > >
> > > DEBUG_FLR_IMAGE_TIMESTAMP: 3ee650a8
> > >
> > > STACK_COMMAND: kb
> > >
> > > BUCKET_ID: 0x0_nt!DbgBreakPoint+0
> > >
> > > Followup: MachineOwner
> > > ---------
> > >
> > >
> > >
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > You are currently subscribed to ntdev as:
> > > xxxxx@stratus.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@stratus.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>

You find error codes in ntstatus.h.

Mark Roddy

-----Original Message-----
From: Nicolas Mugnier [mailto:xxxxx@cesa.fr]
Sent: Tuesday, December 16, 2003 10:02 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: Strange exception with my driver

Where did you find the corresponding message for c0000046 ?
MSDN is so vast…
Anyway thanks ! I found a case where I don’t check return code from
KeWaitForMutexObject() and I might indeed call
KeReleaseMutex() without owning it .

“Roddy, Mark” a ?crit dans le
> message de news:xxxxx@ntdev…
>
> STATUS_MUTANT_NOT_OWNED = c0000046 this ought to be a
> whopping big clue. See the ddk, which in my version spake thusly:
>
> “A mutex object can be released only by the thread currently
> holding the mutex. If an attempt is made to release a mutex
> not held by the thread, a bug check occurs. An attempt to
> release a mutex object whose current state is signaled also
> causes a bug check to occur.”
>
> You need to rethink your design. Did I ever mention that NT
> mutexes are evil mutants? Consider an event lock instead.
>
>
> =====================
> Mark Roddy
>
>
> > -----Original Message-----
> > From: Nicolas Mugnier [mailto:xxxxx@cesa.fr]
> > Sent: Tuesday, December 16, 2003 9:42 AM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] Re: Strange exception with my driver
> >
> > OK, here is what I did and what I get:
> >
> > EXWORKER: exception in worker routine EB0D10A3(EA9F1600)
> > exception record at EB43B690
> > context record at EB43B6E0
> > Break instruction exception - code 80000003 (first chance)
> > nt!DbgBreakPoint:
> > 804aab38 cc int 3
> > kd> .exr EB43B690
> > ExceptionAddress: 8043d5c1 (nt!KeReleaseMutant+0x00000092)
> > ExceptionCode: c0000046
> > ExceptionFlags: 00000001
> > NumberParameters: 0
> > kd> .cxr EB43B6E0
> > eax=c0000046 ebx=00000002 ecx=00000002 edx=00000000 esi=8141fba0
> > edi=814983a0
> > eip=8043d5c1 esp=eb43b9bc ebp=eb43b9cc iopl=0 nv up
> > ei ng nz na pe
> > nc
> > cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
> > efl=00200282
> > nt!KeReleaseMutant+0x92:
> > 8043d5c1 ff4604 inc dword ptr [esi+0x4]
> >
> > I can deduce it’s KeReleaseMutant which is causing trouble.
> > If I 'm not wrong, KeReleaseMutant is used in
> KeReleaseMutex(), right
> > ?
> > My KeReleaseMutex() functions are either called in worker
> threads, or
> > in a
> > DispatchClose()/DispatchRead() routine or in a TDI event.
> So I don’t
> > think one of these KeReleaseMutex() functions are called at IRQL
> > greater than Dispatch Level and my Mutex pointer is not wrong.
> >
> > Well I’m not enough experienced in driver programming to understand
> > what is causing the BSOD, so any help would be welcome. :->
> >
> >
> > “Roddy, Mark” a ?crit dans le message de
> > news:xxxxx@ntdev…
> > >
> > > You are running the checked build of the w2k OS, right? This is a
> > > checked build worker thread debug monitor.
> > >
> > > You should use .exr and .cxr windbg commands to process the
> > exception
> > > and context records printed out on the debug console.
> This will get
> > > you inside the stack frame for the worker thread that barfed, and
> > > perhaps give you
> > some
> > > better clues as to the cause of the barfage.
> > >
> > > Exception handlers run outside of the faulting stack frame
> > (that’s the
> > whole
> > > point, right.) So you rarely get an interesting stack
> frame from the
> > handler
> > > itself. Instead you have to use the debugger to process the
> > exception
> > record
> > > information to recreate the offending stack. The good news
> > is that as
> > > this is the checked build, you are likely to find all local
> > variables
> > > on the stack and one stack frame per function call.
> > >
> > >
> > > =====================
> > > Mark Roddy
> > >
> > >
> > > > -----Original Message-----
> > > > From: Nicolas Mugnier [mailto:xxxxx@cesa.fr]
> > > > Sent: Thursday, December 11, 2003 9:23 AM
> > > > To: Windows System Software Devs Interest List
> > > > Subject: [ntdev] Strange exception with my driver
> > > >
> > > > Hi,
> > > > I have a driver which uses two threads per device to send and
> > > > receive frames with TCP/IP.
> > > > I have three devices on the computer.
> > > > The driver works fine for a while (10 minutes to 2
> hours) then I
> > > > get the following exception (see below).
> > > > However the exception doesn’t happen in my driver’s code and I
> > > > cannot find what could be wrong.
> > > >
> > > >
> > > > EXWORKER: exception in worker routine EB0D10A3(EA9F1600)
> > > > exception record at EB43F690
> > > > context record at EB43F6E0
> > > > Break instruction exception - code 80000003 (first chance)
> > > > nt!DbgBreakPoint:
> > > > 804aab38 cc int 3
> > > > kd> !analyze -v
> > > > Connected to Windows 2000 2195 x86 compatible target,
> ptr64 FALSE
> > > > Loading Kernel Symbols
> > > > …
> > > > …
> > > > .
> > > > Loading unloaded module list
> > > > …
> > > > Loading User Symbols
> > > > ERROR: Module load completed but symbols could not be
> > loaded for
> > > > CesaCtrlAltSup.SYS
> > > >
ERROR: Symbol file could not be found. Defaulted to export
> > > > symbols for dump_WMILIB.SYS -
> > > > ERROR: Module load completed but symbols could not be
> > loaded for
> > > > dump_atapi.sys
> > > >
***********************************************************
> > > > ***********
> > > >

> > > > *
> > > > *
> > > > * Bugcheck Analysis
> > > > *
> > > > *
> > > > *
> > > > ************************************************
> > > >

> > > > ***
> > > >
> > > > Unknown bugcheck code (0)
> > > > Unknown bugcheck description
> > > > Arguments:
> > > > Arg1: 00000000
> > > > Arg2: 00000000
> > > > Arg3: 00000000
> > > > Arg4: 00000000
> > > >
> > > > Debugging Details:
> > > > ------------------
> > > >
> > > >
> > > > FAULTING_IP:
> > > > nt!DbgBreakPoint+0
> > > > 804aab38 cc int 3
> > > >
> > > > EXCEPTION_RECORD: ffffffff – (.exr ffffffffffffffff)
> > > > ExceptionAddress: 804aab38 (nt!DbgBreakPoint)
> > > > ExceptionCode: 80000003 (Break instruction exception)
> > > > ExceptionFlags: 00000000
> > > > NumberParameters: 3
> > > > Parameter[0]: 00000000
> > > > Parameter[1]: eb43f6e0
> > > > Parameter[2]: 00000000
> > > >
> > > > ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Point
> > d’arr t Un
> > > > point d’arr t a t atteint.
> > > >
> > > > DEFAULT_BUCKET_ID: DRIVER_FAULT
> > > >
> > > > BUGCHECK_STR: 0x0
> > > >
> > > > LAST_CONTROL_TRANSFER: from 8041c8f5 to 804aab38
> > > >
> > > > STACK_TEXT:
> > > > eb43f570 8041c8f5 804010a0 00000000 eb43fd98 nt!DbgBreakPoint
> > > > eb43f59c 8041c81f eb0d10a3 ea9f1600 eb43f5cc
> > > > nt!ExpWorkerThreadFilter+0x61
> > > > eb43fda8 804aa09a 00000001 00000000 00000000
> > > > nt!ExpWorkerThread+0x191 eb43fddc 804c526a 8041c68e 00000001
> > > > 00000000 nt!PspSystemThreadStartup+0x54 00000000 00000000
> > 00000000
> > > > 00000000 00000000 nt!KiThreadStartup+0x16
> > > >
> > > >
> > > > FOLLOWUP_IP:
> > > > nt!DbgBreakPoint+0
> > > > 804aab38 cc int 3
> > > >
> > > > FOLLOWUP_NAME: MachineOwner
> > > >
> > > > SYMBOL_NAME: nt!DbgBreakPoint+0
> > > >
> > > > MODULE_NAME: nt
> > > >
> > > > IMAGE_NAME: ntoskrnl.exe
> > > >
> > > > DEBUG_FLR_IMAGE_TIMESTAMP: 3ee650a8
> > > >
> > > > STACK_COMMAND: kb
> > > >
> > > > BUCKET_ID: 0x0_nt!DbgBreakPoint+0
> > > >
> > > > Followup: MachineOwner
> > > > ---------
> > > >
> > > >
> > > >
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > You are currently subscribed to ntdev as:
> > > > xxxxx@stratus.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@stratus.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@stratus.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>