views:

877

answers:

2

I have a situation where IE7 hangs accessing my web app. Based on the excellent suggestion from George V. Reilly, I installed WinDbg to download the IE symbols, setup Process Explorer to use those symbols, and then used Process Explorer to get a stack trace for the hung thread.

I have pasted the stack trace below. Does someone more familiar with the IE internals have an idea of what is happening, or a suggestion on how to progress with this?

ntkrnlpa.exe!KiUnexpectedInterrupt+0x8d
ntkrnlpa.exe!PsDereferencePrimaryToken+0x362
ntkrnlpa.exe!KiDeliverApc+0xb3
ntkrnlpa.exe!KiDispatchInterrupt+0x5a2
ntkrnlpa.exe!SeOpenObjectAuditAlarm+0x1ce
mshtml.dll!CTreePos::GetCp+0x5a
mshtml.dll!CFlowLayout::GetNestedElementCch+0x7d
mshtml.dll!CDisplay::FormattingNodeForLine+0x1d5
mshtml.dll!CFlowLayout::LineStart+0xdb
mshtml.dll!CDisplayPointer::GetLineStart+0x44
mshtml.dll!CDisplayPointer::IsAtBOL+0x4e
mshtmled.dll!CCaretTracker::PositionCaretAt+0xf9
mshtmled.dll!CCaretTracker::Init2+0x54
mshtmled.dll!CSelectionManager::SetCurrentTracker+0x26
mshtmled.dll!CSelectionManager::CreateTrackerForContext+0x1c0
mshtmled.dll!CSelectionManager::SetEditContext+0x8b
mshtmled.dll!CSelectionManager::SetEditContextFromElement+0x2ed
mshtmled.dll!CSelectionManager::EnsureEditContextClick+0x343
mshtmled.dll!CSelectionManager::HandleEvent+0xb9
mshtmled.dll!CHTMLEditor::PostHandleEvent+0x89
mshtml.dll!CDoc::HandleSelectionMessage+0x1e0
mshtml.dll!CDoc::PumpMessage+0xb69
mshtml.dll!CDoc::OnMouseMessage+0x3d7
mshtml.dll!CDoc::OnWindowMessage+0x748
mshtml.dll!CServer::WndProc+0x78
USER32.dll!InternalCallWinProc+0x28
USER32.dll!UserCallWinProcCheckWow+0x150
USER32.dll!CallWindowProcAorW+0x98
USER32.dll!CallWindowProcW+0x1b
IEDevToolbar.dll!DllUnregisterServer+0xe21d
USER32.dll!InternalCallWinProc+0x28
USER32.dll!UserCallWinProcCheckWow+0x150
USER32.dll!DispatchMessageWorker+0x306
USER32.dll!DispatchMessageW+0xf
IEFRAME.dll!CTabWindow::_TabWindowThreadProc+0x189
kernel32.dll!BaseThreadStart+0x37
+1  A: 

Does it hang in all browsers or just IE7?

The only thing that stands out to me is "IEDevToolbar.dll!"

Also... it could be your app doing something it should not.

hunter
@Hunter Daley, It happens with just IE6 and IE7 (not Safari and Firefox). I uninstalled the IE Dev Toolbar, and get the same problem. The stack trace is similar, except it doesn't have the IE Dev Toolbar in it.
Alessandro Vernet
+2  A: 

Based on the stack trace, it is in the middle of altering the DOM. As commented on your previous post, IE is extremely inefficient when doing both reads and writes on the DOM (when compared to Firefox and Chrome.)

The performance problems can be tackled by reducing and optimize both the reading and the writing of the DOM by:

  1. navigating the DOM using simple DOM properties and methods whenever possible (Document.getElementById, DomElement.parentNode, DomElement.childNodes[], DomElement.nextSibling, etc.) instead of the XPATH (CSS) selector methods (DomElement.querySelector)
    • this is because querySelector behaves O(N) under IE, where N is the size of the entire DOM - that is, you will pay the penalty of traversing the entire DOM even if you call querySelector on a leaf node that has no children!
    • if you trigger one or more querySelector calls for each element in a considerable subset of the DOM, you are essentially paying O(N^2) penalty
    • note that YUI's YAHOO.util.Selector.query, Prototype's element.down, element.up, element.select all use the querySelector call internally
  2. altering the UI behavior, if possible, to skip or defer as much DOM traversal and modification as possible
    • present as little information at a time; force the user to click (e.g. on expand links etc.) in order for you to proceed with additional processing/modifications
  3. switch away from Javascript, to Flash or Java.

Given that you are using YUI you may not have a lot of latitude as far as option 1 goes, and I can imagine that option 3 is almost certainly a non-option for you. Which unfortunately leaves option 2.

Cheers, V.

vladr
@Vlad Romascanu, this is all good to solve a performance problem. But what I have here is not a performance problem, but a case where IE hangs. It uses 100% of the CPU and never gets out of this state, even if you leave it running for 1 day. It is a bug in IE, but I am not sure what is causing it.
Alessandro Vernet
Two options: 1) still using windbg, walk up the stack and examine the misc. parameters' string values, you may find a hint as to what's being worked on at the time. 2) 'alert' debugging - stuff your code and YUI with alert's until you pin down the place-of-no-return
vladr
#1 is an interesting suggestion. I'll give it a go. I did #2, but didn't find anything interesting. Which is confirmed by the stack traces above which indicate that this is not happening in JS code.
Alessandro Vernet
I wonder if IE is stuck chasing its own tail navigating the DOM, i.e element.parentNode = element? :)
vladr