Fix Available for Performance Problems with Internet Explorer 7's Phishing Filter

I don't know how I missed it (well, I suspect it's related to quirks in the method(s) in which Microsoft makes notifications of new KB articles available), but it seems that Microsoft has released an update to Internet Explorer 7 to address the performance issues with the Phishing Filter that I had previously (here and here) encountered.

The KB article (The computer may respond very slowly as the Phishing Filter evaluates Web page contents in Internet Explorer 7) is dated December 12, 2006, and contains links to download pages for various versions of Windows that Internet Explorer 7 can run on. Your copy of Windows has to pass the Windows Genuine Advantage (WGA) check before Microsoft will allow you to download the fix. Once downloaded, installation is straightforward; depending on what programs you have open at the time, you may be required to reboot after the installation finishes.

It is interesting to note that the Cause section (below) explains exactly the conditions I was operating in, and the behavior I observed.

---

CAUSE

This problem occurs when one or more of the following conditions are true:
• The Web page contains many frames.
• You browse many frames in a short time.
Internet Explorer 7 evaluates the whole Web page when you browse a frame. Therefore, CPU usage may be very high.

---

Additionally, the workaround (at the bottom of the article) is to disable the Phishing Filter on the "Advanced" tab of the "Internet Options".

Prior to installing the update, I set the Phishing Filter to "Turn off automatic website checking" ("Advanced" tab of "Internet Options") and made sure it was "Enabled" for the Internet Explorer Security Zone I was working in. I then verified that I was able to recreate the behavior I witnessed in The Case of the Sluggish Internet Explorer 7.

I installed the update and needed to reboot (I forgot I had SharpReader open, and it had loaded MSHTML.DLL). Upon reboot I attempted to cause the CPU to spike by doing precisely the things that had caused the problem in the past. I didn't have any luck in doing so. In fact, none of the threads in the iexplore.exe process were consuming an inordinate amount of CPU. It would appear that the fix involved, to some extent at least, changing the technique Internet Explorer uses to queue up requests to have something evaluated by the Phishing Filter (previously, I had hypothesized that Internet Explorer 7 was using the ThreadPool API and was creating a new thread for each request). Based on my explorations so far, the fix takes care of the problem. Kudos to Microsoft for recognizing the problem and taking appropriate steps to address it.

The fix updates 2 Windows / Internet Explorer program files in %windir%\system32 - ieapfltr.dll (the "Microsoft Phishing Filter") and mshtml.dll (the "Microsoft (R) HTML Viewer"). I didn't take the time to save off copies of the previous versions of these DLLs to try to compare differences (perhaps an exercise for another day). However, the new MSHTML.DLL has a date of 2006-11-09, and the new IEAPFLTR.DLL has a date of 2006-11-08. Internet Explorer 7.0 was released on 2006-10-18. So it appears that Microsoft knew of problems with the Phishing Filter performance prior to launch; obviously this wasn't a showstopper issue. It also would appear to have taken just over 1 month for the fix to make its way through the testing / release process. I guess that's not too bad, considering that some high-priority / critical security updates take at least that long. On the other hand, this is a new feature so it didn't have the legacy behind it that some of the security updates have to contend with. I guess I should just be happy to have a fix... ;)

»

Using Process Monitor to Troubleshoot Internet Explorer 7 Performance Issues

