Windows 7 SP1 - Starting explorer window in separate process now takes a loooong time RRS feed

  • Question

  • Hi,

    I installed Windows 7 SP1 and I've noticed a change in behavior for Windows Explorer.

    I use a program called FileMenu Tools to add command to the right-click menu. To create shortcuts to various folders, I have programmed FileMenu Tools to run the command "C:\Windows\explorer.exe folder-path ". This worked well before SP1. Now the explorer window appears, but is non-responsive for about 30 seconds to a minute. During this time, the associated explorer process is busy consuming CPU time, mostly in something that looks like Heap Validation (as per ProcessExplorer).

    If I create new explorer windows from an existing explorer window, I have no problems unless I select the option to run new explorer windows in their own process. In that case, the results are the same as running the C:\windows\explorer command.

    Some other things I tried:

    • Start > Run: explorer C:\Users\tony - Same delay
    • Start > Run: C:\Users\tony - no delay

    The first thing I would like to know is whether anyone else can replicate the problem. The easiest way to try is using Start > Run. If no one else is having the problem, then it's likely that the issue comes from some interaction between SP1 and something else on my system.

    The work-around would be program FileMenu Tools to start a new explorer window by asking the existing explorer process to create a new window, rather than creating a new process. I will keep looking, but I haven't figured out how to do this from a command line that I can use with FileMenu Tools. If anyone knows the magic incantation, I would be forever thankful.

    Finally, if anyone knows why creating a new explorer process takes so long, I would appreciate it.



    Wednesday, March 2, 2011 9:36 PM


  • Vegan Fanatic Said:

        Could be something eating the CPU

    Yes, of course. That's why my message stated:

    During this time, the associated explorer process is busy consuming CPU time, mostly in something that looks like Heap Validation (as per ProcessExplorer).

    In any case, I found a solution and a partial explanation.

    I have my own backup program. It first creates a shadow copy of the drive being backed up. Then it mounts the shadow into a folder called D:\Shadows\Shadow YYYY-MM-DD HH-MM-SS . After a backup finishes, I could delete the shadow, but I keep it around as it is easier to retrieve a file from the shadow folder than from the backup drive.

    Something happens after piling up a number of these shadows and the event log starts recording messages like this:

    The description for Event ID 141 from source Ntfs cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

    If the event originated on another computer, the display information had to be saved with the event.

    The following information was included with the event:

    D:\Shadows\Shadow 2011-03-02 17-30-03\System Volume Information\MountPointManagerRemoteDatabase
    the message resource is present but the message is not found in the string/message table

    The message is not the clearest thing in the world, but when I deleted most of the older shadows, performance returned to normal. The interesting thing is that I did not delete Shadow 2011-03-02 17-30-03, as this is currently my most recent backup. I realize that the space for shadows is limited, but I was assuming that Windows would automatically delete the oldest shadow copy when space ran out.

    • Marked as answer by tonyfreixas Thursday, March 3, 2011 5:13 PM
    Thursday, March 3, 2011 5:13 PM