Search code examples
windowsbatch-fileexplorertaskkill

Restarting explorer.exe only opens an explorer window

The Problem

In one part of a batch file (kind of, see Extra Information) I need to restart Explorer, so I use the, tried-and-tested method of

taskkill /f /im explorer.exe >nul
explorer.exe

Then this happens

  1. explorer.exe is successfully terminated
  2. explorer.exe is started (see Image 2), but only an Explorer window opens, which I am left with indefinitely (see Image 1)

I can then only properly restart Explorer by starting a new task from Task Manager, as, I'm assuming, Win + R is part of Explorer.

Extra Information

Now, I say "kind of" as I'm running the batch file from a self-executing SFX archive, created with WinRAR. So, when executed, the contents of the archive are extracted to %temp% and a user-defined file (usually a boot-strapper and, in this case, my batch file) is run upon successful extraction.

So far, I've deduced

  1. explorer.exe definitely is being fully killed.
  2. The batch file definitely is called and executed correctly, as it runs and everything else in the script works as designed, except for the line that starts explorer.exe
  3. The command to restart Explorer isn't "badly timed", or anything, as I've tried delaying it.
  4. The batch file works perfectly when manually extracted from the archive, so it's not a problem with the compression or extraction processes.
  5. Even with commands like start explorer.exe | cmd.exe Explorer doesn't restart properly, so it's definitely not a problem with the .bat file.

I can confirm that it works on Windows XP and Windows 7 x86 but not Windows 7 x64 (which is my system).

Status

At the moment, I'm suspicious of WinRAR, as I've proved that the code itself works. So, I'm creating the self-executing SFX with different versions of WinRAR. So far, I've tried versions:

  • 4.11 x86
  • 4.11 x64
  • 4.20b3 x86
  • 4.20b3 x64

and had the same results every time.

I submitted a bug report to [email protected] yesterday and got a reply from Eugene Roshal himself this morning

Hello, SFX module uses ShellExecuteEx to start a setup application. Normally it works well. I do not know why Explorer decides to switch to windowed mode. Now I built a small standalone program

#include <windows.h>    
void main()
{
  SHELLEXECUTEINFO si;
  memset(&si,0,sizeof(si));
  si.cbSize=sizeof(si);
  si.lpFile="test.bat";
  si.nShow=SW_SHOWNORMAL;
  ShellExecuteEx(&si);
}

which runs test.bat with contents as in your sample. This program shows exactly the same behavior as WinRAR SFX, so Explorer is started in window.

and a second email this morning

Sorry, no advice now. I replaced ShellExecuteEx with CreateProcess

#include <windows.h>
void main()
{
  STARTUPINFO si;
  PROCESS_INFORMATION pi;
  memset(&si,0,sizeof(si));
  si.cb=sizeof(si);
  CreateProcess(NULL,"test.bat",NULL,NULL,TRUE,0,NULL,NULL,&si,&pi);
}

but result is the same. I tried to use other SW_ flags like SW_SHOWDEFAULT or SW_RESTORE with ShellExecuteEx also as "open" and "explore" lpVerb, but it does not help. For now I do not understand the logic behind this windowed versus desktop mode.

I realise the outlook is grim but, I hope that's of help to someone..

Proof / Evidence

Link to an SFX archive demonstrating this, if anyone wants it: https://dl.dropbox.com/u/27573003/Social%20Distribution/restart-explorer.exe

image 1

image 2

You may notice here that I'm running the commands inside a VM (as denoted by VMwareTray.exe) but it is not a VM-caused conflict. I've tested the exact same files on my own host system (which is the same OS) and have had the same results.

Update

I'm experiencing similar "works outside of an SFX archive but not from one" problems when using REG ADD in a completely different project. I just don't think SFX archives play nice with batch files.

Solution

  • The other day, I was having a look through some of WinRAR's more advanced options and came across this tab:

    enter image description here

    As soon as I saw that I suspected it to be part of the problem and solution, as this issue only ever occurs on Windows 7 x64.

    As suspected, using the Default64.SFX module instead of the default Default.SFX module entirely fixed the issue. Finally.