Win7 x64 IE problem

[todarsey]

I have been having a problem on 2 different computers, one at home and one at the office. They are doth running Win7 x64, one is pro and the other is ultimate. The problem I am having is after a while, my IE stops working. It works fine after a reboot, but after a while when I open it (it could be a day or a couple of days) it just sits there like it is trying to open the page but it never does. I don't think that is is a networking issue because I can still open shared folders from my server. Does anyone have any ideas?

[fizban2]

i would say first disable any add-ons that might be running in IE, then see if you can get it to crash again.

[todarsey]

i would say first disable any add-ons that might be running in IE, then see if you can get it to crash again.

I've tried that, the problem still happens.

[cluberti]

Can you get a hang dump of the iexplore.exe process the next time it happens? IE is an x86 process (even on x64 Win7), so download and install the x86 debugging tools (using the instructions linked).

[todarsey]

What file do I need to post after I run the debug?

[cluberti]

For now, the .dmp file should be sufficient. Zip it up, and then put it somewhere we can get to if you can.

[todarsey]

There were 2 .bmp files so I put both in a zip file. They can be downloaded from here

ftp://hsatally.homeserver.com

user = msfn

password = P@ssWord

[todarsey]

Anyone?

[cluberti]

I didn't see anything obvious in either dump (in fact, the browser was completely idle). However, I could tell that approximately 1 hour had passed since the browser last attempted something, and *something* had spawned a worker thread in both the frame and tab processes (but possibly died out). I took the stack base and stack limit for that thread, and found this in the frame process:

0:010> dds 05eb2000 05ec0000
...
05ebf64c  75720000 kernel32!_imp__DebugBreak <PERF> (kernel32+0x0)
...
05ebf748  77a73af4 ntdll!RtlpAllocateHeap+0xab2
05ebf74c  77a73b23 ntdll!RtlpAllocateHeap+0xe73
...
05ebf860  77250000 KERNELBASE!_imp__RtlUnicodeStringToAnsiString <PERF> (KERNELBASE+0x0)
...
05ebf8c4  77a6e20c ntdll!RtlpLowFragHeapAllocFromContext+0xaec
...
05ebf99c  77a72b21 ntdll!RtlAllocateHeap+0x21d
...
05ebf9c0  7721140a ws2_32!DllMain+0x1bf
...
05ebf9e0  74f41233 rsaenh!DllMain+0x103
05ebf9e4  7510140a mswsock!DllMain+0x183
...
05ebfa18  73aa11d0 xmllite!__DllMainCRTStartup+0xe1
05ebfa1c  73aa0000 xmllite!_imp__UnhandledExceptionFilter <PERF> (xmllite+0x0)
...
05ebfa24  73aa1227 xmllite!__DllMainCRTStartup+0x24e
...
05ebfa50  759caf8c msvcrt!_initptd+0x8c
05ebfa54  759ca501 msvcrt!__CRTDLL_INIT+0x102
...
05ebfa68  73ac7e4c xmllite!_except_handler4
...
05ebfa74  73aa1227 xmllite!__DllMainCRTStartup+0x24e
05ebfa78  77a797c0 ntdll!zzz_AsmCodeRange_End
05ebfa7c  73aa0000 xmllite!_imp__UnhandledExceptionFilter <PERF> (xmllite+0x0)
...05ebfafc  77a79fbc ntdll!LdrpInitializeThread+0x131
05ebfb00  77a79f6a ntdll!LdrpInitializeThread+0x179
...
05ebfb10  73aa1142 xmllite!_DllMainCRTStartup
05ebfb14  7efde000
05ebfb18  77b40214 ntdll!PebLdr+0x14
...

I found this in the tab process, confirming an RPC call likely to spawn the xmllite thread in the frame proc:

0:008> dds 03d52000 03d60000
...
03d5f108  757336c6 kernel32!ConDllInitialize+0xd4
...
03d5f73c  75733647 kernel32!_BaseDllInitialize+0x92
...
03d5f750  7573365c kernel32!_BaseDllInitialize+0x2cf
...
03d5f764  75720000 kernel32!_imp__DebugBreak <PERF> (kernel32+0x0)
...
03d5f7e8  761a02e0 user32!gcsAccelCache
03d5f7ec  7613c6bd user32!NtUserInitializeClientPfnArrays+0x15
03d5f7f0  7613c665 user32!ClientThreadSetup+0xf2
03d5f7f4  77a8f818 ntdll!NtDllUserStubs
03d5f7f8  77a8f8d0 ntdll!NtDllUserStubs+0xb8
03d5f7fc  77a8f988 ntdll!NtDllUserStubs+0x170
03d5f800  76120000 user32!_imp__GetTokenInformation <PERF> (user32+0x0)
...
03d5f8bc  77a6e20c ntdll!RtlpLowFragHeapAllocFromContext+0xaec
...
03d5f940  77a73af4 ntdll!RtlpAllocateHeap+0xab2
...
03d5f994  724a9907 IEShims!IEShimLib::CStringParseCommandLine+0x2f
...
03d5fa44  724bd6cf IEShims!NS_RedirectRegistry::RedirectorRegistry::ThreadAttach+0x31
...
03d5fa54  77a5f88a ntdll!ZwCallbackReturn+0x12
03d5fa58  7613c5c6 user32!__ClientThreadSetup+0x1e
...
03d5fb30  75bf27ef ole32!RPCSStoOLE32SecurityCallback+0x38
...
03d5fb48  7606618c rpcrt4!RPC_INTERFACE::DispatchToStubWorker+0x141
...
03d5fd9c  77a62056 ntdll!ZwWow64GetCurrentProcessorNumberEx+0x12
03d5fda0  77a728e0 ntdll!RtlGetCurrentProcessorNumberEx+0xf
...
03d5fdb0  77a728fe ntdll!TppGetWorkerFactoryHandle+0x10
...
03d5fdc0  77a61ee6 ntdll!ZwWaitForWorkViaWorkerFactory+0x12
03d5fdc4  77aa21aa ntdll!TppWorkerThread+0x216
...
03d5fde0  77b40180 ntdll!TppWorkerpList
...
03d5ff70  77a79d45 ntdll!_RtlUserThreadStart+0x1b
03d5ff74  77aa2c91 ntdll!TppWorkerThread
...
03d5ff8c  77aa2c91 ntdll!TppWorkerThread
...
03d60000  ????????

It looks as if xmllite was loaded for something, IE went down into the network (winsock) stack, and there was some exception that caused a debug break. However, since no debugger was attached, you probably have a "hung" process waiting for commands from a non-existant debugger. Also, I noted that the stack base in the tab process was invalid, which could mean something bad happened while the thread was being created, but in any case a static dump of this probably isn't sufficient to show the issue. It'll probably take someone at the console when the problem first occurs to dump it then, if that's even possible.

It could be an xmllite issue, but I don't think that's likely. Is it always the same website that's up when the browser hangs?

[todarsey]

I have found that the problem is with my Avast antivirus. When I have the problem with IE, I can stop the Avast on access protection then reopen IE and it will open fine, then re-enable Avast and all is well for a while.

[saissylois]

hi

i have encountered the same problem but not in x64 of windows 7 but in x86.. IE is slower than i thought. it always crush

same as my windows media player

try to turn off al pop outs and add ons and other of your running systems in start ups