2014-04-03 20 views
9

Zrobiłem zrzut (używając opcji -ma i wyzwalacza dla wysokiego CPU w procdump.exe) procesu .NET i chcę zobaczyć wskazówki w uruchomionym wątku o tym, co mój kod robił. Mam to:Debugowanie zrzutów .NET za pomocą windbg

*** procdump -ma -c 65 -s 2 -n 3 service.exe 
*** Process exceeded 65% CPU for 2 seconds. Thread consuming CPU: 4396 (0x112c)' 

Wskazany wątek wykonywał że w czasie zrzutu:

0:022> k 
ChildEBP RetAddr 
WARNING: Frame IP not in any known module. Following frames may be wrong. 
0990f104 040666ab 0x40656f8 
0990f124 04066465 0x40666ab 
0990f14c 040655e2 0x4066465 
0990f160 040651f4 0x40655e2 
0990f178 04065032 0x40651f4 
0990f1a4 04064ee5 0x4065032 
0990f1c8 04062705 0x4064ee5 
0990f20c 04062512 0x4062705 
*** WARNING: Unable to verify checksum for System.ServiceModel.ni.dll 
0990f31c 6caf0cab 0x4062512 
0990f3d0 6caeebf6 System_ServiceModel_ni+0x3b0cab 
0990f43c 6caee962 System_ServiceModel_ni+0x3aebf6 
0990f474 6caee5cb System_ServiceModel_ni+0x3ae962 
0990f488 6caed407 System_ServiceModel_ni+0x3ae5cb 
0990f4d4 6cb07a4d System_ServiceModel_ni+0x3ad407 
0990f4f4 6d24c989 System_ServiceModel_ni+0x3c7a4d 
0990f510 6d24c966 System_ServiceModel_ni+0xb0c989 
*** WARNING: Unable to verify checksum for mscorlib.ni.dll 
0990f584 6f8c4096 System_ServiceModel_ni+0xb0c966 
0990f598 6f8ee1a0 mscorlib_ni+0x364096 
0990f5b4 6f8ed949 mscorlib_ni+0x38e1a0 
0990f604 6f8ed7f5 mscorlib_ni+0x38d949 
0990f614 705a3315 mscorlib_ni+0x38d7f5 
0990f668 705a6cdf clr!CallDescrWorkerWithHandler+0x6b 
0990f6dc 70741281 clr!MethodDescCallSite::CallTargetWorker+0x152 
0990f754 706082f7 clr!QueueUserWorkItemManagedCallback+0x1f 
0990f76c 70608365 clr!Thread::DoExtraWorkForFinalizer+0x1ca 
0990f814 70608432 clr!Thread::DoExtraWorkForFinalizer+0x256 
0990f870 7060849f clr!Thread::DoExtraWorkForFinalizer+0x615 
0990f894 70741219 clr!Thread::DoExtraWorkForFinalizer+0x6b2 
0990f948 70740b31 clr!ManagedPerAppDomainTPCount::DispatchWorkItem+0xc5 
0990f95c 70741711 clr!ThreadpoolMgr::ExecuteWorkRequest+0x42 
0990f9c4 707236f8 clr!ThreadpoolMgr::WorkerThreadStart+0x353 
0990fddc 76f9336a clr!Thread::intermediateThreadProc+0x4d 
0990fde8 77bd9f72 kernel32!BaseThreadInitThunk+0xe 
0990fe28 77bd9f45 ntdll!__RtlUserThreadStart+0x70 
0990fe40 00000000 ntdll!_RtlUserThreadStart+0x1b 

problemów jest to, że nie widzę żadnego z „mojego kodu” w stosie, a pula wątków wątek wykonuje, aby mieć pojęcie o tym, co robił.

Odpowiedz

7

Niestety .net nie działa zgodnie z regułami określonymi przez dział Windows, robi to samo (jak wiele rzeczy, które zrobił dział Developer w Microsoft). W rezultacie nie otrzymujesz informacji debugowania wypisanych tak samo jak w przypadku aplikacji natywnych.

To jest przyczyną wielu wstrząsów głowy, kiedy używam windbg, szpiega lub dumpina - narzędzi, które były nieocenione w przeszłości. Ale nieważne, możesz coś z tego wyciągnąć:

Najpierw musisz załadować informacje o sosach, możesz użyć! Clrstack, aby zobaczyć ślad stosu .net.

.loadby sos mscorwks (for .net 2) 
.loadby sos clr (for .net 4, of course :() 
!clrstack 

Jest cheat sheet z kilku przydatnych poleceń.

+0

Rzeczywiście, użycie Son of Strike jest niezbędne, aby nadać sens .NET w WinDbg. –

+0

Tak, wolałbym powiedzieć "zapisz nasze ...", ponieważ bez niego nie masz pojęcia w aplikacjach .net – Gmt

0

Nie sądzę, że "k" wyświetla stosy połączeń ze wszystkich wątków. Czy próbowałeś ~ * k?

+1

Wyświetliłem stos dla wątku wysokiego cpu. ten identyfikator wątku został ustawiony przez procdump podczas wyrzucania – Gmt

Powiązane problemy