1. 首頁
  2. 問答
  3. WinDBG w3wp.exe x64掛起轉儲WRONG_SYMBOLS

WinDBG w3wp.exe x64掛起轉儲WRONG_SYMBOLS

2013-04-10 25 views
2

我正在分析IIS 7.5，Windows 2008 R2 64中64位ASP.NET v4.0 AppPool下掛起的ASP.NET MVC網站問題。我通過taskmgr進行了轉儲，並在Windows 7 64bit上的WinDBG x64中進行分析。WinDBG w3wp.exe x64掛起轉儲WRONG_SYMBOLS

當運行!analyze -v時，我看到錯誤WRONG_SYMBOLS和BUGCHECK_STR: APPLICATION_FAULT_WRONG_SYMBOLS。這阻礙了我的調試，因爲我無法檢查一些需要調查死鎖的線程。

詳細

我的符號服務器是SRV*D:\DOWNLOADEDSYMBOLS*http://msdl.microsoft.com/download/symbols 我已經刪除了這個本地文件夾，並允許所有的符號是從M $下載。

我已加載SOS與.loadby sos clr

輸出從!analyze -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]

輸出從.reload!sym noisy與

DBGHELP: ntdll - public symbols 
     d:\downloadedsymbols\ntdll.pdb\15EB43E23B12409C84E3CC7635BAF5A32\ntdll.pdb 
.............................................................. 
DBGHELP: KERNELBASE - public symbols 
     d:\downloadedsymbols\kernelbase.pdb\91C72371DD43448192B7B46F5ED10AA02\kernelbase.pdb
個

死鎖分析

帖子列表

從!threads輸出：

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>

分析16

從

輸出：

ntdll!NtWaitForMultipleObjects+0xa: 
00000000`771218ca c3    ret

輸出從!clrstack：

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]

來源

2013-04-10 Rots

+1

你的符號好看。你從'〜* e！clrstack'獲得了好的線程堆棧嗎？ – 2013-04-11 13:20:09

+0

有很多線程。然而，那些有問題的死鎖並不能很好地回到！clrstack。 GetContext失敗：1？像這樣的東西。我將在週一爲您提供正確的輸出結果 - 謝謝。 – Rots 2013-04-12 11:31:41

+0

Marc，我編輯了原文。請查看上面的'死鎖分析'部分。你可以看到'！clrstack'的線程分析顯示'GetFrameContext failed：1'。我可以向你展示'〜* e！clrstack'的全部輸出，但是有很多線程可以查看。 – Rots 2013-04-15 02:50:43

回答

3

忽略該錯誤。 ！analyze -v只適用於崩潰轉儲（以及有些參數我相信您可以傳遞給崩潰轉儲以外的其他參數）。它報告的是，「崩潰」的原因是調試點被擊中。這是真的，因爲當你轉儲一個進程時，它會向進程注入一個線程並導致一箇中斷點被命中，然後爲進程轉儲內存。那麼分析告訴你的是，「崩潰」的原因是一個突破點被擊中。它可以安全地忽略。當你去看他們時，你應該能夠看到你所有的線索。其他一切應該正常工作。

來源

2013-04-12 02:29:48 Zipper

+0

謝謝拉鍊。不幸的是我的線程死鎖無法返回任何有用的時候使用！clrstack，因此我發佈了這個。一旦我確認了這一點，我可能會接受你的答案。我將在星期一發布更多信息。 – Rots 2013-04-12 11:35:02

+0

拉鍊 - 請參閱原始帖子中的「死鎖分析」一節瞭解更多信息。在你的回答中，'GetFrameContext failed：1'與符號的加載無關，並且原始問題中發佈的錯誤完全正確，因爲它正在加載崩潰轉儲。 – Rots 2013-04-15 02:51:55

1

我想你剛纔誤解了!blk命令的輸出，它給了我們CLR線程ID爲有問題的線程，而不是它們的序號（這是~s命令預期的）。 要獲得這兩個線程的序號，您可以使用!threads命令的輸出。

從你的例子：

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操作系統的線程ID

來源

2013-04-22 23:34:32 coq

+0

謝謝，我已經更新了原來的帖子。第二個線程提供了更多有趣的信息，但第一個線程仍然顯示'GetFrameContext失敗：1！ – Rots 2013-04-23 23:27:46

+0

@Rots，！blk已經顯示兩個線程的死鎖。你應該分析它們的調用堆棧，看看它們是如何互相鎖定的。那麼你應該學會防止死鎖。 – 2013-04-24 00:19:04

+0

@LexLi謝謝。我通過'！clrstack'分析了另一種方法嗎？ – Rots 2013-04-24 00:51:37

相關問題

 相關問題