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... ;)
»
Posts
14 comments:
When I am trying to reinstall the same version of Internet Explorer, A message has appear the following error message:Setup has detected a newer version of Internet Explorer already installed on this system.Setup cannot continue.
Hi cook,
What version of IE are you trying to install? IE7, or IE6?
If you're trying to reinstall IE6, you probably want to re-apply XP SP2. (See How to reinstall or repair Internet Explorer and Outlook Express in Windows XP
. If you're trying to reinstall IE7, you might consider uninstalling it first.
Hello Molotov,
I tried to reproduce your usage of Process Explorer and Procmon concerning the (anti)phishing filter in IE.
I followed your procedure to catch in each case the stack where ieapflt.dll appeared (it was not so obvious to catch the right thread!).
For some reason, I was able to get the symbols in the stack for ieapflt.dll with Proc Exp but not with ProcMon,(although the symbols are set OK) do you have any explanation? Thanks
Hi dirbase,
Are you saying you're not able to catch a thread executing code in ieapfltr.dll, using Process Monitor's profiling events? Or you are unable to get the symbols for ieapfltr.dll to resolve when using Process Monitor, but the symbols do resolve when you use Process Explorer?
You might want to consider setting an environment variable named DBGHELP_LOG in an instance of CMD.EXE, and have it point to a log file such as C:\Temp\DBGHELP.LOG. Then, from that instance of CMD.EXE invoke procmon.exe; it will inherit the environment of the parent process and symbol engine activity will be logged to C:\Temp\DBGHELP.LOG. So, when you attempt to inspect the stack of an event continaing calls in ieapfltr.dll, the log should have some details as to why symbol resolution is not working.
In short...
1) Launch CMD.EXE
2) Execute [set DBGHELP_LOG=C:\TEMP\DBGHELP.LOG] (without the []'s)
3) Launch procmon.exe from CMD.EXE
4) Check the stack for some events
5) Check C:\TEMP\DBGHELP.LOG if you notice symbol resolution anomalies
Kind regards,
--molotov
Hi Molotov,
I was unable to get the symbols for ieapfltr.dll to resolve when using Process Monitor (PM), but the symbols do resolve when I use Process Explorer (PE).
I did what you recommended. This is the portion of interest of the dbghelp.log file, obtained when checking the stack with PM:
DBGHELP: _NT_SYMBOL_PATH: symsrv*symsrv.dll*d:\symbols*http://msdl.microsoft.com/download/symbols
DBGHELP: Symbol Search Path: .;symsrv*symsrv.dll*d:\symbols*http://msdl.microsoft.com/download/symbols
[....]
SYMSRV: d:\symbols\ieapfltr.dll\4758AB2260000\ieapfltr.dll not found
SYMSRV: http://msdl.microsoft.com/download/symbols/ieapfltr.dll/4758AB2260000/ieapfltr.dll not found
I noticed that the ieapfltr.dll which appears in my c:\windows\system32 directory is version 7.0.6000.16461; I am not sure yours was the same when you did your stack look-up.
I also note that Bryce says, in the Windows Sysinternals forum, that :
"ProcMon and ProcExp use different mechanisms for resolving symbols because ProcMon supports resolving symbols on machines other than the one on which the trace was collected. The mechanism that ProcMon uses requires that the symbol engine have access to both the module (.exe, .dll or .sys file) and the pdb in order to resolve symbols. You need to make sure those files are somewhere the symbol engine can find them." and also
"..occasionally MS will release a hotfix that includes a module (dll/exe) that they provide symbols for, but don't place a copy of the module itself on the symbol server. The symbol engine requires a copy of both the exe/dll and the pdb to work correctly.."
Could it be that for this dll version, MS provided the symbols (the .pdb file was loaded and PE could use that) but not the module itself on the symbol server (the engine used by PM could not find it)?
I found a temporary workaround by adding "c:\windows\system32;" to the symbol path for PM.
After doing that, the symbols for ieapfltr.dll where resolved in PM and the dbghelp.log had this:
DBGHELP: _NT_SYMBOL_PATH: c:\windows\system32;symsrv*symsrv.dll*d:\symbols*http://msdl.microsoft.com/download/symbols
DBGHELP: Symbol Search Path: .;c:\windows\system32;symsrv*symsrv.dll*d:\symbols*http://msdl.microsoft.com/download/symbols
[...]
DBGHELP: c:\windows\system32\ieapfltr.dll - OK
DBGHELP: No header for c:\windows\system32\ieapfltr.dll. Searching for image on disk
DBGHELP: c:\windows\system32\ieapfltr.dll - OK
DBGHELP: c:\windows\system32\ieapfltr.pdb - file not found
DBGHELP: c:\windows\system32\dll\ieapfltr.pdb - file not found
DBGHELP: c:\windows\system32\symbols\dll\ieapfltr.pdb - file not found
DBGHELP: ieapfltr - public symbols
d:\symbols\ieapfltr.pdb\BCE9452F747042FC8C21506DF6A5FA2A2\ieapfltr.pdb
I would think that this is a temporary workaround only, since forcing an initial search in \system32 could lead to wrong symbols resolution if the right-version dll is located for example in the application directory..
Thanks for your interest in clearing this up!
Sorry some lines were cut, here there are again:
First set:
DBGHELP: _NT_SYMBOL_PATH: symsrv*symsrv.dll*d:\symbols*http://msdl.microsoft.com
/download/symbols
DBGHELP: Symbol Search Path: .;symsrv*symsrv.dll*d:\symbols*http://msdl.microsoft.com
/download/symbols
SYMSRV: d:\symbols\ieapfltr.dll\4758AB2260000\ieapfltr.dll not found
SYMSRV: http://msdl.microsoft.com/download/symbols/ieapfltr.dll
/4758AB2260000/ieapfltr.dll not found
second set:
DBGHELP: _NT_SYMBOL_PATH: c:\windows\system32;symsrv*symsrv.dll*d:\symbols*http:
//msdl.microsoft.com/download/symbols
DBGHELP: Symbol Search Path: .;c:\windows\system32;symsrv*symsrv.dll*d:\symbols*http:
//msdl.microsoft.com/download/symbols
DBGHELP: c:\windows\system32\ieapfltr.dll - OK
DBGHELP: No header for c:\windows\system32\ieapfltr.dll. Searching for image on disk
DBGHELP: c:\windows\system32\ieapfltr.dll - OK
DBGHELP: c:\windows\system32\ieapfltr.pdb - file not found
DBGHELP: c:\windows\system32\dll\ieapfltr.pdb - file not found
DBGHELP: c:\windows\system32\symbols\dll\ieapfltr.pdb - file not found
DBGHELP: ieapfltr - public symbols
d:\symbols\ieapfltr.pdb\
BCE9452F747042FC8C21506DF6A5FA2A2
\ieapfltr.pdb
Could it be that for this dll version, MS provided the symbols (the .pdb file was loaded and PE could use that) but not the module itself on the symbol server (the engine used by PM could not find it)?
I think this is a likely explanation.
I would think that this is a temporary workaround only, since forcing an initial search in \system32 could lead to wrong symbols resolution if the right-version dll is located for example in the application directory..
I think your "temporary workaround" is the one that makes the most sense in this case, and really doesn't need to be that temporary. Some mechanism (checksum or the like) is used to tie the PDB with the module it is associated with. So in the event that the symbol engine found a same-named, but "physically" different module in a folder that's in the symbol path, it would be ignored if it didn't match the PDB.
Good work!
OK then I'll maintain the workaround for a while :-)
Since I got this stack from the updated (anti)phishing filter , I can compare it with your earlier version, where you had up to 23 frames related to this dll in one stack in December 2006. I got now no more than 14 frames in the same stack under ieapfltr.dll, including this telltale one:
U 31 ieapfltr.dll ProcessingThread::LookupURLsInUrs + 0xbd
which I decode as: "look up [these] URLs in the [MS] URL Reputation Service (Urs)".
Cheers and congrats for this very instructive blog!
which I decode as: "look up [these] URLs in the [MS] URL Reputation Service (Urs)".
Makes sense to me! :)
Thanks, dirbase.
Unfortunately, the rules which dictate how MS updates the DLL Help Database are not clear. So, for the case of ieapfltr.dll specifically, one does not know which version(s) may have been released since the initial experiment, and now, as no entries for ieapfltr.dll are returned.
"no entries for ieapfltr.dll are returned"
This is not surprising because IE 7.0 is not listed in the list of products.
Apparently it's been a while since dll help has been last updated!
This is not surprising because IE 7.0 is not listed in the list of products.
Yes, the product list (or, all of the DLL Help Database) seems to have been left to decay. No Vista in the list, still, either...
Hi again!
I still have some difficulties with the symbols:
two applications seem to have opposite recommendations:
Kernrates "usage guide" says:
"Kernrate will append
%WINDIR%\SYSTEM32\DRIVERS; %WINDIR%\SYSTEM32; %WINDIR% to the end of the [symbol] path string."
WinDebug help file (in the verifying symbols page) says:
"If you are using the kernel debugger make sure your local %WINDIR% is not on your symbol path."
Can you please reconcile these two statements?
Hi DirBase,
Probably, the key is in the wording of the statement:
"If your symbol path is wrong, fix it. If you are using the kernel debugger make sure your local %WINDIR% is not on your symbol path."
I would interpret this as... If you're using the kernel debugger, the debugger system ("your" system) should not have the symbol path pointing to your local %WINDIR%. Perhaps in other words, the system used for kernel debugging need not be the same platform as the debuggee.
Hope this helps.
Kind regards,
--molotov
Thanks for sharing your interpretation.
Post a Comment