Solved

IE 8 keeps hanging up and freezing on Windows XP SP3

  • 15 October 2012
  • 33 replies
  • 201 views

  • New Voice
  • 10 replies
Have had webroot secureanywhere running with mcaffe security center v11 for months w/o problems.  I let them update when the need arises.  I have had both scan the system including other independent products and no virus or trojans id'd.  Some pups but of the general nature ones.
 
Nothing worse when you are in the middle of something and the screen starts freezing.  Updated the video drivers and it seemed to eliminate the issue but returned aparadically.  Stated IE without addons but didn't solve the freeze.  Then decided to shutdown SecureAnyWhere and have not yet had the type of freeze (other than perhaps some impatience) previously experienced..
 
Don't like the idea of having the product shutdown since i'm a paid subscriber but something is going on that is causing a significant conflict and eventual screen freeze and it appears related to secureanywhere.
icon

Best answer by Kit 13 November 2012, 00:31

View original

33 replies

@kit - the only two items that show up in protected applications, both as protected are;
 
- regsvr32.exe
- iexplore.exe
 
Userlevel 7
@ wrote:
@;  shut the identity shield off as you have suggested.  So far, no freezes so we may have isolated the area where the problem is coming from. 
Excellent.  When you are comfortable considering this to be the definite source (I'm pretty sure it is), you may continue as described below.
 
Please check the "Edit/View Protected Applications" link under the Identity & Privacy tab.
1:
Look for anything you absolutely trust marked as "Block".  If you find this, change it to Allow.  You are done and good to go in this case.  For bonus points, feel free to contact support and let them know what was under block that you allowed and fixed it.
2:
Look for anything that you have absolutely no idea about marked as Block.  If you find this, and can't identify it, contact Support and advise them about the information I am giving here.  They will need a full set of wsalogs and will instruct you on how to get them if you have not done so already.
3:
If you find nothing blocked, as a temporary measure you may set iexplore.exe to Allow instead of Protect and contact support.  They will need full wsalogs in that case and will instruct you on how to acquire them if you have not done so already.
 
Once this is done, in any case, you may turn the ID Shield back on.
 
Way too much info bonus section:
The ID shield specifically prevents blocked and sometimes certain other processes from accessing various resources when a protected browser window is open.  Applications should not have any problem when they can't get these, however in order for that to be the case, the application must be written properly, and if it isn't, it'll have problems.  If an addon in IE is being blocked from accessing IE and isn't written properly, it will freeze up IE while it tries to get the data it wants and can't.  If something else on the computer is trying to access IE and can't, it might freeze up other things on the computer while it is being blocked.
@Kit;  shut the identity shield off as you have suggested.  So far, no freezes so we may have isolated the area where the problem is coming from. 
Userlevel 7
If it's occurring when the Webroot firewall is running, then the firewall has to be blocking something from connecting to the internet.  Unless you uninstalled an reinstalled Webroot or cleared out the old logs since the last time it happened, the logs will allow us to see what was connecting to where.  This is more worrisome since we normally only block cases where it would try to download a threat.  I'd say that the wsalogs.exe program is your best bet as long as you haven't cleared logs since the last time it crashed.
Have not sent up any logs as of yet. I disabled the Webroot firewall and problem went away. Am I positive it was the Webroot firewall specifically. No. Is it some other function of Webroot. I do not know. But if you shut off the firewall and the problem disappears, what do you think. My interpretation is something in the Webroot firewall and Foxfire/Seamonkey do not coexist correctly. I will need to reable the Webroot firewall and wait for a crash again. I remember when it happens, it is always Webroot reporting the problem. The problem does not occur with Webroot firewall off. Never. I may decide to chase that problem or just leave the Webroot firewall off. I am using the windows firewall and besides I have hardware firewall set up in my router. So it is really a non issue for me. I guess it might help tech support or some other users if I sent up a log. When I find some time I will send it up.
I started using Webroot about 4 or 5 months ago. The antivirus section is  not even that good. It has missed viruses that my offline virus scanner that I have created a dvd for never misses. I have used Norton, AVG, Mcaffee, panda. They all have issues. But I have a subscription for a year and will keep an eye on it.
Bernie
Userlevel 7
@DB:
 
Just requesting the ID shield be disabled specifically.  Main window, click on the Identity & Privacy tab at the top, then click on the green "Switch" to the left of the words "Identity Shield is On" to turn it off.
 
@berniez:
 
Our SecureAnywhere firewall is a network firewall only ans doesn't care about memory consumption.  Are you certain it was a Webroot firewall warning specifically? 
 
The process "plugin-container.exe" is the Firefox sandbox for all plugins.  PDFs, Flash, and other things loaded inside the browser in plugins will load inside that process to try to keep them away from the rest of the computer.  If the plugin-container.exe process was taking up too much memory, there had to have been something flash (video, animated stuff, or a threat) loading, or something else that uses the plugin system loading, and taking up WAY more memory than it should.  This can be caused by so many diffrent things that I can't begin to speak on them unfortunately.  I looked to see if there were logs from your ticket, but if you supplied wsalogs results at any point, they were not from the email you used on the forums.  This case is best handled through the ticketing system though, since there are so many possibilities, the logs will help narrow it down.
Userlevel 7
Badge +56
Can you please Submit a Support Ticket so support can help you futher and please let us know the out come so it may help other users.
 
Thanks,
 
TH
One other item. plugin-container.exe is in my allowed Webroot firewall list. Actually I think it may be twice.
Bernie
I actually run Seamonkey which is Firefox and Thunderbird combined in one suite. Designed by the Mozilla team. That is why you see plugin-container.exe  I understand what you are telliig me here. I can only tell you shutting off the Webroot firewall stopped the crashing on my machine. As I posted, Webroot would post the warning about plugin-container eating all the resources and caused the crash. I do not get a blue screen. The machine locks up, the computer beeps, and then after about 90 sconds beeps again and the warning message comes up. I can then go forward. I am using Seamonkey 2.13.2 which is built on Firefox 16.0
Bernie
Userlevel 7
Badge +56
Hi Bernie just to let you know that the Webroot firewall is only outbound and Windows firewall is inbound and is recommended that you run both and plugin-container.exe is part of Firefox can I ask which version of Firefox you are using as I have v16.0.2 and don't see plugin-container.exe in my firewall list? https://detail.webrootanywhere.com/agenthelp.asp?n=Managing_network_applications
 
TH
I had a similar proble with Windows XP service pack 3. Only happened when I was using my browser. Total lockup for about 90 secocnds and then system released. According to Webroot a file named plugin-container.exe was maxing out my memory resources and the firewall tried to stop it. Thereby locking up the machine. I found the Webroot firewall was the problem. Disabled the Webroot firewall and run the Windows firewall and so far all is well. Pretty weird as this ony started happening the last month or so.
Bernie
reset IE based on Kit's suggestion and like the other user indicated it did not solve the freeze.
 
brought WBS online after reboot and went thru the IE8 auto dialogue again....    within short period of time FREEZE.
Get rid of WBS by shutting it down - NO Problem experienced.
 
Not sure what exact steps to take with the Shields as there are way too many to try and understand and too vague of instructions to an end item customer especially if i am reading it correctly I need to keep track of what's being manipulated nothwithstanding whatever exposure there is from there not being active.. 



Userlevel 7
Please update the thread if you try Kit's suggestions and narrow it down to a specific shield. 😃
These are all great suggestions, and I will definitely be following them after hours today. We work 8-5 and I am going to let my users enjoy their Friday. I really appreciate the responsiveness of this discussion board. Thanks!
Userlevel 7
Again, it's not a common issue.  The vast majority of customers on XP and IE8 are not encountering it. Therefore it will require some troubleshooting.
 
Narrowing down which shield function is causing the issue is still the best idea, which is why I requested that you start by disabling the Identity Shield functionality either by turning of the Identity shield or looking into the Protected Applications for anything standing out as blocked and setting everything in there temporarily to Allow.
Yeah, the disabling of our shields/SWA was not a solution but a verification that WSA is the culprit. I will post when I receive a response from support. Thanks for all the info!
@ wrote:
Hi, 
 
Thanks for the updates Mike and DB. I actually tried resetting IE 8 as directed (SOP for stuff like this). I also ran MBam and Superantispyware scans and no virus. This is affecting several machines, all XP SP3 with IE 8. Disabling all shields seems to resolve the issue.
 
Also, other browsers seem immune, as I have directed users to use Chrtome or Firefox as a temp workaround.
 
steve - thanis for the added input.  getting users off with a workaround  is a good thing.
However, disabling all shields seems to me to defeat the purpose of WBS.  But, it does appear to confirm the thought that one (or more) of the shields is causing an incomatability with IE.
Hi, 
 
Thanks for the updates Mike and DB. I actually tried resetting IE 8 as directed (SOP for stuff like this). I also ran MBam and Superantispyware scans and no virus. This is affecting several machines, all XP SP3 with IE 8. Disabling all shields seems to resolve the issue.
 
Also, other browsers seem immune, as I have directed users to use Chrtome or Firefox as a temp workaround.
 
I will open a support ticket, update upon results.
 
Steve
Userlevel 7
I'm web QA so there isn't time for anything else really.

A rerun of the logs might be a good idea to see if the OS functionality used by the script is working now. I am aware that McAfee is up to date, I was saying that it has been on a relatively long update chain with no clean installs and appears to have a good bit of old stuff sticking around that it should no longer be trying to use, but it is still loading several outdated libraries if I recall correctly. Sometimes cleaning up the old stuff can be helpful.

I still primarily recommend checking stuff in the Identity Shield based on what I'm seeing and the troubleshooting that it will allow us to focus on or rule out.
 
Edit: Corrected some "smart"-phone-based typos.
Kit, thanks... let me digest what you have indicated.  incidently, there is no such thing as extracurricular activity when in Q/A.
 
I can rerun the logs if need be to see if there is a comparison since I ran  MSoft's suggested RegWorks to address any registry issues if that will be of assistance for any comparison.  McAfee Total Protection is v11.6 build 11.6.435 affid 101 and last updated 10/26/2012 while the Scan is version 15.6 build 15.6 .dat vers 6882 build 15.6.231.
 
 
 
best regards
former  SQA & ISO9000 sr. director (now thankfully ret!)
Userlevel 7
@ wrote:
kit, if you took the time to read this, I had submitted all the logs.  I had also indicated initially that I started IE w/o any addons.  Before commenting, please read the entire thread.
Quite sorry.  I am currently in QA, so any work I do on the forums is extracurricular.  :)
 
