browser hang (no response) after 3 screens viewed.

[LuckMan212]

alright, i've uploaded the correct dump files now:

hang_mode__date_01-16-2009__time_17-24-09pm.zip

download from: http://drop.io/4avkcl0

By 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 Tools

The 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]

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> k
ChildEBP		  RetAddr		   
03fef62c 774adcea ntdll_77af0000!NtWaitForMultipleObjects+0x15
03fef6c8 77648f76 kernel32!WaitForMultipleObjectsEx+0x11d
03fef71c 6e906071 user32!RealMsgWaitForMultipleObjectsEx+0x14d
WARNING: Frame IP not in any known module. Following frames may be wrong.
03fef73c 6e90af93 ieui+0x6071
03fef770 6e90b4ea ieui+0xaf93
03fef790 6e90b447 ieui+0xb4ea
03fef7e4 76052cce ieui+0xb447
03fef81c 76052deb msvcrt!_endthreadex+0x44
03fef824 7751e3f3 msvcrt!_endthreadex+0xce
03fef830 77b6cfed kernel32!BaseThreadInitThunk+0xe
03fef870 77b6d1ff ntdll_77af0000!__RtlUserThreadStart+0x23
03fef888 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> k
ChildEBP		  RetAddr		   
043af478 774a1270 ntdll_77af0000!ZwWaitForSingleObject+0x15
043af4e8 774a11d8 kernel32!WaitForSingleObjectEx+0xbe
043af4fc 69b3f74f kernel32!WaitForSingleObject+0x12
WARNING: Stack unwind information not available. Following frames may be wrong.
043af50c 699ffdbf Flash10a!DllUnregisterServer+0x3055c
043af51c 69ad01e8 Flash10a+0x1fdbf
043af608 69b1dc0a Flash10a+0xf01e8
043af688 69b1e4f8 Flash10a!DllUnregisterServer+0xea17
043af6d4 6e94e095 Flash10a!DllUnregisterServer+0xf305
043af700 6e94de5e jscript!GcAlloc::ReclaimGarbage+0x76
043af71c 6e94dedc jscript!GcContext::Reclaim+0x93
043af730 6e95a62e jscript!GcContext::Collect+0x9a
043af73c 6e9443fd jscript!GcContext::ExhaustiveCollect+0x1c
043af754 6e944cd2 jscript!CSession::Close+0x10b
043af774 6f7f44b0 jscript!COleScript::Close+0x82
043af7a4 6f84d2cd mshtml!DllCanUnloadNow+0x14f
043af7b0 6f84d2b4 mshtml!MatchExactGetIDsOfNames+0x1822f
043af7cc 6f84d29b mshtml!MatchExactGetIDsOfNames+0x18216
043af848 6f84d4d2 mshtml!MatchExactGetIDsOfNames+0x181fd
043af860 6f84d438 mshtml!MatchExactGetIDsOfNames+0x18434
043af888 6f7f4991 mshtml!MatchExactGetIDsOfNames+0x1839a

// The version of flash, for reference:
0:004:x86> lmvm flash10a
start			 end				 module name
00000000`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 Player

Note that adobe flash is probably the biggest offender in IE crashes and hangs, so if you can live without it, disable it.

[LuckMan212]

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> k
Child-SP          RetAddr           Call Site
00000000`000ceb08 00000000`75c4ab46 wow64cpu!WaitForMultipleObjects32+0x3a
00000000`000cebb0 00000000`75c4a14c wow64!RunCpuSimulation+0xa
00000000`000cebe0 00000000`779852d3 wow64!Wow64LdrpInitialize+0x4b4
00000000`000cf140 00000000`77985363 ntdll!LdrpInitializeProcess+0x14ac
00000000`000cf3f0 00000000`779785ce ntdll! ?? ::FNODOBFM::`string'+0x1ff19
00000000`000cf4a0 00000000`00000000 ntdll!LdrInitializeThunk+0xe

What 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]

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 - No

4 - 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