Restarting explorer.exe only opens an explorer window - windows

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
explorer.exe is successfully terminated
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
explorer.exe definitely is being fully killed.
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
The command to restart Explorer isn't "badly timed", or anything, as I've
tried delaying it.
The batch file works perfectly when manually extracted from the archive, so
it's not a problem with the compression or extraction processes.
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 dev#rarlab.com 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
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.

I think user1631170 is on to something, "I wonder if some part of Win-RAR is running in 32-bit mode? Could you even start explorer64 running from a 32-bit process? I am pretty certain that Windows won't do that."
When I start explorer.exe from ProcessHacker (32-bit process manager), I get an explorer window.
But I can force it to start the 64-bit explorer with this:
%systemroot%\sysnative\cmd.exe /c start /B explorer.exe
sysnative is a keyword that Windows recognizes to bypass the file system redirection for 32-bit/64-bit (http://msdn.microsoft.com/en-us/library/windows/desktop/aa384187(v=vs.85).aspx
Enjoy!

I had this same problem and found that all the solutions here still didn't work from a batch script.
None of these worked completely:
start explorer.exe
start explorer
explorer.exe
explorer
because they all either opened a window (and didn't show the taskbar again), or the batch script then hung thereafter and couldn't execute any more commands
I found that this line in the batch file did work (after killing explorer.exe):
start "" "%windir%\explorer.exe"
and also allowed other commands to be executed after it in the script

This works in Windows 7:
taskkill /f /IM explorer.exe
start explorer.exe
exit

For restarting explorer.exe, this worked for me.
powershell.exe Stop-Process -processname explorer

When you run explorer.exe from an 32-bit application in 64-bit windows, the path will be redirected to the SysWOW64 directory which contains the 32-bit explorer.exe.
In XP64 it wasn't not such a big deal. In the taskmanager you can see the 32-bit explorer.exe running but it did start as the shell. In Windows 10 (as I came to this problem, it looks like it is introduced in Windows 7), the 32-bit explorer.exe is a stub which creates a new instance of the 64-bit explorer.exe. It probably passes a path on the commandline here so the 64-bit explorer.exe opens a window instead of starting the shell.
So it is still like before that you can control whether a window or a shell should be started by starting explorer.exe with or without a path as commandline parameter.
Instead, you should force starting the 64-bit explorer.exe from the 32-bit application and all is ok. To do this, one method is using the sysnative directory as mentioned above. But another method is to use Wow64DisableWow64FsRedirection/Wow64RevertWow64FsRedirection.
I did the latter and can confirm it works nicely. For both CreateProcess and ShellExecuteEx API.

Try
%windir%\explorer.exe
start %windir%\explorer.exe
start /d%windir% explorer.exe

I have seen similar problems before doing this in C#. The process had to be invoked by calling explorer shell rather than explorer window, but I haven't had any problems in batch.
Try using this:
taskkill /im explorer.exe /f
explorer
The difference between the other answers being explorer rather than explorer.exe which has caused problems before for me.
This works on my Win7 x64 PC.
Hope this helps!

The other day, I was having a look through some of WinRAR's more advanced options and came across this tab:
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.

I do not understand why, but it will only for me if using the full path, regardless of your PATH variable.
%windir%\explorer

Have same issue with Visual Studio.
What works for me (Win 7 Pro 64bit):
PPM on Project name select "Properties"
Configuration Properties > Build Events > Pre-Build Event
taskkill /im explorer.exe /f
Configuration Properties > Build Events > Post-Build Event
start "" "C:\Windows\explorer.exe"
But this make other problem (the IDE is frozen after the explorer runs) and now I'm only able to restart the IDE to run build command again...

Use this (.bat with administrative privileges) in x64 or x86
tasklist /fi "imagename eq explorer*" | find /i "explorer*"
if not errorlevel 1 (taskkill /f /im "explorer*") else (
start %windir%\explorer.exe

What worked for me in Windows 7 64 bit was
"C:\Windows\expstart.exe"
or just
expstart.exe

Try adding a explorer.exe key to App Paths in the registry.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\explorer.exe
(Default) C:\Windows\explorer.exe
Path C:\Windows
or copy the following to notepad and save it as a .reg file then run it:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\explorer.exe]
#="C:\Windows\explorer.exe"
"Path"="C:\Windows"

To see the start panel you need to execute the explorer.exe from the system32 folder
taskkill /im explorer.exe /f
cd %WINDIR%\system32
start %WINDIR%\explorer.exe

Easy Context Menu
Just right-click on the desktop and choose Restart Windows Explorer. Enjoy!

Related

Running .cmd with 32 bit launcher?

I have spent a lot of hours trying to figure out this simple thing I want to accomplish. I have a .cmd file with one line: sfc /scannow
I wrapped this into a package with the command line as a program at: cmd /c sfc.cmd and this is set to install as required and hidden. (I can look at the cbs log if this actually did run).
So then it get's deployed and downloaded to the test machines and i see it in ccmcache folder. Looking at execmgr.log it executed the following:
"C:\Windows\system32\cmd.exe" /c sfc.cmd, Working Directory = C:\Windows\ccmcache\g\
Running "C:\Windows\system32\cmd.exe" /c sfc.cmd with 32bitLauncher
Those two indicators were noted around 4:43PM. I don't see exit code 0 or any other code. Then looking at cbs.log the last write time was 4:19PM. What am I doing wrong?
If I try to run sfc /scannow from a 32Bit cmd in 64Bit Windows I get an error so you probably have to use a trick to run the 64bit sfc.
Instead of the commandline
cmd /c sfc.cmd
use
C:\windows\sysnative\cmd /c sfc.cmd
Sysnative is an alias that you can unfortunately not see but if a program is started as 32bit process it can access it. What it does is avoiding the WoW64 redirection that intercepts every call to system32 and sends it to syswow64 which in your case leads to a problem.

Making Any Command in CMD work in a .BAT as an .EXE

Redirecting CMD Commands To An EXE File
Long story short, basically I have the problem that every time I run BCDedit on the .BAT that I converted into an .EXE it never worked and I thought that the reason why it wasn't work was because it wasn't on Path but my Path was fine and even if it was on Path is set by default thanks to foxidrive.
Now my main problem is that is there a way I can convert it to an .EXE file with every single command working, is there a technique I could use to get BCDedit working as an .EXE file?
All of the commands do work it just BCDedit and I say if every single command would work so if somebody has a similar command problem like me they know how to figure it out, it works perfectly as batch but is there a way I can convert it and make BCDedit still work as an .EXE?
Please answer As Soon As Possible and if you want to take a look at my Path and Batch the visit the link at the top.
Thank you so much!
Compile this batch file and see if it works:
#echo off
bcdedit /?
pause
Then try this version:
#echo off
c:\Windows\System32\bcdedit.exe /?
pause
Just as the SysWow64 Redirection link you listed states. If you want a x86 application to call the 64-bit system directory you need to call the bcdedit application as follows.
%SystemRoot%\SysNative\bcdedit
This is because of Windows backwards compatibility measures, it is looking at C:\Windows\SysWOW64 instead of C:\Windows\System32. Another alternative would be to compile the script as both x86 and 64-bit, but then you could only use each on the respective systems.
Update for Comments
Even though the path is correct, an x86 application will execute commands or batch scripts against the C:\Windows\SysWOW64\cmd.exe which will cause the path redirection issue. Example to illustrate my point. On a 64-bit version of Windows, open C:\Windows\SysWOW64\cmd.exe and using Windows explorer create two unique files , one is C:\Windows\System32\unique_test64.txt and the other in C:\Windows\SysWOW64\unique_test86.txt. Now on the x86 command prompt enter if exist C:\Windows\System32\unique_test86.txt echo true. You will see that it is being redirected to SysWOW64 and will print true. And if you enter if exist C:\Windows\System32\unique_test64.txt echo true, nothing will be found.
Screenshot Example: http://i.imgur.com/K4kkI29.png

Launch a program asynchronously at startup on Windows 7, just once, using only the registry

The program I am launching is the windows notepad (for a readme file after a program installation requiring a reboot). I am working in Windows 7 Professional, with administrator rights.
I would like to get the following solution working:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce
Name: myregentry
Type: REG_SZ
Data: notepad.exe C:\test2.txt
However, RunOnce is synchronous (http://msdn.microsoft.com/en-us/library/aa376977%28v=vs.85%29.aspx). This results in the notepad launching on top of a completely black screen (screenshot # tinypic), with no possibility to do anything but read the text. Startup waits, and resumes only after the notepad window is closed. This is not acceptable for my use (ti would confuse users).
I could get the following solution to work:
1) Create a registry entry:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce
Name: myregentry
Type: REG_SZ
Data: C:\launchreadme.bat
2) Create a self-deleting batch file at C:\launchreadme.bat:
#ECHO OFF
start notepad.exe C:\test2.txt
REM **** Delete this script ****
DEL "%~f0"
This does what I want. However I'd like to know:
Is there is a cleaner way to do this, without generating this batch file first, so: only using the registry?
This could be useful to others, as the web is full of example of "how to launch the notepad once from the registry", yet none of them (that I could find) mention this issue.
Additional information:
I could not get "start" to work in the registry entry (start notepad.exe C:\test1.txt does nothing on startup).
RunServicesOnce (instead of RunOnce), which used to launch programs once, asynchronously, apparently doesn't exist anymore in Windows 7.
Run (instead of RunOnce) is also asynchronous and works well. But obviously I don't want to launch this readme file after every reboot.
You can use the batch file approach without needing a batch file:
cmd /c "start notepad"

Running Batch Stript in Windows 7 causes process to be launched under wrong cmd process

Whenever I run a batch file on my comuter (64 bit architecture running 64 bit windows 7), the console window that is opened is running in 32-bit mode, and checking the task manager confirms I am indeed running everything as a 32-bit process. I want to run the batch file under a 64-bit process, not a 32-bit process. I have changed the comspec environment variable to point to the proper variable, to no avail. Does anyone know how to fix this so that when I click on the batch file, it everything is run in 64-bit mode.
I realize I could simply open the 64 bit command window and run my batch file. However, this is a workaround and doesn't get at the root of the problem, and won't help when I give file to others.
Thanks,
MM
Are the file associations for .cmd associated with the 32bit cmd.exe or the 64bit cmd.exe?
Can you run the scripts with the full path name to the executable?
"C:\Windows\System32\cmd.exe" /c <batch_name> should run 64-bit
"C:\Windows\SysWOW64\cmd.exe" /c <batch_name> would run in 32-bit
Otherwise, you could change the associations to run the extension .cmd with 64-bit (ftype cmdfile=C:\Windows\System32\cmd.exe /c "%1" %*) and .bat with 32-bit (ftype cmdfile=C:\Windows\SysWOW64\cmd.exe /c "%1" %*).

Silent Dropbox removal

I use the following script in Npackd to uninstall Dropbox. It works on XP and Vista, but fails on Windows 7/64. Instead of showing the taskbar (the one that is normally at the bottom of the screen) it shows a Windows Explorer window with the content of C:/. This is not Dropbox related as removing other packages with DLL based shell extensions also shows the same effect.
Uninstall.exe /S _?=%CD%
taskkill /f /fi "IMAGENAME eq explorer.exe"
del DropboxExt.13.dll
del DropboxExt64.13.dll
rem start explorer from the root directory so it does not lock this one
start "" /D\ explorer.exe
What is wrong with the script? How can it be modified to work correctly on Windows 7 too?
Thanks
EDIT: I am really tired of this problem. The following batch file works either started as a normal user or "As Administrator":
taskkill /f /fi "IMAGENAME eq explorer.exe"
ping -n 5 127.0.0.1
pushd \
rem runas /trustlevel:0x20000
start "" /D\ explorer.exe
popd
Here is the code that starts the .bat from my program (path="Uninstall.bat", only 2 new environment variables are defined):
QDir d = this->getDirectory();
QProcess p(0);
p.setProcessChannelMode(QProcess::MergedChannels);
QStringList params;
p.setWorkingDirectory(d.absolutePath());
QString exe = d.absolutePath() + "\\" + path;
for (int i = 0; i < env.count(); i += 2) {
p.processEnvironment().insert(env.at(i), env.at(i + 1));
}
p.start(exe, params);
The corresponding code in Qt/qprocess_win.cpp:
DWORD dwCreationFlags = CREATE_NO_WINDOW;
dwCreationFlags |= CREATE_UNICODE_ENVIRONMENT;
STARTUPINFOW startupInfo = { sizeof( STARTUPINFO ), 0, 0, 0,
(ulong)CW_USEDEFAULT, (ulong)CW_USEDEFAULT,
(ulong)CW_USEDEFAULT, (ulong)CW_USEDEFAULT,
0, 0, 0,
STARTF_USESTDHANDLES,
0, 0, 0,
stdinChannel.pipe[0], stdoutChannel.pipe[1], stderrChannel.pipe[1]
};
success = CreateProcess(0, (wchar_t*)args.utf16(),
0, 0, TRUE, dwCreationFlags,
environment.isEmpty() ? 0 : envlist.data(),
workingDirectory.isEmpty() ? 0 : (wchar_t*)QDir::toNativeSeparators(workingDirectory).utf16(),
&startupInfo, pid);
Why does the Explorer think there is already a taskbar?
EDIT2: I know what is wrong now. After the Explorer is killed a new is automatically started by an svchost.exe process with the following parameters: /factory,{682159d9-c321-47ca-b3f1-30e36b2ec8b9}. The GUID is for DesktopExplorerFactory. This is probably a crash-protection for a COM service. My calls to explorer.exe do not start a new Explorer as there is already one. After a minute or two this process will be automatically closed if no windows are opened. So I think Ben Voigt is right and "There's really no good way to unload the shell completely without logging off all users."
What is wrong with the script is quite simple: The shell is loaded into many many applications besides just Windows Explorer. Every application that uses the common open/save file dialogs hosts the shell.
To address your immediate question of how to control the working directory of Windows Explorer without passing arguments that open a window, just set the working directory:
pushd C:\
start explorer.exe
popd
But this still will not let you reliably delete the extension. There's really no good way to unload the shell completely without logging off all users.
EDIT: Is your script running at the same integrity level as the original explorer.exe you killed? Same elevation level? The shell runs with medium (normal) integrity level and unelevated token, you need to match this.
For what it's worth, your command "start "" /d\ explorer.exe" seems to work fine for me even on win7, it restarts the taskbar & desktop if it's been killed.
However, you don't really need "start". You can just call "explorer.exe" from a batch file, it won't block. Not sure if this makes a difference but it's worth a try.
By the way, if it doesn't work... what happens on the affected computer if you bring up the task manager with ctrl+shift+esc and do a File->Run "explorer"? Does that start the taskbar or will it, again, produce an explorer window? If this produces the expected results there may be something wrong with the batch file or its environment. Such as not being run as the currently logged on user, etc.
Explorer should start the taskbar if there are no other instances of its own process around. The fact that the shell itself may be loaded into other processes does not matter... you can kill all instances of explorer, have a "file open" dialog up in Excel, and still restart the taskbar by running explorer.exe from the task manager.
Try to replace the following line
start "" /D\ explorer.exe
with this one
start "" /D\ %SystemRoot%\explorer.exe
This should run explorer without parameters.
The thing is that running explorer without full path runs it with parameters you specified:
/factory,{682159d9-c321-47ca-b3f1-30e36b2ec8b9}
but I have no clue why this happens.

Resources