I got a couple of cases of this kind recently, one where the web pages were served by PerformancePoint and the other one was a completely custom web site, but both of them shared the same common root issue: browsing some specific pages, the CPU on client got constantly at 100% and the GUI was completely frozen
From the Internet Explorer dump we captured it was very clear that thread 2 was the one burning the CPU:
0:000> !runaway User Mode Time Thread Time 2:1654 0 days 0:07:55.954 0:1610 0 days 0:00:00.420 7:142c 0 days 0:00:00.070 9:1788 0 days 0:00:00.050 4:1388 0 days 0:00:00.010 17:8f0 0 days 0:00:00.000 16:11cc 0 days 0:00:00.000 15:1180 0 days 0:00:00.000 14:11ec 0 days 0:00:00.000 13:1778 0 days 0:00:00.000 12:f8 0 days 0:00:00.000 11:7dc 0 days 0:00:00.000 10:e0c 0 days 0:00:00.000 8:1784 0 days 0:00:00.000 6:1420 0 days 0:00:00.000 5:1478 0 days 0:00:00.000 3:1338 0 days 0:00:00.000 1:1634 0 days 0:00:00.000
And thread 2 has his stack:
0:002> kpL1000 ChildEBP RetAddr 01bcf0bc 43d0e4d7 mshtml!CFormatInfo::GetMatchedBy 01bcf170 43cf914f mshtml!CStyleSelector::Match+0x34d 01bcf694 43d12175 mshtml!CStyleSheetArray::Apply+0x1e1 01bcf6f4 43d17298 mshtml!CElement::ApplyDefaultFormat+0x490 01bcf708 43cf8958 mshtml!CAnchorElement::ApplyDefaultFormat+0x9f 01bcf748 43cf53e2 mshtml!CElement::ComputeFormatsVirtual+0xaa3 01bcf764 43d0cb08 mshtml!CElement::ComputeFormats+0x3a 01bcf9f4 43d3876b mshtml!CTreeNode::GetFancyFormatHelper+0x4b 01bcfb10 43e167ab mshtml!CElement::UpdateFormats+0x2da 01bcfb2c 43d3d908 mshtml!CElement::HandleMouseHoverForStyle+0x1a7 01bcfbac 43e3f53c mshtml!CDoc::PumpMessage+0xa3f 01bcfcf8 43d3c4a1 mshtml!CDoc::OnMouseMessage+0x4df 01bcfe1c 43d7e137 mshtml!CDoc::OnWindowMessage+0x748 01bcfe48 7e398734 mshtml!CServer::WndProc+0x78 01bcfe74 7e398816 user32!InternalCallWinProc+0x28 01bcfedc 7e3989cd user32!UserCallWinProcCheckWow+0x150 01bcff3c 7e398a10 user32!DispatchMessageWorker+0x306 01bcff4c 4367e6c3 user32!DispatchMessageW+0xf 01bcffb4 7c80b683 ieframe!CTabWindow::_TabWindowThreadProc+0x189 01bcffec 00000000 kernel32!BaseThreadStart+0x37
Something similar also happens if you have a .NET control inside a table using percentage width and height for the control, and using percentage width for the wrapping table cell:
ChildEBP RetAddr 018a84f8 77f17fda ntdll!KiFastSystemCallRet 018a854c 629c31f7 gdi32!NtGdiExtTextOutW+0xc 018a8588 629c322c lpk!InternalTextOut+0x1d4 018a85bc 77f31dc4 lpk!LpkExtTextOut+0x29 018a860c 436761bc gdi32!ExtTextOutW+0x26a 018a8890 43676038 mshtml!XHDC::ExtTextOutW+0x13e 018a88b8 43675ffa mshtml!ExtTextOutW+0x24 018a8e64 43675f06 mshtml!LSReExtTextOut+0x79 018a8f38 436763a5 mshtml!CLSRenderer::TextOutW+0x7fe 018a90d8 436b03e4 mshtml!CLSRenderer::BlastLineToScreen+0x4a7 018a9150 436aff59 mshtml!CLSRenderer::RenderLine+0x3f7 018a94b8 436afc4b mshtml!CDisplay::Render+0x4e0 018a94d0 436b004f mshtml!CFlowLayout::Draw+0x1c 018a9504 436ad37e mshtml!CLayout::DrawClient+0x52 018a98e0 436abdc0 mshtml!CDispLeafNode::DrawSelf+0x42c 018a9bc4 436ace26 mshtml!CDispNode::Draw+0x10d 018a9be4 436ac529 mshtml!CDispContainer::DrawChildren+0x3f 018a9f80 436abdc0 mshtml!CDispContainer::DrawSelf+0x290 018aa264 436ace26 mshtml!CDispNode::Draw+0x10d 018aa284 436ad86a mshtml!CDispContainer::DrawChildren+0x3f 018aa620 436abdc0 mshtml!CDispContainer::DrawSelf+0x2be 018aa904 436ace26 mshtml!CDispNode::Draw+0x10d 018aa924 436ad86a mshtml!CDispContainer::DrawChildren+0x3f 018aacc0 436abdc0 mshtml!CDispContainer::DrawSelf+0x2be 018aafa4 43667b64 mshtml!CDispNode::Draw+0x10d 018acf50 43667a64 mshtml!CDispRoot::DrawBand+0xc7 [...]
The stacks look quite similar for the one we had for a couple of old bugs already fixed for Internet Explorer when dynamically adding cells via DHTML (back in 2002-2003); there was also another bug in .NET 2.0 which has been fixed in KB# 928365.
For both customers the problem reproduced only with IE7, IE was running in Strict mode (but not in Quirks mode) and the page layout was made with nested Tables and DIVs whose dimensions (width and/or height) where expressed in percentage.
Since we needed the page layout to adapt gracefully to the size of browser’s window, we could not avoid using percentages for Tables and DIVs, so we decided to not use Strict mode instead. This is controlled with the !DOCTYPE page declaration, in particular:
You can use this declaration to switch Microsoft Internet Explorer 6 and later into strict standards-compliant mode. You turn the switch on by including the !DOCTYPE declaration at the top of your document, specifying a valid Label in the declaration, and in some cases, specifying the Definition and/or URL. The following table shows when standards-compliance is on or off.
| DOCTYPE | URL Present | URL Not Present |
| No DOCTYPE present | off | off |
| HTML (no version) | off | off |
| HTML 2.0 | off | off |
| HTML 3.0 | off | off |
| HTML 4.0 | on | on |
| HTML 4.0 Frameset | on | off |
| HTML 4.0 Transitional | on | off |
| HTML 4.0 Strinct | on | on |
| XHTML | on | on |
| XML | on | on |
| Unrecognized DOCTYPE | on | on |
To make things easy we simply removed the DOCTYPE declaration from the problematic pages, and the CPU usage went back to normal.
In my tests, the problem does not reproduce in IE8.
Carlo
Quote of the day:
When ideas fail, words come in very handy. – Johann Wolfgang von Goethe