IExplore.exe remains as active process

It started as a graphics problem - the screen would retain windows when the task terminated. The process list shows multiple instances of IEXPLORE.EXE running when there are none in the Applications Task list.

Ending these spurious processes sometimes addresses the problem and the screen display recovers.

I run Sygate as a firewall, AVG for viruses Spybot, Adaware, Spyware Guard and Spyware Blaster, all up to date and run daily
 OS is W2k SP4
Pentuim III with 768K RAM
Nvidia GEForce 256 with 32Mb

Why does IEXPLORE.EXE fail to terminate?
braunpAsked:
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

x
 
Droby10Connect With a Mentor Commented:
so long as you know what it is, and the connections are within a feasible range of usage then there's not much reason to worry.  the stuff that is related to IE is pretty legit, experts-exchange, and a few windows update sites.  the weird thing about the windows update connections is that they are in close_wait status.  which means they've received a close message from the remote host and are waiting for a close signal from you or the application.  it's not out of the ordinary to get a connection in this status - but you typically don't see them for a duration of time unless the application is just flawed in it's handling; which may be one in the same for the lingering IE processes.  a thread stuck on socket close handling could prevent proper handling of WM_QUIT messages in the main thread where it is attempting to kill all the other threads before terminating.

i would say that despite everything we've done, jthow comments to reinstall IE might be the best answer.
0
 
jthowCommented:
Not seen that, except caused by virus / trojan.

If you're sure all your anti virus & anti malware stuff is up to date, try repairing IE.  Control panel; Add & Remove Programs; Microsoft Internet Explorer; Change / Remove & select the repair option.

JohnT
0
 
Droby10Commented:
none of the listed programs will protect you from a majority of the payload driven exploits writen specifically for internet explorer.  your firewall will be ineffective as internet explorer is the one accessing the network...well code running within that process anyway.  virus and malware detections won't have signatures for this (yet).  you might try using foundstone's fport utility to see what ports are bound to internet explorer, cross section that with netstat output, and if available a network monitor log.

it could be a non-malicious ie problem.  but it sure doesn't sound like it.
0
Learn to develop an Android App

Want to increase your earning potential in 2018? Pad your resume with app building experience. Learn how with this hands-on course.

 
The_Master_ChiefCommented:
Do you have a history kill application installed and running?
0
 
braunpAuthor Commented:
Thank you all - Yes, JohnT, I have tried an IE repair but no joy.
I will try Droby10's suggestion but I am iggerent as to The Master Chef's history kill ap - I will have to do some research
Cheers
0
 
braunpAuthor Commented:
Re: The Master Chef's history kill ap - the obvious answer is No
0
 
braunpAuthor Commented:
Good grief! is this because of Microsoft's autoupdate?
Peter

Netstat output
Active Connections

  Proto  Local Address          Foreign Address        State
  TCP    p3:4470                p3:31002               TIME_WAIT
  TCP    p3:4471                p3:31002               TIME_WAIT
  TCP    p3:4472                p3:31002               TIME_WAIT
  TCP    p3:4473                p3:31053               TIME_WAIT
  TCP    p3:4474                p3:31053               TIME_WAIT
  TCP    p3:4475                p3:31053               TIME_WAIT
  TCP    p3:4476                p3:31002               TIME_WAIT
  TCP    p3:4477                p3:31002               TIME_WAIT
  TCP    p3:4478                p3:31002               TIME_WAIT
  TCP    p3:4482                p3:31002               TIME_WAIT
  TCP    p3:4483                p3:31002               TIME_WAIT
  TCP    p3:4923                wu-ori.microsoft.com:http  CLOSE_WAIT
  TCP    p3:4925                v4-ori.windowsupdate.microsoft.com:http  CLOSE_WAIT
  TCP    p3:4927                wustat.windows.com:http  CLOSE_WAIT
0
 
Droby10Commented:
okay regarding the time_wait status.  when a tcp socket tears down it goes through a handshake much like the initialization (only 4 steps instead of 3).  the time_waits are client connections that have been fully terminated but are still resident in memory.  it is normal to have them for as long as a minute or two after the connection has been terminated, but if you find you have a significant number of them, you may want to look into other areas.  if we're talking >25 then i would definately be suspicious of malware acting as a zombie for DDoS attack purposes.  but you will also likely see a good number of established or syn_sent status connections as well.  the local address porting looks normal, but i'm curious what you are running on port 31002.  make use of fport to determine this; it will be listed as:

Pid   Process            Port  Proto Path
420   svchost        ->  31002   TCP   [application]

where [application] is whatever is bound and listening to that port.

IE. should have one or more bound ports (usually client based) but should never have a port in listening status for accepting connections as is illustrated in the client/server time_wait connections.  you might also use the -an flags with netstat

c:\> netstat -an

there are several reasons for this.  first, is that a will list listening ports in addition to established/torn down connections.  the n will provide ip addresses which are a more reliable soure of information than fqhn (dns/host file tampering provides unreliability in host/domain name resolution).  it's also faster.