[Added 2007-01-18: Fix Available for Performance Problems with Internet Explorer 7's Phishing Filter ...]

Previously, I wrote about sluggish behavior with Internet Explorer 7. I had used Process Explorer to help pinpoint the cause of the sluggishness - in this case, it was Internet Explorer 7's (anti)phishing filter. I could also have used a relatively new tool from Microsoft's Windows Sysinternals - Process Monitor.

In Process Monitor, it is easy to get inundated with all of the data that the tool collects. Filters are very critical to enabling one to find the desired information, and the implementation of filters in Process Monitor is top notch. For this exercise, after starting Process Monitor and checking "Generate Profiling Events" on the "Options" menu, I captured events while exercising the web application with the Phishing Filter set to "Turn off automatic website checking" and "Enabled" for the Security zone the web application was in. After capturing events for a minute or so, I set the following filters:
-Process Name is iexplore.exe then Include
-Event Class is Registry then Exclude
-Event Class is File System then Exclude
-Event Class is Process then Exclude

This displayed all "profiling" events for the iexplore.exe process. I double-clicked an event to bring up the "Event Properties" dialog and clicked on the "Stack" tab, which had the following information:

ntdll.dll!KiFastSystemCallRet
kernel32.dll!WaitForSingleObject + 0x12
ole32.dll!GetToSTA + 0x6f
ole32.dll!CRpcChannelBuffer::SwitchAptAndDispatchCall + 0xf6
ole32.dll!CRpcChannelBuffer::SendReceive2 + 0xb9
ole32.dll!CAptRpcChnl::SendReceive + 0xab
ole32.dll!CCtxComChnl::SendReceive + 0x113
RPCRT4.dll!NdrProxySendReceive + 0x43
RPCRT4.dll!NdrClientCall2 + 0x1fa
OLEAUT32.dll!IDispatch_RemoteInvoke_Proxy + 0x1b
OLEAUT32.dll!IDispatch_Invoke_Proxy + 0xb6
ieapfltr.dll!ATL::CComPtr::GetProperty + 0x56
ieapfltr.dll!FieldContainer::VisitInput + 0x1b9
ieapfltr.dll!FieldContainer::VisitAllElements + 0x21d
ieapfltr.dll!FieldContainer::ExtractFieldCount + 0x10e
ieapfltr.dll!FieldContainer::InitFieldCount + 0x9
ieapfltr.dll!PageDetails::Init + 0x315
ieapfltr.dll!PageDetails::Factory + 0x59
ieapfltr.dll!HeuristicsFeatures::InnerExecute + 0x15b
ieapfltr.dll!HeuristicsFeatures::Execute + 0x55
ieapfltr.dll!ProcessingThread::RunPageAnalysis + 0x1b4
ieapfltr.dll!ProcessingThread::RunUrlAndPageAnalysis + 0xdb
ieapfltr.dll!ProcessingThread::Analyze + 0xd3
ieapfltr.dll!ProcessingThread::AnalyzeFrame + 0x249
ieapfltr.dll!ProcessingThread::EnumerateFrames + 0x2e5
ieapfltr.dll!ProcessingThread::EnumerateFrames + 0x249
ieapfltr.dll!ProcessingThread::Evaluate + 0x1ec
ieapfltr.dll!ProcessingThread::Execute + 0x78
ieapfltr.dll!ProcessingThread::Process + 0x24e
ieapfltr.dll!ProcessingThread::Start + 0x72
ieapfltr.dll!Evaluator::ContinueProcessing + 0x21f
ieapfltr.dll!Evaluator::ContinueProcessingWrapper + 0x21
ntdll.dll!RtlpWorkerCallout + 0x70
ntdll.dll!RtlpExecuteWorkerRequest + 0x1a
ntdll.dll!RtlpApcCallout + 0x11
ntdll.dll!RtlpWorkerThread + 0x87
kernel32.dll!BaseThreadStart + 0x37

With this information from Process Monitor, one could come to a similar conclusion - the Phishing Filter in Internet Explorer 7 seems to cause Internet Explorer 7's performance to degrade in certain environments.

»

The Case of the Sluggish Internet Explorer 7

[Added 2007-01-18: Fix Available for Performance Problems with Internet Explorer 7's Phishing Filter ...]

I like Internet Explorer 7. I've installed it many, many times and on
many systems. I've never had a problem with it. That is, until I had to spend some time working with a web-based application on an Intranet. I had to go through several iterations of repetetive steps in this application. It was the kind of work where it would have been more fun to write a program to achieve the end result, but it would probably have taken more time to write the program than it would to go through the tedious process. That, and the fact that I didn't immediately have access to some of the information that would be required to write the app, prevented me from taking the fun route. So I was stuck copying, clicking, pasting, and... WAITING.

The problem wasn't the responsiveness of the web server - the problem was localized to my system. As I was working on a laptop, I could hear the fan kick into high gear as CPU utilization hit 100%... and stayed there. When I paused for a bit, the CPU usage went back down. So, interacting with the web application was causing the behavior. The task took about 90 minutes to complete, and when I was done, Process Explorer showed iexplore.exe as having used nearly 90 minutes of CPU time. I didn't have this problem with Internet Explorer 6! In communicating with the vendor of the web application, they indicated that they hadn't had problems of this sort in any of their experiences with IE7 or with other customers.

I surmised that there was likely a setting in Internet Explorer 7 that was affecting the performance. But IE7 has no shortage of settings, and to try each one was not a task that I wanted to undertake. I fired up IE7, loaded the web-based app, and started working. Then, while the CPU was taxed, I went to Process Explorer, hit the properties of the iexplore.exe process, and checked the "Threads" tab. There were 89 threads, most having a start address of "ndtll.dll!RtlpWorkerThread", and all vying for CPU time. It appeared that a new thread was created for each request that was made, which seems rather "wasteful". At any rate, RtlpWorkerThread is a private "run-time library" worker thread threadproc function, presumably the threadproc used when one uses the Thread Pool API. The stack of one of these threads at the point that I captured it (obtained with Process Explorer and properly configured debugging symbols) is rather deep:

ntkrnlpa.exe!KiSwapContext+0x2e
ntkrnlpa.exe!KiSwapThread+0x46
ntkrnlpa.exe!KeWaitForMultipleObjects+0x284
ntkrnlpa.exe!NtWaitForMultipleObjects+0x2a2
ntkrnlpa.exe!KiFastCallEntry+0xf8
ntdll.dll!KiFastSystemCallRet
ntdll.dll!ZwWaitForMultipleObjects+0xc
kernel32.dll!WaitForMultipleObjectsEx+0x12c
ole32.dll!CoWaitForMultipleHandles+0x100
ieapfltr.dll!AntiPhishingMutex::AntiPhishingMutex+0x91
ieapfltr.dll!AntiPhishingHashTable::Find+0xaf
ieapfltr.dll!CacheManager::FindUrlInUrsCache+0xa5
ieapfltr.dll!AntiPhishDataSeeker::MatchRollUps+0x2cf
ieapfltr.dll!AntiPhishDataSeeker::MatchRollUpsInCache+0x43
ieapfltr.dll!AntiPhishDataSeeker::FindOMOTarget+0x2d
ieapfltr.dll!PageDetails::CountTargetRollups+0x34
ieapfltr.dll!PageDetails::Init+0x1da
ieapfltr.dll!PageDetails::Factory+0x59
ieapfltr.dll!HeuristicsFeatures::InnerExecute+0x15b
ieapfltr.dll!HeuristicsFeatures::Execute+0x55
ieapfltr.dll!ProcessingThread::RunPageAnalysis+0x1b4
ieapfltr.dll!ProcessingThread::RunUrlAndPageAnalysis+0xdb
ieapfltr.dll!ProcessingThread::Analyze+0xd3
ieapfltr.dll!ProcessingThread::AnalyzeFrame+0x249
ieapfltr.dll!ProcessingThread::EnumerateFrames+0x2e5
ieapfltr.dll!ProcessingThread::EnumerateFrames+0x249
ieapfltr.dll!ProcessingThread::Evaluate+0x1ec
ieapfltr.dll!ProcessingThread::Execute+0x78
ieapfltr.dll!ProcessingThread::Process+0x24e
ieapfltr.dll!ProcessingThread::Start+0x72
ieapfltr.dll!Evaluator::ContinueProcessing+0x21f
ieapfltr.dll!Evaluator::ContinueProcessingWrapper+0x21
ntdll.dll!RtlpWorkerCallout+0x70
ntdll.dll!RtlpExecuteWorkerRequest+0x1a
ntdll.dll!RtlpApcCallout+0x11
ntdll.dll!RtlpWorkerThread+0x87
kernel32.dll!BaseThreadStart+0x37

As you can see, after the thread pool plumbing is out of the way, the first function in the stack is ieapfltr.dll!Evaluator::ContinueProcessingWrapper - a function in ieapfltr.dll. ieapfltr.dll describes itself as "Microsoft Phishing Filter", though I suspect IEAP is an acronym for Internet Explorer Anti-Phishing. At any rate, it certainly seemed that the settings surrounding the (anti)phishing filter would be a good place to start.

I went into "Internet Options" in the Control Panel (Start Run inetcpl.cpl) and hit the "Advanced" tab. Toward the bottom was a setting for the Phishing Filter where there were three options:
-Disable Phishing Filter
-Turn off automatic website checking
-Turn on automatic website checking

Mine was set to "Turn off automatic website checking". I changed it to "Disable Phishing Filter" and hit OK, and re-tried the web application. The application was responsive as ever, and the "excess" threads that were previously being created were nowhere to be seen. Changing the setting back to "Turn off automatic website checking", and hitting the web application again caused iexplore.exe to consume as much of the CPU as it could. It appeared that I found the cause of the sluggish performance.

It is worth noting that in the "Internet Options", on the Security tab, each Internet Explorer Zone has its own setting for the Phishing Filter. If one selects a Zone, and clicks the "Custom level..." button, about 75% of the way down is a setting for "Use Phishing Filter" that has 2 options - Disable or Enable. The setting on the Advanced tab overrides this - if the Security zone setting is set to "Enable" and the Advanced setting is set to "Disable Phishing Filter", the Phishing Filter is disabled for all zones. However, if the Advanced setting is set to "Turn off automatic website checking" or "Turn on automatic website checking", one can exercise more granular control over each Security zone by choosing to enable / disable the filter where it makes sense.

»