Asp.net WinDBG w3wp.exe x64挂起转储错误的\u符号
我正在分析在IIS 7.5、Windows 2008 R2 64中的64位ASP.NET v4.0应用程序池下运行的挂起ASP.NET MVC网站问题。我通过taskmgr进行了转储,并在Windows 7 64位上的WinDBG x64中进行分析 当运行Asp.net WinDBG w3wp.exe x64挂起转储错误的\u符号,asp.net,iis,64-bit,windbg,Asp.net,Iis,64 Bit,Windbg,我正在分析在IIS 7.5、Windows 2008 R2 64中的64位ASP.NET v4.0应用程序池下运行的挂起ASP.NET MVC网站问题。我通过taskmgr进行了转储,并在Windows 7 64位上的WinDBG x64中进行分析 当运行时!analyze-v我看到错误错误的\u符号和错误检查\u STR:APPLICATION\u FAULT\u error\u符号。这阻碍了我的调试,因为我无法检查一些需要调查死锁的线程 详细信息 我的符号服务器是SRV*D:\下载的符号*h
时!analyze-v
我看到错误错误的\u符号
和错误检查\u STR:APPLICATION\u FAULT\u error\u符号
。这阻碍了我的调试,因为我无法检查一些需要调查死锁的线程
详细信息
我的符号服务器是SRV*D:\下载的符号*http://msdl.microsoft.com/download/symbols
我已删除此本地文件夹,并允许从m$下载所有符号
我已使用加载sos。加载方式为sos clr
从输出!分析-v
:
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
FAULTING_IP:
+0
00000000`00000000 ?? ???
EXCEPTION_RECORD: ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 0000000000000000
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 0
FAULTING_THREAD: 0000000000000544
DEFAULT_BUCKET_ID: WRONG_SYMBOLS
PROCESS_NAME: w3wp.exe
ERROR_CODE: (NTSTATUS) 0x80000003 - {EXCEPTION} Breakpoint A breakpoint has been reached.
EXCEPTION_CODE: (HRESULT) 0x80000003 (2147483651) - One or more arguments are invalid
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
APP: w3wp.exe
MANAGED_STACK: !dumpstack -EE
OS Thread Id: 0x944 (15)
Current frame:
Child-SP RetAddr Caller, Callee
PRIMARY_PROBLEM_CLASS: WRONG_SYMBOLS
BUGCHECK_STR: APPLICATION_FAULT_WRONG_SYMBOLS
LAST_CONTROL_TRANSFER: from 000007fefd8910dc to 000000007712135a
STACK_TEXT:
00000000`000afac8 000007fe`fd8910dc : 00000000`00000000 00000000`00000000 000007fe`f9921630 000007fe`fadb7f66 : ntdll!NtWaitForSingleObject+0xa
00000000`000afad0 000007fe`f99241bc : 00000000`00000000 00000000`ffaf6de0 00000000`00000000 00000000`00000128 : KERNELBASE!WaitForSingleObjectEx+0x79
00000000`000afb70 00000000`ffaf3c60 : 00000000`fffffffe 00000000`00415f90 00000000`ffaf4588 000007fe`f9920000 : w3wphost!AppHostInitialize+0x278
00000000`000afbd0 00000000`ffaf11f1 : 00000000`00000000 00000000`ffaf1351 00000000`00000000 000003fd`deed0e35 : w3wp!wmain+0x470
00000000`000afd60 00000000`76e6652d : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : w3wp!PerfStopProvider+0x19b
00000000`000afda0 00000000`770fc521 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd
00000000`000afdd0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d
STACK_COMMAND: ~0s; .ecxr ; kb
FOLLOWUP_IP:
w3wphost!AppHostInitialize+278
000007fe`f99241bc f605e1b4000003 test byte ptr [w3wphost!g_dwDebugFlags (000007fe`f992f6a4)],3
SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: w3wphost!AppHostInitialize+278
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: w3wphost
IMAGE_NAME: w3wphost.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 4ce7c9ef
FAILURE_BUCKET_ID: WRONG_SYMBOLS_80000003_w3wphost.dll!AppHostInitialize
BUCKET_ID: X64_APPLICATION_FAULT_WRONG_SYMBOLS_w3wphost!AppHostInitialize+278
WATSON_STAGEONE_URL: http://watson.microsoft.com/StageOne/w3wp_exe/7_5_7601_17514/4ce7afa2/unknown/0_0_0_0/bbbbbbb4/80000003/00000000.htm?Retriage=1
Followup: MachineOwner
---------
从.chain
输出:
Extension DLL search Path:
C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\WINXP;C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\winext;C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\winext\arcade;C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\pri;C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64;C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\winext\arcade;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\;C:\Program Files\Microsoft SQL Server\100\Tools\Binn\;C:\Program Files\Microsoft SQL Server\100\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\;C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\;C:\Program Files (x86)\Intel\Services\IPT\;C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\;C:\Program Files (x86)\Microsoft Team Foundation Server 2012 Power Tools\;C:\Program Files (x86)\Microsoft Team Foundation Server 2012 Power Tools\Best Practices Analyzer\;C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files\Microsoft SQL Server\110\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\;C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn\;C:\Program Files\Microsoft\Web Platform Installer\;C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET Web Pages\v1.0\;C:\Program Files (x86)\Windows Kits\8.0\Windows Performance Toolkit\
Extension DLL chain:
D:\DOWNLOADEDSYMBOLS\sos_AMD64_AMD64_4.0.30319.18034.dll\50B5A78395e000\sos_AMD64_AMD64_4.0.30319.18034.dll: image 4.0.30319.18034, API 1.0.0, built Wed Nov 28 18:45:59 2012
[path: D:\DOWNLOADEDSYMBOLS\sos_AMD64_AMD64_4.0.30319.18034.dll\50B5A78395e000\sos_AMD64_AMD64_4.0.30319.18034.dll]
sosex: image 4.5.0.0, API 1.0.0, built Thu Oct 04 03:57:55 2012
[path: C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\sosex.dll]
D:DOWNLOADEDSYMBOLS\sos_AMD64_AMD64_4.0.30319.18034.dll\50B5A78395e000\sos_AMD64_AMD64_4.0.30319.18034.dll: image 4.0.30319.18034, API 1.0.0, built Wed Nov 28 18:45:59 2012
[path: D:\DOWNLOADEDSYMBOLS\sos_AMD64_AMD64_4.0.30319.18034.dll\50B5A78395e000\sos_AMD64_AMD64_4.0.30319.18034.dll]
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos: image 4.0.30319.18034, API 1.0.0, built Wed Nov 28 18:45:59 2012
[path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos.dll]
dbghelp: image 6.2.9200.20512, API 6.2.6, built Fri Sep 07 17:45:49 2012
[path: C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\dbghelp.dll]
ext: image 6.2.9200.20522, API 1.0.0, built Fri Sep 21 20:17:05 2012
[path: C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\winext\ext.dll]
exts: image 6.2.9200.16384, API 1.0.0, built Thu Jul 26 14:15:20 2012
[path: C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\WINXP\exts.dll]
uext: image 6.2.9200.16384, API 1.0.0, built Thu Jul 26 14:15:09 2012
[path: C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\winext\uext.dll]
ntsdexts: image 6.2.9200.16384, API 1.0.0, built Thu Jul 26 14:16:01 2012
[path: C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64\WINXP\ntsdexts.dll]
从输出。用重新加载!sym噪音
DBGHELP: ntdll - public symbols
d:\downloadedsymbols\ntdll.pdb\15EB43E23B12409C84E3CC7635BAF5A32\ntdll.pdb
..............................................................
DBGHELP: KERNELBASE - public symbols
d:\downloadedsymbols\kernelbase.pdb\91C72371DD43448192B7B46F5ED10AA02\kernelbase.pdb
死锁分析
线程列表
从输出!线程
:
ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Lock Count Apt Exception
7 1 7a8 0000000001f92a50 28220 Preemptive 0000000000000000:0000000000000000 000000000119ee70 0 Ukn
13 2 1764 0000000001fa9fb0 2b220 Preemptive 0000000102D5DCC8:0000000102D5F7E8 000000000119ee70 0 MTA (Finalizer)
15 3 944 0000000001ffa010 102a220 Preemptive 0000000000000000:0000000000000000 000000000119ee70 0 MTA (Threadpool Worker)
16 4 bb0 0000000002006ec0 21220 Preemptive 0000000000000000:0000000000000000 000000000119ee70 0 Ukn
6 15 1018 00000000086704d0 20220 Preemptive 0000000000000000:0000000000000000 000000000119ee70 0 Ukn
35 16 12e4 00000000098fc820 202b220 Preemptive 000000010400E5A0:00000001040102B0 0000000002005e90 1 MTA
……等等
从输出!dlk
:
*DEADLOCK DETECTED*
CLR thread 0x15 holds the lock on SyncBlock 0000000009913cf8 OBJ:00000000ffe31898
[System.Collections.Generic.Dictionary``2[[System.String, mscorlib],[System.Resources.ResourceLocator, mscorlib]]]
...and is waiting for the lock on SyncBlock 0000000009913ca8 OBJ:00000000ffe318e8[System.Resources.ResourceReader]
CLR thread 0x16 holds the lock on SyncBlock 0000000009913ca8 OBJ:00000000ffe318e8[System.Resources.ResourceReader]
...and is waiting for the lock on SyncBlock 0000000009913cf8 OBJ:00000000ffe31898
[System.Collections.Generic.Dictionary``2[[System.String, mscorlib],[System.Resources.ResourceLocator, mscorlib]]]
CLR Thread 0x15 is waiting at System.Resources.ResourceReader.AllocateStringForNameIndex(Int32, Int32 ByRef)(+0x17 IL,+0xc9 Native)
CLR Thread 0x16 is waiting at System.Resources.RuntimeResourceSet.GetObject(System.String, Boolean, Boolean)(+0xee IL,+0x375 Native)
螺纹15的分析
从~6s
输出:
ntdll!ZwDelayExecution+0xa:
00000000`771213aa c3 ret
。。然后从输出!clrstack
:
OS Thread Id: 0x1018 (6)
Child SP IP Call Site
GetFrameContext failed: 1
0000000000000000 0000000000000000 <unknown>
OS Thread Id: 0x12e4 (35)
Child SP IP Call Site
000000000cc9e188 00000000771218ca [HelperMethodFrame_1OBJ: 000000000cc9e188] System.Threading.WaitHandle.WaitMultiple(System.Threading.WaitHandle[], Int32, Boolean, Boolean)
000000000cc9e2c0 000007fef65e562c System.Threading.WaitHandle.WaitAny(System.Threading.WaitHandle[], Int32, Boolean)
000000000cc9e320 000007fef5670d06 System.Net.TimerThread.ThreadProc()
000000000cc9e3f0 000007fef65a0a05 System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
000000000cc9e550 000007fef65a0769 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
000000000cc9e580 000007fef65a0727 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
000000000cc9e5d0 000007fef65b3e81 System.Threading.ThreadHelper.ThreadStart()
000000000cc9e8e8 000007fef9ec07f3 [GCFrame: 000000000cc9e8e8]
000000000cc9ec18 000007fef9ec07f3 [DebuggerU2MCatchHandlerFrame: 000000000cc9ec18]
000000000cc9edf8 000007fef9ec07f3 [ContextTransitionFrame: 000000000cc9edf8]
000000000cc9efe8 000007fef9ec07f3 [DebuggerU2MCatchHandlerFrame: 000000000cc9efe8]
从输出!clrstack
:
OS Thread Id: 0x1018 (6)
Child SP IP Call Site
GetFrameContext failed: 1
0000000000000000 0000000000000000 <unknown>
OS Thread Id: 0x12e4 (35)
Child SP IP Call Site
000000000cc9e188 00000000771218ca [HelperMethodFrame_1OBJ: 000000000cc9e188] System.Threading.WaitHandle.WaitMultiple(System.Threading.WaitHandle[], Int32, Boolean, Boolean)
000000000cc9e2c0 000007fef65e562c System.Threading.WaitHandle.WaitAny(System.Threading.WaitHandle[], Int32, Boolean)
000000000cc9e320 000007fef5670d06 System.Net.TimerThread.ThreadProc()
000000000cc9e3f0 000007fef65a0a05 System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
000000000cc9e550 000007fef65a0769 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
000000000cc9e580 000007fef65a0727 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
000000000cc9e5d0 000007fef65b3e81 System.Threading.ThreadHelper.ThreadStart()
000000000cc9e8e8 000007fef9ec07f3 [GCFrame: 000000000cc9e8e8]
000000000cc9ec18 000007fef9ec07f3 [DebuggerU2MCatchHandlerFrame: 000000000cc9ec18]
000000000cc9edf8 000007fef9ec07f3 [ContextTransitionFrame: 000000000cc9edf8]
000000000cc9efe8 000007fef9ec07f3 [DebuggerU2MCatchHandlerFrame: 000000000cc9efe8]
忽略那个错误!analyze-v只对崩溃转储有用(我相信除了崩溃转储之外,还有一些参数可以传递给它)。据报道,“崩溃”的原因是一个调试点被击中。这是正确的,因为当您转储一个进程时,它会向该进程注入一个线程,并导致一个断点被命中,然后转储该进程的内存。因此,分析告诉你的是,“崩溃”的原因是一个断点被击中。可以放心地忽略它。当您去查看线程时,应该能够看到所有线程。其他一切都应该正常工作。我想你只是误解了的输出!blk
命令,它为我们提供了有问题线程的CLR线程ID,而不是它们的序号(这是~s
命令所期望的)。
要获得这两个线程的序号,可以使用的输出!线程
命令
从你的例子来看:
ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Lock Count Apt Exception
7 1 7a8 0000000001f92a50 28220 Preemptive 0000000000000000:0000000000000000 000000000119ee70 0 Ukn
7是序号,0x1是CLR线程ID,0x7a8是OS线程ID,您的符号看起来不错。你能从~*e获得好的线程堆栈吗!clrstack
?是的,有很多线程。有问题的僵局不会很好地恢复!尽管如此。GetContext失败:1?像这样的。我会在周一为你得到正确的输出-谢谢。马克,我已经编辑了原始文章。请检查上面的死锁分析部分。您可以从中看到线程分析!clrstack
显示GetFrameContext失败:1
。我可以向您展示~*e!的全部输出!clrstack
但是有很多线程需要查看。Hi Rots。我也有类似的问题。您是否能够弄清导致应用程序挂起的原因。任何关于如何弄清这一点的提示和见解都将不胜感激。@Yoismel这是很久以前的事了,但根据记忆,我们在每次点击Web服务时都会读6次配置文件。除非在启动时,否则不要从文件系统中读取!:)谢谢你。不幸的是,我的死锁线程在使用时无法返回任何有用的东西!clrstack,因此我发布了这个。一旦我确认了这一点,我可能会接受你的回答。我将在周一发布更多信息。Zipper-有关更多信息,请参阅原始帖子中的死锁分析部分。从您的回答来看,GetFrameContext失败:1
与符号的加载无关,并且原始问题中发布的错误非常好,因为它正在加载崩溃转储。谢谢,我已相应地更新了原始帖子。第二个线程提供了更有趣的信息,但第一个线程仍然显示GetFrameContext失败:1
@Rots!blk已经显示了两个线程的死锁。您应该分析它们的调用堆栈,看看它们是如何相互锁定的。那么你应该学会防止死锁。@LexLi谢谢。我已经通过进行了分析!clrstack
还有其他方法吗?@Rots,如果不访问转储,很难说。例如,使用k
命令及其变体可以看到本机调用堆栈。如果您不熟悉转储分析,请尝试通过@LexLi打开支持案例谢谢您的建议,我将尝试使用k命令。我对联系微软不感兴趣,因为我想在这方面进一步学习。