The information I posted is partially generic and generalized information. 
 
Injected DLLs are also not always in addons, mind you.  As a good example, there is an HP WebHelper.dll being injected into IE that is technically comprised of incomplete code (TODO:<File Description>).   
 
 
Regardless, I found the logs from October 18th.  Didn't look too deeply into them, but on cursory inspection, some stuff jumped out at me.
Things that caught my eye:
 
- There was a threat detected on the initial install of WSA.   This means there could be damage to the system that could not be rolled back by Webroot because it wa preexisting.  Could also be a non-issue, since I research what the items were.
 
- The copy of McAfee installed on the system has been updating since 2006 or so.  You might find it beneficial to either or both: 1: Clear McAfee off and do a clean install of it (make sure you have your license information for them prior to doing so). 2: Tell McAfee to ignore Webroot files, especially c:windowssystem32wruser.dll.  If the second of those works, definitely let us know, as it means that we will want to check on what McAfee is doing and we are doing in response that is causing the issue. (I don't think this is the issue personally, but it's a possibility.)
 
- The logs are incomplete.  Specifically, the Windows Scripting Engine is normally used to gather a set of information using a VB Script in the log-gathering utility, but this information is utterly missing.  The script ran, as the framework is there, but the data is not filled.  Something interfered with a normal Windows function.  This could be any number of things from a limited user account to a security program to damage caused by numerous other things from data degradation to malware to badly-applied patches (never seen that be the user's fault).  The account is not a limited account, so that can't be the issue.  That leaves a question about what blocked the data gathering.
 
The thing that I think might be worth trying that won't take a huge amount of effort though is to try turning off the Identity and Privacy shield in Webroot temporarily, or going into Protected Applications under that section and looking to see if anything interesting (or at all) is set to blocked.  Record or remember the state of the protected applications and set everything to "Allow" with nothing in "Protect" or "Block".
 
I am going to try to encourage escalation of the ticket if possible, since just the quick glance shows me quite a few things that -could- cause the problem, but no clear indication as to what actually is doing so.
kit, if you took the time to read this, I had submitted all the logs.  I had also indicated initially that I started IE w/o any addons.  Before commenting, please read the entire thread.
mike r - I didn't see an image.
Userlevel 7
This is not a universal issue.  For example, it doesn't happen on any system that I have tried it on here.
 
This indicates that there is likely an addon or injected DLL that is being monitored by Webroot and doesn't deal properly with being watched.  In a perfect world, code is written in such a way that it handles pico-delays.  In reality, much of it is pretty badly-written. 
 
A quick contact with support will allow us to check your logs and see if anything like that is the case, or what is going on if not. 
 
Edit: One of the main ideas behind a reset of IE is that it unloads and re-configures all addons and extra stuff that the browser could be loading, so it has a potential to fix things that a lot of other programs can really badly mess up.  If you have a lot of custom configuration in the Internet settings, then you may not want to perform a reset.  If you didn' go poking at the guts of IE's advanced settings, then it should be fine and safe.  It wipes all stuff that has been there over the use of IE and takes it back to a state as if you just ran IE for the very first time.
Userlevel 7
I am interested in the results of an Internet Explorer reset.
 
If you are worried about losing personal settings you can uncheck the "Delete personal settings" check box (see image below).

Reply