LuckMan212 Posted January 17, 2009 Posted January 17, 2009 alright, i've uploaded the correct dump files now: hang_mode__date_01-16-2009__time_17-24-09pm.zipdownload from: http://drop.io/4avkcl0By the way, I installed the 32bit version of Windbg but when I opened the dump files they basically looked the same. In the docs for the x64 edition, it states"When to Use 64-bit Debugging ToolsThe 64-bit versions of Debugging Tools for Windows allow you to debug both 32-bit and 64-bit user-mode applications running on 64-bit processors. Use this package to debug both the application and the WOW64 emulator."So are you sure I cannot debug 32bit apps in the 64bit Windbg? Anyway, I really appreciate any sort of help sifting through these dumps, because I think I have the right tools but not the know-how.
cluberti Posted January 18, 2009 Posted January 18, 2009 Yes, you can - but it's not as easy. You will need to do .effmach x86; .load wow64exts to see the x86 threads - then, you have to know that there are some differences in debugging x86 in x64 windbg. I'd rather people new at this use the right debugger architecture for the bitness of the app they're debugging first, until you're comfortable, before doing x86 debugging in x64 windbg.Anyway, onto the fun:Thread 0 (remember how I said x86 on x64 is different? I'm looking at this in x64 windbg - note that the x86 "thread 0" is really thread 3 under wow64, for example) is waiting for a worker thread to complete, which means the browser is going to appear "hung" until the worker thread returns:// x86 Thread 0 - the "UI" thread, is waiting:0:003:x86> kChildEBP RetAddr 03fef62c 774adcea ntdll_77af0000!NtWaitForMultipleObjects+0x1503fef6c8 77648f76 kernel32!WaitForMultipleObjectsEx+0x11d03fef71c 6e906071 user32!RealMsgWaitForMultipleObjectsEx+0x14dWARNING: Frame IP not in any known module. Following frames may be wrong.03fef73c 6e90af93 ieui+0x607103fef770 6e90b4ea ieui+0xaf9303fef790 6e90b447 ieui+0xb4ea03fef7e4 76052cce ieui+0xb44703fef81c 76052deb msvcrt!_endthreadex+0x4403fef824 7751e3f3 msvcrt!_endthreadex+0xce03fef830 77b6cfed kernel32!BaseThreadInitThunk+0xe03fef870 77b6d1ff ntdll_77af0000!__RtlUserThreadStart+0x2303fef888 00000000 ntdll_77af0000!_RtlUserThreadStart+0x1b// The worker thread - it looks like you browsed away from a page, and IE is waiting for the flash plugin to unload:0:004:x86> kChildEBP RetAddr 043af478 774a1270 ntdll_77af0000!ZwWaitForSingleObject+0x15043af4e8 774a11d8 kernel32!WaitForSingleObjectEx+0xbe043af4fc 69b3f74f kernel32!WaitForSingleObject+0x12WARNING: Stack unwind information not available. Following frames may be wrong.043af50c 699ffdbf Flash10a!DllUnregisterServer+0x3055c043af51c 69ad01e8 Flash10a+0x1fdbf043af608 69b1dc0a Flash10a+0xf01e8043af688 69b1e4f8 Flash10a!DllUnregisterServer+0xea17043af6d4 6e94e095 Flash10a!DllUnregisterServer+0xf305043af700 6e94de5e jscript!GcAlloc::ReclaimGarbage+0x76043af71c 6e94dedc jscript!GcContext::Reclaim+0x93043af730 6e95a62e jscript!GcContext::Collect+0x9a043af73c 6e9443fd jscript!GcContext::ExhaustiveCollect+0x1c043af754 6e944cd2 jscript!CSession::Close+0x10b043af774 6f7f44b0 jscript!COleScript::Close+0x82043af7a4 6f84d2cd mshtml!DllCanUnloadNow+0x14f043af7b0 6f84d2b4 mshtml!MatchExactGetIDsOfNames+0x1822f043af7cc 6f84d29b mshtml!MatchExactGetIDsOfNames+0x18216043af848 6f84d4d2 mshtml!MatchExactGetIDsOfNames+0x181fd043af860 6f84d438 mshtml!MatchExactGetIDsOfNames+0x18434043af888 6f7f4991 mshtml!MatchExactGetIDsOfNames+0x1839a// The version of flash, for reference:0:004:x86> lmvm flash10astart end module name00000000`699e0000 00000000`69e55000 Flash10a (export symbols) Flash10a.ocx Loaded symbol image file: Flash10a.ocx Image path: C:\Windows\SysWOW64\Macromed\Flash\Flash10a.ocx Image name: Flash10a.ocx Timestamp: Sat Oct 04 23:16:05 2008 (48E83175) CheckSum: 003AB626 ImageSize: 00475000 File version: 10.0.12.36 Product version: 10.0.12.36 File flags: 0 (Mask 3F) File OS: 4 Unknown Win32 File type: 2.0 Dll File date: 00000000.00000000 Translations: 0409.04b0 CompanyName: Adobe Systems, Inc. ProductName: Shockwave Flash InternalName: Adobe Flash Player 10.0 OriginalFilename: Flash.ocx ProductVersion: 10,0,12,36 FileVersion: 10,0,12,36 FileDescription: Adobe Flash Player 10.0 r12 LegalCopyright: Adobe® Flash® Player. Copyright © 1996-2008 Adobe Systems Incorporated. All Rights Reserved. Protected by U.S. Patent 6,879,327; Patents Pending in the United States and other countries. Adobe and Flash are either trademarks or registered trademarks in theҽﻯ LegalTrademarks: Adobe Flash PlayerNote that adobe flash is probably the biggest offender in IE crashes and hangs, so if you can live without it, disable it.
LuckMan212 Posted January 19, 2009 Posted January 19, 2009 thanks cluberti, for your time- this is amazing! Of course I have some questions- 1) how do you know the main/UI thread is 'thread 3' - is thread 3 always the UI thread when debugging x86 on x64?2) how did you figure out from the entry "03fef62c 774adcea ntdll_77af0000!NtWaitForMultipleObjects+0x15" that it means it is waiting for thread 4? 3) do multithreaded apps always pass control in a linear fashion? (i.e. if thread 3 is waiting, then it means thread 4 is executing??) 4) how do you know thread 4 is a `worker thread`?5) when I open the dump files in x86 WinDbg on my system, the 'k' command yields the following:0:000> kChild-SP RetAddr Call Site00000000`000ceb08 00000000`75c4ab46 wow64cpu!WaitForMultipleObjects32+0x3a00000000`000cebb0 00000000`75c4a14c wow64!RunCpuSimulation+0xa00000000`000cebe0 00000000`779852d3 wow64!Wow64LdrpInitialize+0x4b400000000`000cf140 00000000`77985363 ntdll!LdrpInitializeProcess+0x14ac00000000`000cf3f0 00000000`779785ce ntdll! ?? ::FNODOBFM::`string'+0x1ff1900000000`000cf4a0 00000000`00000000 ntdll!LdrInitializeThunk+0xeWhat do you think the ntdll ?? ::FNODOBFM:: line is? That line doesn't appear when debugging in the x64 version.sorry for so many questions, I am just trying to understand how you were able to figure this out!
cluberti Posted January 19, 2009 Posted January 19, 2009 1 - Experience, and no.2 - I know how IE works - looking at the other threads (actually, specifically thread 4) let me know that there was a worker thread, meaning someone had to spawn it (and from what it was doing, this would have been done as the result of a browse event meaning it comes from thread "0" (again, experience)3 - No4 - because it's doing work 5 - This is the x86 side of the wow64 CPU thread - you can't see what it's doing without private (internal) symbols, but rest assured this is normal
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now