zombie IE processes

Discussion in 'Internet Explorer' started by George Neuner, Sep 8, 2013.

  1. Hi all,

    I administer a 2 user machine running Win7 Home 64-bit and IE10 that
    of late is accumulating detached IE processes. The users don't always
    log out but they do pretty faithfully close applications before they
    leave the machine. After a few days running, there may be a dozen or
    more instances of IE with no visible browser windows. The detached
    instances may be running under either username and always are in
    pairs: a 64-bit parent and a 32-bit child.

    The machine normally runs Avast v8 antivirus and Comodo v5 firewall,
    and additionally blocks known malware and tracking sites with the
    hosts file. I have boot scanned it for malware using a few different
    antivirus packages ... so far nothing.

    Some googling has revealed that the cause of IE zombies might be a bad
    add-on or extension. However, apart from Avast's hook modules,
    everything is vanilla IE. Additionally, all the MS provided social
    media crap has been disabled for all users. Checking the Avast user
    forums, it seems no one is complaining about problems with their IE
    extensions. Additionally, I have Avast running on several machines -
    most with much more complex IE setups - only this relatively simple
    one is having problems.

    I know that errant scripts can silently crash IE and prevent it from
    closing, but as far as I can determine, this is not the case here. I
    have looked at the browser histories and gone to many of the sites
    from the problem machine ... but whenever I do it, IE closes properly
    without leaving a zombie process. And much of the time the users are
    going to different sites with little or nothing in common.

    At this point I'm stumped. Any ideas would be appreciated.
    Thanks,
    George
     
    George Neuner, Sep 8, 2013
    #1
    1. Advertisements

  2. George Neuner

    Mayayana Guest

    I've only seen that kind of thing when creating IE
    instances in scripts. (Since IE runs in its own process
    it can be left hanging if a script crashes.)

    I don't know whether this will be helpful, but if you
    can't figure it out you might use the following script
    to enumerate open windows and access the document
    object for any open IE instance:

    '----------------------------------
    Dim Shl, s, Win, Wins, FSO, TS

    Set Shl = CreateObject("Shell.Application")
    Set Wins = Shl.windows
    On Error Resume Next
    For Each Win in Wins
    If TypeName(Win.document) = "HTMLDocument" Then 'IE instance
    s = s & Win.LocationURL
    s = s & vbCrLf & vbCrLf
    With Win.document
    If .compatMode = "CSS1Compat" Then
    s = s & .documentElement.innerHTML
    Else
    s = s & .Body.innerHTML
    End If
    End With
    s = s & vbCrLf & vbCrLf
    End If
    Next

    Set Wins = Nothing
    Set Shl = Nothing

    Set FSO = CreateObject("Scripting.FileSystemObject")
    Set TS = FSO.CreateTextFile("C:\IEs.txt", True)
    TS.Write s
    TS.Close
    Set TS = Nothing
    Set FSO = Nothing

    MsgBox "Done."
    '-----------------------------------

    Copy that to Notepad, save it with extension .vbs,
    and run it. It will write a file to C drive named IEs.txt
    that will contain the URL locations and document
    content of all open IE instances. ... At least it *should*.
    Different versions of Windows might be slightly different.
    I just wrote this on XP. It very likely works on Vista/7,
    but there could be some minor change, like that maybe
    TypeName(Win.document) is not exactly "HTMLDocument"
    or some such.

    Knowing what's in the hidden windows might yield a clue.
    (Or it may just be an IE10 bug. I don't know.)

    The way it works is to use Shell.Application to enumerate
    all open "Explorer" windows. When MS came out with Active
    Desktop (as part of their response to the Netscape court
    case) they put a browser window in all folder windows and
    proclaimed that IE and Explorer were the same thing. For
    the sake of backward compatibility it still works that way,
    even though there's been no actual IE broswer window in
    folder windows since WinME. The Windows collection consists
    of all open instances of IE and Explorer folders.
    TypeName(Win.document) provides a way to distinguish
    them. The IE instances return an actual IE document for
    Win.document. The open folder windows also have a
    document property but it returns the ShellFolderView
    object for the folder!
     
    Mayayana, Sep 8, 2013
    #2
    1. Advertisements

  3. George Neuner

    VanguardLH Guest

    Go back to IE9.
    Disable GPU acceleration.

    IE10 is a frankenjob web browser. Microsoft wanted to move to a 64-bit
    web browser but wanted to continue supporting 32-bit add-ons (since not
    all 32-bit add-ons yet have 64-bit equivalents). So IE10 loads as a
    64-bit process but the tabs are 32-bit. That's why you see an
    iexplore.exe (64-bit) and iexplore.exe*32 (32-bit) processes listed in
    Task Manager's Processes tab. That's also why you no longer see the 2
    versions of IE listed in the Start menu as for IE9 ("Internet Explorer"
    and "Internet Explorer (64-bit)"). iexplore.exe under "Program Files
    (x86)" doesn't load a 32-bit version of IE10 but loads a 64-bit version.

    Also, IE10 mandates a DX platform update: KB2670838. This has caused
    all sorts of problems for users regarding destablizing their computer.
    If you install IE10, you get this platform update. To avoid the
    platform update, you need to configure your Windows Update catalog (on
    your own WSUS server or in the WU app) to hide both the IE10 and
    KB2670838 updates; otherwise, the user will get them offered again. I'm
    not sure it is so much a problem when upgrading to IE10 as it is when
    installing the platform update. If you uninstall KB2760838, and because
    IE10 mandates this be present, you will also end up uninstalling IE10.

    http://support.microsoft.com/kb/2670838

    That DX platform update has been a hassle for more than users just
    noticing stability problems on their PCs. According to Microsoft,
    developers must change to a new SDK. They cannot continue using the old
    version. So everyone developing programs that want their use with IE10
    will need to use the new SDK plus require their users to also install
    the platform update. KB2670838 has been dubbed the "Evil Update".

    Microsoft released IE10 for Windows 8 back in Nov 2012. Apparently they
    felt pressured to backport it to Windows 7 and released it Feb 2013. I
    don't see much of anything critical or even important that IE10 has over
    IE9; that is, the feature differences are trivial but the compatibility
    and stability issues are major. This backporting mandated the DX
    platform update in Windows 7 that was already available in Windows 8.
    In fact, considering what features got discontinued in IE10, I won't be
    installing it [again] for quite awhile until web sites catch up by also
    discontinuing use of those same dropped features. See:

    http://en.wikipedia.org/wiki/Internet_Explorer_10#Discontinued_features

    Note that IE10 has rendering problems. I've run across sites where
    spacing is screwed up. There will 2 hyperlinks next to each other. In
    IE9 there is some spacing between them, like seeing "edit" and "delete"
    (both underlined to indicate they are hyperlinks). In IE10, they show
    as underlined "editdelete" and you cannot find a spot between the two
    word for a space (i.e., where your cursor would change to indicate you
    are not hovering over a hyperlink). The cure is to use Compatibility
    View mode. It fixes that problem but causes others, like Google Maps
    linked to inside web pages not displaying. So you fix one rendering
    problem with Compatibility View mode in IE10 but then generate another
    rendering problem. I uninstalled the KB2670838 platform update which
    also uninstalls IE10 and reverted back to IE9 until Microsoft gets
    around to fixing problems with IE10.

    I also ran across problems on my own ISP's web site when logging in.
    With IE9, I can enter my login credentials and get logged in okay. With
    IE10, I'd enter my correct login credentials but the web site would
    respond that I enter them wrong. I would notice in the info message
    from the site that it thought I was trying to logon as a different user.
    I have 5 user accounts at my ISP's site: 1 owner and 4 member accounts
    (so I can have 5 independent e-mail addresses). I was trying to logon
    under a member account but the site would report that I entered the
    wrong password for the owner account (that I did NOT specify). It would
    work better in Compatibility View mode but I really don't want to use
    that unless forced to. A better solution was to revert to IE9 to have
    the sites that I visit render okay and behave normally.

    Also, although it might appear IE9 or IE10 work okay when using GPU
    acceleration mode (Internet Options -> Advanced), too many times old
    hardware that can only use older drivers will generate faults in IE9 or
    IE10 when using GPU acceleration. When IE crashes because of the fault,
    it can still be left loaded in memory. The user might find IE's window
    became unresponsive and closes it thinking the iexplore.exe process will
    also unload but it doesn't, or the crash makes the window disappear so
    the user thinks IE unloaded but the iexplore.exe is still present. The
    user has to do the process kill cleanup after the crash. So you might
    want to look in Event Viewer to see if there are any crashes related to
    IE or to the video driver.

    You might want to revert back to IE9. I've hit sites that don't render
    properly with IE10 and there were scripting anomalies. You might also
    want to disable GPU acceleration. Even users with recent video cards
    with the latest drivers run afoul of that feature and only users
    visiting online graphic gaming sites would care about it. If these are
    business PCs then those users shouldn't be playing online games at work.
     
    VanguardLH, Sep 9, 2013
    #3
  4. George Neuner

    Mayayana Guest

    Very interesting information. I hadn't known anything
    about IE10, though there seem to be a lot of problems
    mentioned in this group. I tried to install it on a Win7-64
    test PC recently, just for testing webpages, and it
    wouldn't take. I was required to install 4 or 5 updates
    first, but somehow the IE10 installer never seemed to
    recognize that those updates were installed. I finally
    gave up.

    To me it seemed like an ominous indicator of where
    Microsoft has gone in recent years. The fact that the
    OS needs separate updates just to install their own
    browser is bizarre in itself. But on top of that, the
    updates apparently don't install properly.
     
    Mayayana, Sep 9, 2013
    #4
  5. George Neuner

    SC Tom Guest

    I have IE10 on two Win7HP-32 machines, and one of them works just fine. The
    other gave me so many problems that it makes Vanguard's problems seem
    trivial :) After fighting it for about a week, I rolled that machine back
    to IE9, and haven't had any more IE problems. On the one that works fine
    with it, I just left it alone. No sense fixing what ain't broke :)
     
    SC Tom, Sep 9, 2013
    #5
  6. Thanks. It does work on XP but not on Win7. I'll have to find out
    more about IE10's COM interface and experiment with it.

    Hanged if I know. I have several machines here all running IE10, but
    only this one is having problems. I don't know what is different.

    George
     
    George Neuner, Sep 12, 2013
    #6
  7. George Neuner

    Mayayana Guest

    Thanks. It does work on XP but not on Win7. I'll have to find out
    more about IE10's COM interface and experiment with it.
    That's odd. I just tried it on Win7-64 and it
    listed both IE32 and IE64 windows. If I uncomment
    the filter to skip Explorer windows then I also get
    those fine. I only have IE8, but I'd be very surprised
    if MS has broken Shell.Application with IE10. That's
    been a supported, documented object since Active
    Desktop.

    You might try commenting out the part
    that writes the file and just show a MsgBox listing
    the locationURL of each window to test restrictions.
    Maybe you're unable to write to C:\. If that's the case
    you might have to just give yourself permission, or
    write to your own docs folder.
     
    Mayayana, Sep 12, 2013
    #7
  8. I should have qualified:

    It doesn't work on Win7 64-bit with IE10. I don't have any Win7
    machines running IE8 ... they're all running 10 and they're all 64-bit
    if that matters.

    You had mentioned that you wrote the script on XP, so I did try it
    there - with IE8 - and it worked fine.

    No permission problems. The script runs without errors and creates
    the output file ... but the file is empty even when IE is deliberately
    open and visibly running.

    FWIW: I am a professional software developer, but I don't work with
    browser apps and I don't do much with VB scripts. I understand what
    the script is trying to do ... I am guessing it doesn't work because
    IE10 uses different DOC tags than IE8.

    I guess I need to poke around in the IE SDK.

    George
     
    George Neuner, Sep 13, 2013
    #8
  9. George Neuner

    Mayayana Guest

    The script runs without errors

    Even if "On Error Resume Next" is commented?
    and creates
    the output file ... but the file is empty even when IE is deliberately
    open and visibly running.
    If you have a copy of Spy++ (Spyxx) there it might
    show something. At least you could check to see if
    there are window titles anywhere. It's very unlikely
    that there's an issue with the IE DOM. In that case
    you'd still get locationURL strings, and probably you'd
    get an error like "No such object: Win.document.body".

    Microsoft has broken compatibility with their old
    object model by making the old and new mutually
    exclusive. There are actually 2 DOMs now. The one
    in effect depends on the DOCTYPE tag. But the script
    I posted accounts for that. It will get the document
    content from either the new (allegedly standards-
    compliant) or old (quirks mode) DOM.

    I'm curious to look into this, but I can't even get
    IE10 to install. :)

    Two possibilities I can think of offhand:

    1) The running instances are some sort of corruption
    or bugginess with IE10, as VanguardLH was indicating
    they might be.

    2) There may be some complication with the tabs,
    like maybe Shell finding parent windows but not
    tab windows. (I've never used tabs and didn't think
    to test that when testing my script on Win7.)
    ** See below**

    3) Avast is a nasty piece of work. Just last week I
    was writing a little program to integrate Google maps/
    earth/streetview, using the G. Maps API with basic
    winsock code that talks to the Google Maps server.
    The program works fine. Google's response is dependable.
    But on one test machine with Avast it would either
    not work, failing with winsock error 10038
    (WSAENOTSOCK - Socket operation on non-socket.)
    or my program would crash. I tried exempting the program
    from Avast restrictions. That didn't work. The only thing
    that worked was to disable Avast "network shield" and
    "web shield". It seemed that Avast was somehow corrupting
    pointers in my software. I haven't figured it out.

    As far as I can tell, Avast has been expanded from an AV
    program to be a wide-ranging behavior-monitoring and
    "reputation" monitoring program. It scans IP traffic as
    part of that and apparently sets up a middleman hook
    for all internet traffic, then checks with the Avast database
    to see whether executables are "reputable", interfering
    with internet activity enough to even crash programs.

    Unfortunately, Avast doesn't seem to provide much control
    to the end-user. The design seems to be aimed at blocking
    just about anything other than known, corporate operations.
    In other words, if you want to use IE or Firefox to access
    gmail or hotmail, it will recognize that as "reputable". But
    anything not known is by definition suspect. Since my program
    is new and goes online repeatedly, which is something that
    malware often does, Avast seems to be deciding to block it,
    despite the exemption settings I set and without any user-
    notification from Avast that it's "taking the law into its own
    hands".

    Long story short: If I were testing anomalies I'd try to
    rule out Avast.

    Another thought: Putting a lot of work into enumerating
    the windows and their content seems like a likely red
    herring, but if you still want to pursue it, I have a shell
    library that should be able to deal with it:

    http://www.jsware.net/jsware/compfiles.php5#jsshl

    The method GetIEDocFromHandle can return a document
    object from any window of class Internet Explorer_Server,
    which is the class of the actual browser window, whether
    it be in IE, an HTA, etc.
    The help for that method explains the details. Having tabs
    in IE complicates things quite a bit, but they can be
    enumerated. If you prefer to have the code for that, there's
    related sample code for Shell at

    http://www.jsware.net/jsware/vbcode.php5

    It basically boils down to a combination of window
    and child window enumeration functions with a very
    interesting and obscure method from oleacc.dll named
    ObjectFromLresult, which provides a way to get at the
    DOM for any true IE browser window. jsShell is a
    scriptable wrapper for all that, and for Active Accessibility
    (oleacc) in general.

    ** Below** Following is part of the help I wrote for
    GetIEDocFromHandle. I'm including it here to show
    how IE tabbed might complicate getting URLs and
    document HTML.
    -------------------------

    Note for use with IE tabs: In later versions of IE, multiple pages can be
    open in tabs. This presents a very different windowing scenario from the
    page-per-window approach. Without tabs, the URL of a loaded page in IE is
    the browser window's title bar text. Loaded pages can be enumerated by
    enumerating top-level windows. When IE is used with tabs, each page is in a
    browser window, which itself is embedded in a window hierarchy, which is
    "descendant" of the main IE window. Each loaded webpage will have its own
    window hierarchy and browser window of class Internet Explorer_Server. The
    page URL will be the title bar text of a window nested in the middle of that
    hierarchy, with a class name of TabWindowClass. Those window titles must be
    enumerated if you want to return a specific webpage document object and not
    just the document from the first Internet Explorer_Server class window that
    the child window enumeration comes across. See the IE tabs demo.vbs sample
    script for a demonstration of how to handle IE with tabs.
     
    Mayayana, Sep 13, 2013
    #9
  10. Ok, then it gives an error on "TS.Write s" in line 26:

    "Invalid procedure call or argument".
    800A0005

    But it only gives the error when an instance of IE is running. If
    there are no instances running there is no error, but the file is
    empty (presumably because there is nothing in 's' to be written).

    ??? It works on XP ... with or without IE running.

    I have a number of tools, but I can't find any open windows associated
    with the detached instances. Their startup command lines also are
    unhelpful as they appear to have been started directly from Explorer
    (i.e. not launched by another app with a URL argument).

    I know I can write something using COM to get at whatever information
    is available via IE's automation interface ... at least assuming those
    detached instances aren't actually crashed. But I've only ever toyed
    with automation - and only with Word - so I was hoping your kindly
    provided script could save me some effort learning about IE.

    I doubt Avast was corrupting your app ... at least I've never seen it.
    Most likely it blocked the URL and aborted the connection.

    I don't know about the crash scenario, but that error will occur if
    your program tried to use the closed socket.

    This problem isn't unique to Avast - it can happen with any local
    firewall software if they interfere and abort the connection. The
    socket structure is destroyed in the TCP stack, but the application
    won't be notified unless you're using asynch sockets.

    Avast was running on the XP machine as well. However, for
    completeness, I disabled it on Win7 and tried the script again.
    No joy - same result.

    Thanks ... I'll take a look at them.

    George
     
    George Neuner, Sep 15, 2013
    #10
  11. George Neuner

    Mayayana Guest

    Ok, then it gives an error on "TS.Write s" in line 26:

    "Invalid procedure call or argument".
    800A0005

    But it only gives the error when an instance of IE is running.
    Weird. It sounds like s is an incompatible data type, but
    I don't see how. And even if it were, that returns a
    type mismatch error. Perhaps the vartype is Null? I don't
    know how to test that. In any case, it sounds like you're
    getting something, but not what it's supposed to be.

    I just tried using tabs in Win7-64 with IE9 and the script
    ran fine. So it's not that. It really does sound like what
    VanguardLH was describing: a rebuild of IE with v. 10 that's
    simply not compatible. (Not much help, I know.)
    I have a number of tools, but I can't find any open windows associated
    with the detached instances.
    Strange. I don't see how an IE instance could run with
    no windows. Normally there are several. For what it's
    worth, I came across something similar to Spy++.

    http://windowdetective.sourceforge.net/

    It doesn't lay out the window hierarchy quite so clearly
    but it's similar.
     
    Mayayana, Sep 15, 2013
    #11
  12. The users don't perceive anything is wrong so my guess is that IE is
    hanging as it closes - perhaps after destroying the document(s), which
    may be why the script fails.

    ProcessExplorer shows the instances are using a tiny fraction of CPU,
    so they aren't completely idle, but they could be stuck in some loop
    trying to release resources.

    George
     
    George Neuner, Sep 16, 2013
    #12
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.