Geek's summary: Win9x Explorer.exe stops responding for long periods after file operations, and once this starts, it continues as long as Explorer.exe is running.  There may be a fix.

The following situations and bugs are not this problem pattern:

• Problems related to the resident KB891711 patch for MS05-002
• Left-hand "tree" pane does not show changes until F5 pressed
• Fake W: drive letter appears in left-hand "tree" pane
• Drive letters vanish from left-hand "tree" pane
• Delay in displaying contents in right-hand pane
• Namespace icon names spontaneously revert (XP)
• Show full path in title bar setting is lost after Safe Mode
• Status bar not displayed after installing SP2 for XP
• Can't access network share if shared dir name = volume name
• Explorer.exe window does not repaint if drag-and-drop is pending
• Mouse "sticks" and keystrokes ignored during file operations

Affected software

The problem has been described as affecting Windows 98 with Internet Explorer 6 installed.  I've seen it often and for so long that I can't recall whether earlier versions of Win9x and IE are involved, or if it affects Windows ME as well; it does not affect Windows XP.  It has been said that upgrading to Internet Explorer 6 SP1 fixes the issue, but that has not been my experience - I've seen three Win98xx PCs with IE 6 SP1 with this problem in the last week alone.  In my experience, the problem doesn't start straight after any particular upgrade or update.

Failure pattern

The target window of a file operation stops responding when the operation completes, and remains unresponsive for several minutes, then spontaneously returns to normal.  It's interesting that the problem "latches" from non-existence to frequent occurrence at two levels; for the life of an installation, and for the life of an Explorer.exe runtime session.

Details for each affected system:

• Unaffected installations don't have the problem
• Once problem starts, the installation will usually have the problem
• A parallel install on the same PC doesn't have the problem, at first

Details for each affected Windows session:

• Fresh Windows sessions are often problem-free
• Typically, the problem starts after a bulk file operation, e.g.:
    -  deletions (rt-click menu or Del key)
    -  deletions from Recycle Bin
    -  deletions bypassing Recycle Bin by holding down Shift key
    -  file or folder moves
    -  file or folder renames (rt-click menu or F2 key)
    -  New Folder creation
    -  less often; file or folder copies
• Typically, the problem initiator involves multiple files
    -  usually involving 100s to 1000s of files or folders
    -  number of items rather than size of contents
    -  but I've seen it start after an F2 rename of a single item
• Once problem starts, all file operations in that session affected
    -  impossible to do any renames, deletes, New Folder creation
    -  new Explorer.exe windows affected, old ones OK at first
    -  eventually zeroth instance (desktop, Start Menu etc.) affected
    -  I resort to Command.com to do file operations once this starts
• Terminating Explorer.exe clears the problem session:
    -  Ctl+Alt+Del, Explorer.exe, End Task (desktop repaints, etc.)
    -  Shutdown, or shutdown and restart Windows

Details for each problem event:

• During the file operation, the target window is responsive
• The file operation completes normally
• The target window stops responding, and during this time:
    -  no part of the window is repainted
    -  in drag-and-drop cases, source window is unaffected
    -  other windows can navigate into target location
    -  all expected file changes in that location are completed
    -  initially, all other Windows Explorer windows behave normally
    -  mouse still moves and pointer type changes normally
    -  keystrokes to other windows are not delayed or ignored
• After several minutes, the window behaves normally again   

*  It's standard practice here to set Explorer instances to run as separate threads

The following do not exclude the problem:

• Safe Mode
• MSConfig suppression of the startup axis
• Avoiding low resources as per Resource Meter
• Disabling "View As Web Page" and Active Desktop
• Choosing no-(x,y)-position views, e.g. List or Details
• Renaming away or deleting the AppLog folder (reported)
• Doing a Scandisk
• Doing a Defrag
• Excluding malware and \Autorun.inf
• Suppressing autorun via NoDriveTypeAutoRun
• Absence of LAN and/or mapped drive letters
• Clearing all Recycle bins
• Changing Recycle Bin settings (reported)
• Any particular hardware items or drivers

Speculations

Resource heaps: I've seen variable mileage with this, i.e. Resource Meter reporting low heap space when the problem occurs, but I've seen low heap space and no problem, as well as the problem with normal heap space, on the same affected PC.  I also notice no correlation to uptime, as would be typical if heap leakage were a trigger factor.

GDI issues: Failure to repaint any part of the target window has been interpreted as a sign that a GDI failure is the cause.  As other windows are not affected, I think the mechanism is more likely due to the target window being "too busy" to process OS messages to that process, so that the process fails to repaint itself after messages that indicate a need to do so.

Per-item overhead: Because this is usually associated with large number of items, one wonders if this is a scalability issue, e.g. that some per-item overhead has been underestimated.  Relevant observations:
  -  problem starts only when the operation is "finished", so it's not an on-the-fly "cost"
  -  even the initial trigger operation can be "small", i.e. renaming one file
  -  duration of post-operation problem period feels the same, unrelated to item count
Whatever the cause, it seems to follow at the end of the operation (perhaps the code is expected to finish quickly enough not to bother including it in the "progress indicator" period), or after the operation function has completed and returned.

Recycle Bin Desktop.ini: At one time, I thought I found the cause; absence of Desktop.ini in a \Recycled in one or more hard drive volumes, causing that volume's Recycled to display a generic yellow folder icon.  At first it appeared that deleting a Desktop.ini in a volume's \Recycled would precipitate the problem and that copying one back (all volumes' \Recycled seem to have identical Desktop.ini) would clear it.  But as testing went on, this became inconclusive.

Swap file or free HD space: This is not a factor, as I've seen this when there's over 1G of free space on all volumes, and when free space is more than double the bulk of the file operation.

Low memory: Not a factor either, as I've seen this with anything from 16M to 512M physical RAM, and with ample free space on C: for an unlimited "let Windows manage..." swap file.

Typical setup

Most systems I set up have the following in common...
  -  primary C: plus D:, E:, F: on extended partition
  -  mix of FAT32 and FAT16 volumes
  -  each Explorer session to run as new process
  -  show all files, paths and extensions
  -  disable active desktop and View As Web Page
  -  display List view
  -  NoDriveTypeAutoRun = 9D or BD (suppress HD autorun)
...but I've seen this with more "generic" systems as well.

Solutions

It has been noted that uninstalling IE 6 and falling back to older versions, typically IE 5.5, fixes the problem - at the risk of bringing back the MIME-spoofing defect and other vulnerabilities.

A better fix is suggested at http://www.frankprovo.com/win98ie6filesproblem.htm:

• Get out of Windows into DOS mode (not a DOS window!)
• Copy BrowseUI.dll and BrowseLC.dll to Internet Explorer's base directory
• Overwrite these .DLLs in the System directory with those from IE 5.5
• It is reported that IE 5.5 SP2 versions of these .DLLs will work

I like the sound of this fix, as it preserves most of IE 6, and there have been many claims that this not only fixes the problem, but causes no other problems that one might expect from the "version soup" effect.

To be confident of the safety of this fix, I'd like to know what exploits (if any) are re-exposed by reverting to IE 5.5 SP2 versions of these two .DLL files, and this could be tricky to test definitively if some contexts access the ones in System while others access the ones in Internet Explorer base directory.

(C) Chris Quirke, all rights reserved, April 2005

Back to index