Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

Debugging aspnet_wp.exe dump

66 views

Skip to first unread message

Cheung, Jeffrey Jing-Yen

unread,

Jul 1, 2003, 6:47:48 PM7/1/03

Before I get to my question, here is some background info.

My previous experience in windbg is very minimal. I usually only use it
when I get a dump during a BSOD to see what conflicts occurred. I am a
master at !analyze -v only when symbols are correctly loaded, as it
usually points me directly to the source of the problem.

Recently, an ASP.NET application has been consistently deadlocking in a
production environment. MS states that I will have to produce a dump
file, and debug in order to pinpoint exactly where this deadlock is
taking place. I have accomplished in getting a dmp file per MS's
instructions, but I can't make heads or tails out of it. A lot of the
.NET assemblies have symbols readily available in their respective bin
folders, but they don't seem to be loaded.

My actual question is, how do I find exactly what is going rogue? From
what very little I've read, ASPNET has multiple threads, and usually in
a deadlock scenario, these threads are all waiting on each other. I'm
not certain how to go about finding this problem. Also, will the
functionality of loading the .NET assembly symbols benefit me at all
while debugging, or is it pointless? If it will be beneficial, how do I
do this?

Thanks in advance for any replies.

Jeff Cheung

Ivan Brugiolo [MSFT]

unread,

Jul 1, 2003, 10:44:19 PM7/1/03

Start from the output of the '~*kb' command.
Look at the top function in the stack, and identify what are the threads
waiting for.

You may find threads waiting on Window Messages
(normally the message pump of an STA thread),
you may find thread in the LPC WaitReceiveReplay state (RPC worker threads),
you may find threads doing an explicit wait on an event,
or you may find threads waiting on Critical Sections.

I would attack the critical section first,
even if I would suspect an STA/MTA deadlock
given the generic cisrcumstances.

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Cheung, Jeffrey Jing-Yen" <jin...@emailREMOVEMEuser.net> wrote in message
news:#BIbLLCQ...@TK2MSFTNGP10.phx.gbl...

Cheung, Jeffrey Jing-Yen

unread,

Jul 2, 2003, 12:20:03 PM7/2/03

Ivan,

First of all, I appreciate your response. I am not that familiar with
the debugging environment, and this is something that I want to rectify
over time.

From the looks of things, it seems that all the threads are waiting for
the GC (garbage collector). The top of the stack for most threads read:

NTDLL!NtWaitForSingleObject
KERNEL32!WaitForSingleObject
mscorwks!GCHeap::WaitUntilGCComplete

Is this normal behavior? Is it safe to assume that the Garbage
Collector has already attempted to clean up things, and the processes
are just waiting for it to finish?

Confused,

Jeff Cheung

Ivan Brugiolo [MSFT]

unread,

Jul 2, 2003, 1:56:09 PM7/2/03

There should be one thread performing garbage collection,
and all the others executing managed code are expected to be waiting
in selected "safe" points till the collection has completed.

Could you just report the output of '~*kb' ?

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Cheung, Jeffrey Jing-Yen" <jin...@emailREMOVEMEuser.net> wrote in message

news:#6X8OXLQ...@tk2msftngp13.phx.gbl...

Paul Wehland

unread,

Jul 3, 2003, 2:43:16 PM7/3/03

We encountered the same hang. Although I do not have the entire
stack, I do have the threads that were deadlocking:

. 0 Id: 36c.170 Suspend: 1 Teb: 7ffde000 Unfrozen
ChildEBP RetAddr Args to Child
0012f660 77e962ce 000000cc 00000000 00000000 ntdll!NtWriteFile+0xb
0012f6cc 0044291e 000000cc 0012f6f4 00000000 KERNEL32!WriteFile+0x111
0012f700 00442eb1 77ea9d54 00442e06 00000000
aspnet_wp!CSyncPipeManager::Ping+0x4c
0012f708 00442e06 00000000 00fcdcb4 7ffdf000 aspnet_wp!TestPipes+0x27
0012ff60 0044408d 00000000 002f3770 002f41f0 aspnet_wp!wmain+0x3b7
0012ffc0 77ea847c 7ffd6000 00fcdcb4 7ffdf000
aspnet_wp!wmainCRTStartup+0x143
0012fff0 00000000 00443f4a 00000000 000000c8
KERNEL32!BaseProcessStart+0x3d

1 Id: 36c.700 Suspend: 1 Teb: 7ffdd000 Unfrozen
ChildEBP RetAddr Args to Child
00b6f910 77e96156 000000c8 00000000 00000000 ntdll!ZwReadFile+0xb
00b6f984 0044288e 000000c8 00501e90 00000019 KERNEL32!ReadFile+0x181
00b6f9b8 004425ef 00502d38 00501e90 00000000
aspnet_wp!CSyncPipeManager::SendSyncMessage+0x7a
00b6f9e0 004439ea 0000000b 00000001 00000002
aspnet_wp!CSyncPipeManager::GetDataFromIIS+0xab
00b6fa04 00dcabad 00504e98 00000002 0cfd5a5c
aspnet_wp!PMCallISAPI+0x36

Our workaround was to run the appliction at a higher protection level
than Low. The interesting thing is that aspnet_wp.exe did not
deadlock when a debugger was attached, we had to hang first then
attach cdb to discover the pipe that aspnet_wp was deadlocking on. I
do not think Microsoft has a fix for this bug yet, but you can
workaround it by not running at low protection level.

--
Paul Wehland

"Ivan Brugiolo [MSFT]" <ivan...@online.microsoft.com> wrote in message news:<u7KX3MMQ...@tk2msftngp13.phx.gbl>...

Cheung, Jeffrey Jing-Yen

unread,

Jul 4, 2003, 1:54:41 AM7/4/03

Paul,

The site is actaully running in High Isolation mode now, and it still
deadlocks unfortunately... :(

Cheung, Jeffrey Jing-Yen

unread,

Jul 4, 2003, 1:59:07 AM7/4/03

Ivan,

I will glady provide the output. I hope you can help me decipher this
as this is my first time *truly* reading debugger info.

0:012> ~*kb

0 Id: 12c.4f4 Suspend: 1 Teb: 7ffde000 Unfrozen