can anyone help me in understanding the problem

nayan_Kumar · January 28, 2008, 6:17am

Hi All,

can anyone help me in understanding the problem based on the following output that i am getting after issuing !analyze -v cmd in windbg.

In the following result Module name is Nt that is making me confuse.

Is it the problem of operating system.

I am trying to terminate the thread in my driver and as i am signaling the event i am getting the blue screen.

******************************************************************************** ** Bugcheck Analysis ** ********************************************************************************
THREAD_TERMINATE_HELD_MUTEX (4000008a)A driver acquired a mutex on a thread that exited before themutex could be released. This can be caused by a driver returningto user mode without releasing a mutex or by a driver acquiring amutex and then causing an exception that results in the thread itis running on being terminated. Look at the callstack. If there isa driver on the stack that is directly followed by system exceptionhandling routines and then thread termination routines, this driveris at fault and needs to be fixed so that it does not cause anunhandled exception while holding a kernel mutex. If the stack justshows normal thread termination code and no driver is implicated, run!pool or ‘ln’ on the address of the mutex (parameter 2) and see if youcan discover who owns the it. This bug will almost certainly be in thecode of the owner of that mutex.Arguments:Arg1: 85feaa18, The address of the KTHREAD that owns the KMUTEX.Arg2: 85b8a6d8, The address of the KMUTEX that is owned.Arg3: 00000000Arg4: 00000000
Debugging Details:------------------

BUGCHECK_STR: 0x4000008a_9
DEFAULT_BUCKET_ID: DRIVER_FAULT
PROCESS_NAME: System
LAST_CONTROL_TRANSFER: from 804f8dd9 to 8052a980
STACK_TEXT: a9a1e890 804f8dd9 00000003 a9a1ebec 00000000 nt!RtlpBreakWithStatusInstructiona9a1e8dc 804f99c4 00000003 85feaa18 85feaa28 nt!KiBugCheckDebugBreak+0x19a9a1ecbc 804f9f13 4000008a 85feaa18 85b8a6d8 nt!KeBugCheck2+0x574a9a1ecdc 804fd202 4000008a 85feaa18 85b8a6d8 nt!KeBugCheckEx+0x1ba9a1ed04 805d0f3d 85feaa18 85feac60 00000000 nt!KeRundownThread+0x78a9a1ed88 805d130e 00000000 00000000 85feaa18 nt!PspExitThread+0x413a9a1eda8 805cea14 85feaa18 00000000 00000000 nt!PspTerminateThreadByPointer+0x52a9a1eddc 8054546e a8fc5350 85b80000 00000000 nt!PspSystemThreadStartup+0x4000000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
STACK_COMMAND: kb
FOLLOWUP_IP: nt!KeRundownThread+78804fd202 cc int 3
SYMBOL_STACK_INDEX: 4
SYMBOL_NAME: nt!KeRundownThread+78
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrpamp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 45e5484a
FAILURE_BUCKET_ID: 0x4000008a_9_nt!KeRundownThread+78
BUCKET_ID: 0x4000008a_9_nt!KeRundownThread+78
Followup: MachineOwner
Regards

Post ads for free - to sell, rent or even buy.www.yello.in
http://ss1.richmedia.in/recurl.asp?pid=186

OSR_Community_User · January 28, 2008, 6:24am

I’m not entirely sure what you are asking. If it’s what is ‘nt,’ then,
yes, it is the generic name used for whatever version of ntoskrnl.exe
(ntkrpamp.exe, et. c.) the os is currently using.

Good luck,

mm

nayan kumar wrote:

Hi All,

can anyone help me in understanding the problem based on the
following output that i am getting after issuing !analyze -v cmd in windbg.

In the following result Module name is Nt that is making me confuse.

Is it the problem of operating system.

I am trying to terminate the thread in my driver and as i am signaling
the event i am getting the blue screen.

*******************************************************************************
*
*
* Bugcheck
Analysis *
*
*
*******************************************************************************
THREAD_TERMINATE_HELD_MUTEX (4000008a)
A driver acquired a mutex on a thread that exited before the
mutex could be released. This can be caused by a driver returning
to user mode without releasing a mutex or by a driver acquiring a
mutex and then causing an exception that results in the thread it
is running on being terminated. Look at the callstack. If there is
a driver on the stack that is directly followed by system exception
handling routines and then thread termination routines, this driver
is at fault and needs to be fixed so that it does not cause an
unhandled exception while holding a kernel mutex. If the stack just
shows normal thread termination code and no driver is implicated, run
!pool or ‘ln’ on the address of the mutex (parameter 2) and see if you
can discover who owns the it. This bug will almost certainly be in the
code of the owner of that mutex.
Arguments:
Arg1: 85feaa18, The address of the KTHREAD that owns the KMUTEX.
Arg2: 85b8a6d8, The address of the KMUTEX that is owned.
Arg3: 00000000
Arg4: 00000000
Debugging Details:

BUGCHECK_STR: 0x4000008a_9
DEFAULT_BUCKET_ID: DRIVER_FAULT
PROCESS_NAME: System
LAST_CONTROL_TRANSFER: from 804f8dd9 to 8052a980
STACK_TEXT:
a9a1e890 804f8dd9 00000003 a9a1ebec 00000000
nt!RtlpBreakWithStatusInstruction
a9a1e8dc 804f99c4 00000003 85feaa18 85feaa28 nt!KiBugCheckDebugBreak+0x19
a9a1ecbc 804f9f13 4000008a 85feaa18 85b8a6d8 nt!KeBugCheck2+0x574
a9a1ecdc 804fd202 4000008a 85feaa18 85b8a6d8 nt!KeBugCheckEx+0x1b
a9a1ed04 805d0f3d 85feaa18 85feac60 00000000 nt!KeRundownThread+0x78
a9a1ed88 805d130e 00000000 00000000 85feaa18 nt!PspExitThread+0x413
a9a1eda8 805cea14 85feaa18 00000000 00000000
nt!PspTerminateThreadByPointer+0x52
a9a1eddc 8054546e a8fc5350 85b80000 00000000 nt!PspSystemThreadStartup+0x40
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb
FOLLOWUP_IP:
nt!KeRundownThread+78
804fd202 cc int 3
SYMBOL_STACK_INDEX: 4
SYMBOL_NAME: nt!KeRundownThread+78
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrpamp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 45e5484a
FAILURE_BUCKET_ID: 0x4000008a_9_nt!KeRundownThread+78
BUCKET_ID: 0x4000008a_9_nt!KeRundownThread+78
Followup: MachineOwner

Regards

Post free auto ads on Yello Classifieds now! Try it now!
http:</http:>

OSR_Community_User · January 28, 2008, 6:51am

As Martin pointed out, NT is the kernel. However, 99.9% of the time this is a problem
with your driver. Windbg’s analyze -v is only accurate about 70% of the time, and especially
when you see a core system file as the cause of the bug-check - this is just about
always wrong.

This is a key indicator that something in your driver is stepping on the system’s memory
area. If this only happens with your driver installed, your driver is pulling a ‘hit and run’ on
some important portion of memory.

If the bug check changes between crashes, that is definitely memory corruption from a pointer
going astray usually.

If the bug-check remains constant, I’d recommend you look at your memory pool allocations vs.
the size of the data your putting in there.

I would hope you were running your test with ‘Driver Verifier’ enabled and building with SDV. These two tool, depending on the type of error may pin-point the problem for you.

Regards,

Matt

----- Original Message -----
From: nayan kumar
To: Windows System Software Devs Interest List
Sent: Monday, January 28, 2008 5:16 AM
Subject: [ntdev] can anyone help me in understanding the problem

Hi All,

can anyone help me in understanding the problem based on the following output that i am getting after issuing !analyze -v cmd in windbg.

In the following result Module name is Nt that is making me confuse.

Is it the problem of operating system.

I am trying to terminate the thread in my driver and as i am signaling the event i am getting the blue screen.

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
THREAD_TERMINATE_HELD_MUTEX (4000008a)
A driver acquired a mutex on a thread that exited before the
mutex could be released. This can be caused by a driver returning
to user mode without releasing a mutex or by a driver acquiring a
mutex and then causing an exception that results in the thread it
is running on being terminated. Look at the callstack. If there is
a driver on the stack that is directly followed by system exception
handling routines and then thread termination routines, this driver
is at fault and needs to be fixed so that it does not cause an
unhandled exception while holding a kernel mutex. If the stack just
shows normal thread termination code and no driver is implicated, run
!pool or ‘ln’ on the address of the mutex (parameter 2) and see if you
can discover who owns the it. This bug will almost certainly be in the
code of the owner of that mutex.
Arguments:
Arg1: 85feaa18, The address of the KTHREAD that owns the KMUTEX.
Arg2: 85b8a6d8, The address of the KMUTEX that is owned.
Arg3: 00000000
Arg4: 00000000
Debugging Details:

BUGCHECK_STR: 0x4000008a_9
DEFAULT_BUCKET_ID: DRIVER_FAULT
PROCESS_NAME: System
LAST_CONTROL_TRANSFER: from 804f8dd9 to 8052a980
STACK_TEXT:
a9a1e890 804f8dd9 00000003 a9a1ebec 00000000 nt!RtlpBreakWithStatusInstruction
a9a1e8dc 804f99c4 00000003 85feaa18 85feaa28 nt!KiBugCheckDebugBreak+0x19
a9a1ecbc 804f9f13 4000008a 85feaa18 85b8a6d8 nt!KeBugCheck2+0x574
a9a1ecdc 804fd202 4000008a 85feaa18 85b8a6d8 nt!KeBugCheckEx+0x1b
a9a1ed04 805d0f3d 85feaa18 85feac60 00000000 nt!KeRundownThread+0x78
a9a1ed88 805d130e 00000000 00000000 85feaa18 nt!PspExitThread+0x413
a9a1eda8 805cea14 85feaa18 00000000 00000000 nt!PspTerminateThreadByPointer+0x52
a9a1eddc 8054546e a8fc5350 85b80000 00000000 nt!PspSystemThreadStartup+0x40
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND: kb
FOLLOWUP_IP:
nt!KeRundownThread+78
804fd202 cc int 3
SYMBOL_STACK_INDEX: 4
SYMBOL_NAME: nt!KeRundownThread+78
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nt
IMAGE_NAME: ntkrpamp.exe
DEBUG_FLR_IMAGE_TIMESTAMP: 45e5484a
FAILURE_BUCKET_ID: 0x4000008a_9_nt!KeRundownThread+78
BUCKET_ID: 0x4000008a_9_nt!KeRundownThread+78
Followup: MachineOwner

Regards

Post free auto ads on Yello Classifieds now! Try it now!

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

Tim_Roberts · January 28, 2008, 5:19pm

nayan kumar wrote:

can anyone help me in understanding the problem based on the
following output that i am getting after issuing !analyze -v cmd in
windbg.

In the following result Module name is Nt that is making me confuse.

Is it the problem of operating system.

I am trying to terminate the thread in my driver and as i am signaling
the event i am getting the blue screen.

Did you read the description? This is one of the most helpful bugcheck
descriptions there is. The problem is almost certainly that your thread
grabbed a mutex, but didn’t release it before calling
PsTerminateSystemThread.

Perhaps you should show us the code in the thread.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.