hope this helps.
0
 
Droby10Commented:
err..ignore the svchost it should be the application name for the fullpath provided in [application]
0
 
braunpAuthor Commented:
Disk alert is the first answer
828   DriveMonitor   ->  31001 TCP   C:\Program Files\Executive Software\DiskArt\DriveMonitor.exe
860   danotification ->  31002 TCP   C:\Program Files\Executive Software\DiskArt\danotification.exe
840   LServer        ->  31053 TCP   C:\Program Files\Executive Software\DiskArt\LServer.exe
 and the netsta -an gives

Active Connections

  Proto  Local Address          Foreign Address        State
  TCP    0.0.0.0:110            0.0.0.0:0              LISTENING
  TCP    0.0.0.0:135            0.0.0.0:0              LISTENING
  TCP    0.0.0.0:445            0.0.0.0:0              LISTENING
  TCP    0.0.0.0:1026           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:1032           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:4923           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:4925           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:4927           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:4929           0.0.0.0:0              LISTENING
  TCP    0.0.0.0:31001          0.0.0.0:0              LISTENING
  TCP    0.0.0.0:31002          0.0.0.0:0              LISTENING
  TCP    0.0.0.0:31053          0.0.0.0:0              LISTENING
  TCP    127.0.0.1:4807         127.0.0.1:31002        TIME_WAIT
  TCP    127.0.0.1:4854         127.0.0.1:31002        TIME_WAIT
  TCP    127.0.0.1:4855         127.0.0.1:31002        TIME_WAIT
  TCP    127.0.0.1:4856         127.0.0.1:31002        TIME_WAIT
  TCP    192.168.0.1:139        0.0.0.0:0              LISTENING
  TCP    192.168.0.1:3002       0.0.0.0:0              LISTENING
  TCP    192.168.0.1:3003       0.0.0.0:0              LISTENING
  TCP    192.168.0.1:3004       0.0.0.0:0              LISTENING
  TCP    192.168.0.1:4581       0.0.0.0:0              LISTENING
  TCP    192.168.0.1:4581       192.168.0.201:139      ESTABLISHED
  TCP    211.30.12.144:139      0.0.0.0:0              LISTENING
  TCP    211.30.12.144:4810     64.156.132.140:80      TIME_WAIT
  TCP    211.30.12.144:4811     64.156.132.140:80      TIME_WAIT
  TCP    211.30.12.144:4815     64.156.132.140:80      TIME_WAIT
  TCP    211.30.12.144:4818     64.156.132.140:80      TIME_WAIT
  TCP    211.30.12.144:4827     64.156.132.140:80      TIME_WAIT
  TCP    211.30.12.144:4828     64.156.132.140:80      TIME_WAIT
  TCP    211.30.12.144:4833     64.156.132.140:80      TIME_WAIT
  TCP    211.30.12.144:4834     64.156.132.140:80      TIME_WAIT
  TCP    211.30.12.144:4835     64.156.132.140:80      TIME_WAIT
  TCP    211.30.12.144:4836     64.156.132.140:80      TIME_WAIT
  TCP    211.30.12.144:4838     64.156.132.140:80      TIME_WAIT
  TCP    211.30.12.144:4839     64.156.132.140:80      TIME_WAIT
  TCP    211.30.12.144:4840     64.156.132.140:80      TIME_WAIT
  TCP    211.30.12.144:4847     64.156.132.140:80      TIME_WAIT
  TCP    211.30.12.144:4850     64.156.132.140:80      TIME_WAIT
  TCP    211.30.12.144:4923     207.46.249.57:80       CLOSE_WAIT
  TCP    211.30.12.144:4925     207.46.245.126:80      CLOSE_WAIT
  TCP    211.30.12.144:4927     207.46.197.59:80       CLOSE_WAIT
  UDP    0.0.0.0:445            *:*
  UDP    0.0.0.0:1025           *:*
  UDP    0.0.0.0:3001           *:*
  UDP    127.0.0.1:3024         *:*
  UDP    127.0.0.1:3033         *:*
  UDP    127.0.0.1:3375         *:*
  UDP    127.0.0.1:3576         *:*
  UDP    127.0.0.1:4227         *:*
  UDP    192.168.0.1:53         *:*
  UDP    192.168.0.1:67         *:*
  UDP    192.168.0.1:68         *:*
  UDP    192.168.0.1:137        *:*
  UDP    192.168.0.1:138        *:*
  UDP    192.168.0.1:500        *:*
  UDP    192.168.0.1:4500       *:*
  UDP    211.30.12.144:137      *:*
  UDP    211.30.12.144:138      *:*
  UDP    211.30.12.144:500      *:*
  UDP    211.30.12.144:4500     *:*

BTW your prompt response is appreciated - Thanks!
Peter















0
All Courses

From novice to tech pro — start learning today.