Solved

IExplore.exe remains as active process

Posted on 2004-04-02
10
1,675 Views
Last Modified: 2012-05-04
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?
0
Comment
Question by:braunp
10 Comments
 
LVL 6

Expert Comment

by:jthow
ID: 10747007
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
 
LVL 5

Expert Comment

by:Droby10
ID: 10748051
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
 
LVL 2

Expert Comment

by:The_Master_Chief
ID: 10748433
Do you have a history kill application installed and running?
0
Use Case: Protecting a Hybrid Cloud Infrastructure

Microsoft Azure is rapidly becoming the norm in dynamic IT environments. This document describes the challenges that organizations face when protecting data in a hybrid cloud IT environment and presents a use case to demonstrate how Acronis Backup protects all data.

 

Author Comment

by:braunp
ID: 10750705
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
 

Author Comment

by:braunp
ID: 10750716
Re: The Master Chef's history kill ap - the obvious answer is No
0
 

Author Comment

by:braunp
ID: 10750751
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
 
LVL 5

Expert Comment

by:Droby10
ID: 10750834
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
 
LVL 5

Expert Comment

by:Droby10
ID: 10750839
err..ignore the svchost it should be the application name for the fullpath provided in [application]
0
 

Author Comment

by:braunp
ID: 10751053
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
 
LVL 5

Accepted Solution

by:
Droby10 earned 250 total points
ID: 10751135
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

Featured Post

Backup Your Microsoft Windows Server®

Backup all your Microsoft Windows Server – on-premises, in remote locations, in private and hybrid clouds. Your entire Windows Server will be backed up in one easy step with patented, block-level disk imaging. We achieve RTOs (recovery time objectives) as low as 15 seconds.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

NTFS file system has been developed by Microsoft that is widely used by Windows NT operating system and its advanced versions. It is the mostly used over FAT file system as it provides superior features like reliability, security, storage, efficienc…
One of the biggest threats facing all high-value targets are APT's.  These threats include sophisticated tactics that "often starts with mapping human organization and collecting intelligence on employees, who are nowadays a weaker link than network…
This Micro Tutorial will teach you how to censor certain areas of your screen. The example in this video will show a little boy's face being blurred. This will be demonstrated using Adobe Premiere Pro CS6.
Windows 10 is mostly good. However the one thing that annoys me is how many clicks you have to do to dial a VPN connection. You have to go to settings from the start menu, (2 clicks), Network and Internet (1 click), Click VPN (another click) then fi…

813 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

15 Experts available now in Live!

Get 1:1 Help Now