I run a program in batch file and I use /bg command to run it in background. My question is, how can I see the process in task manager? I am asking this because /bg hide also the process.
In task manager you may only be seeing processes running under your user, click the "Show processes from all users" to see all processes.
Related
I'm trying to run a .vbs file as a scheduled task through Windows Task Scheduler. Under the 'General' tab, when I select "Run only when user is logged on", the script executes as expected.
However, when I select "Run whether user is logged on or not", and enter the appropriate credentials, the task runs at the scheduled time, but the script does not actually run. I've already tried running the script under wscript.exe as well as cscript.exe, but no luck with either.
EDIT: Even if I am logged in when the task begins, the script will still not run under the "logged in or out" setting.
Additional info: The purpose of this scheduled task is to run before I arrive at work. I've already configured my BIOS to startup at a predetermined time (06:00), and set the Task Scheduler to run at 06:27. I've successfully tested the BIOS startup, as well as the script itself (including using the Task Scheduler to run it). Therefore, the only weak link I can find is the option to "Run whether the user is logged on or not".
I'm running Windows 7 Enterprise.
Any help would be appreciated!
This is because normally it would run the script using the shell handler, which by default is wscript.exe. When there's no desktop environment (because no-one is logged-in) it would fail and abort script execution (or rather, not run the script in the first place).
To fix this, instead of running the .vbs file directly, change it to run cscript.exe (the command-line script runtime program) with the script's filename passed as the first argument. Also be sure to ensure you don't have any InputBox or MessageBox calls (instead use WScript.Echo to return messages to the user: wscript displays message-boxes, but cscript will write it to the console.
I am trying to create a scheduled task to run a batch file. I know that my batch file runs fine, because I have no problem running it manually. However, when the task calls it, it says that it's running, but it's not. The reason I know that it's not running is because it calls a python script, and the python script sends an email saying that the process has started. And I'm not receiving that email.The python process doesn't take too long (maybe 5 minutes at most), and the task keeps saying that it's "Running" after an hour.
I have the current settings with "Run whether user is logged on or not" (doesn't seem to work at all if I have it as "Run only when user us logged on", because the status never changes from "Ready" even if I tell it to run). I also have the setting with "Run with highest privileges", and just the name of the batch file under "Program/script" and the path to the batch file under "Start in". I also want to note, that I have the user account as "DOMAIN\Administrator".
However, I've tried other ways of calling it. I've tried putting the entire path with the batch file under "Program/script" (G:\GOM3_Update\FeatureServices\copies\test.bat), or putting the path to the python program, and then putting the path to the python script as an argument, but that doesn't seem to work either.
I'm not sure if this issue is caused by some major security settings with windows 10, or something minor in the task scheduler settings.
Here are my current settings:
Full path of the Start in is: "G:\GOM3_Update\FeatureServices\copies\"
The batch file:
"C:\Users\Administrator.DOMAIN\AppData\Local\ESRI\conda\envs\arcgispro-py3-clone\python.exe" "G:\GOM3_Update\FeatureServices\copies\database.py"
I would include a full path to batch file here:
From my personal experience it is usually the environment problem, aka things like current working directory etc..
Also, make sure to click the refresh button in the right pane of Task Scheduler because it is known for not updating the status of task unless you manually refresh. You may see it change from 'running' to 'ready' sooner if you do that.
The reason why I feel like your screen is not refreshing is because normally Task Scheduler does not allow any scheduled task to execute for longer that 1 hour and you said yours was still saying 'running' after an hour.
What does the exit code and messages say under tasks history?
Exit code 0 means no errors captured by Task Scheduler.
Another idea is to log the start of batch script (inside batch) to a log file before you do anything. And do the same for python file. This will help you narrow down the problem.
I struggled with this one also a lot, changing the User Account
AND Group. User Account alone was not enough for me.
This helped for me:
And then clicking on the Locations...you'll have to choose "WINSTADM"
For those who don't know what SCCM is, a little information, to understand better what i want to know. SCCM is an application, with you can deploy software packages. It is also possible to create a so called "Task Sequence". A Task sequence can contain multiple packages, which will be installed one after the other.
The Task Sequence execution occurs in Session 0. Of course the packages query some processes, if they are running. If they are, a window will pop up, to ask the user to close the application.
Here comes the problem. If an administrator deploys packages using task sequences (and they do), the users won't see the window, and won't close the required process. If the process is not closed, the script execution aborts.
I found this Link, and created a simple exe, according to the description. This simple exe is able to start a process from session 0 in session 1(or above), where the user is logged on(i know the security risks). So far so good, but how do i get the packages to display their windows? Obviously i could change the command line, so my exe will start the installation of every package, but this is not an option. There would be to much work.
The ideal solution would be if my exe would be the first in the task sequence, it would do "something" so the windows could be visible.
And that's where i am stuck.
Does anyone has any idea how i could achieve what i want?
Thanks in advance!
I've created two Batch scripts that I launch via the windows 7's Task Scheduler, and I've noticed that from times to times the execution of one of these scripts freezes. When this happens I get a Taskeng.exe window, and the only way to get rid of it is to kill the equivalent process.
And since I'm running those scripts on differents machines, whenever I log on in the morning, I find multiple Taskeng.exe windows from the previous executions.
Is there anyway to solve this problem ? Is there a way to kill those processes whenever their execution is incomplete ?
Thanks for reading.
Hicham
There are many references on Internet claiming that one of differences between a GUI and a console application is that running the GUI application from a batch file does not block its execution, while running the console application does block it.
Few of many references, these are particularly from SO/SE:
How can I get an MFC application to block from the command line?
How to wait for a process to terminate to execute another process in batch file
How do you wait for an exe to complete in batch file?
Run a program in a batch script and wait for it to finish before continuing
Moreover, I myself remember this is/was true.
Yet it does not seem to work this way.
I've tested this on a simple batch file like:
echo Pre
notepad
echo Post
The Post is not printed until I close notepad. Why, when a notepad is clearly a GUI application?
I've tested this on Windows 8, 7, and XP just to rule out a possibility that the behavior has changed in recent versions of Windows. I've tried to disable command extensions as one of possible culprits too.
It has to do with how the application that you launch runs and terminates. Some programs launch another process and then terminate, others continue to run. Calc.exe and Notepad.exe simply run until you close them. Write.exe and any program that launches as a result of a file association (e.g., bitmap, wave file, control panel applet, etc.), actually launch another program and then the process that launched them terminates returning control back to the batch file so it can execute the next line.
Here are some examples:
#echo off
echo Starting Calc.exe
calc.exe
echo Calc was closed by the user
echo Starting Notepad.exe
Notepad.exe
echo Notepad was closed by the user
echo Starting WordPad.exe
write.exe
echo Write launched WordPad and then terminated allowing the batchfile to continue
echo Starting Services.msc
services.msc
echo Windows launched MMC, opened services.msc, then returned control to the batchfile
echo Launching WMP via Chord.wav
c:\windows\media\chord.wav
echo Windows launched WMP, opened Chord.wav, then returned control to the batchfile
The CMD process knows Calc and Notepad are still running because it spawned them itself. The CMD process does not know that the others are still running because the intermediate process terminated.
To observe this, open Process Explorer and view the processes displayed in the hierarchical tree. Calc.exe and Notepad.exe both remain as child processes of the CMD process that ran the batchfile. Write.exe and MMC.exe (services.msc) both become top-level processes, no longer children to the CMD process. WMPlayer.exe remains a child process to svchost.exe, which is how Windows launched it. The CMD process doesn't know they are still running because it didn't launch them, some other Windows process did. So execution continues...
One more example of this is how MSPaint.exe functions. If you run it by using the Windows built-in file association for BMPs, then Windows launches MSPaint.exe and control is immediately returned to the batchfile. However, if you pass the BMP to MSPaint.exe, then the batchfile waits for you to close MSPaint before continuing. (I'm on a dev machine with no BMPs, so create a simple one called C:\MyBitmap.bmp.)
#echo off
C:\MyBitmap.bmp
calc.exe
mspaint.exe C:\MyBitmap.bmp
notepad.exe
Calc.exe will open immediately, Notepad.exe will not open until you close the second instance of MSPaint.exe.
I know you didn't ask about launching Windows processes via their file association, but it just demonstrates how the owning process can change. If the CMD process owns the launched process, it should wait until it terminates to continue execution. If the spawned process hands control off to another process, then the CMD process doesn't know about the grandchild process and it continues on with its execution.
Because it waits for return code.You can use start command to create a separate subprocess:
#echo pre
#start "notepad" notepad
#echo post
I've used Windows since NT 3.1, and I too would have said "cmd.exe does not wait for GUI programs to terminate" when you simply type the name of the program (as opposed to using the START command). Though memory grows dim, I believe it originally worked this way. But today, my statement is true interactively, false for "batch" files. Having been thus reminded, I vaguely think it was intentionally changed as some point, since the naïve batch-writer expects sequential execution, but I can't be sure and I don't know when.
I think the answer lies in this question Difference between Windows and Console application.
I quote from two answers.
Konrad Rudolph answered:
The sole difference is that a console application always spawns a console if it isn't started from one (or the console is actively suppressed on startup). A windows application, on the other hand, does not spawn a console. It can still attach to an existant console or create a new one using AllocConsole.
This makes Windows applications better suited for GUI applications or background applications because you usually don't want to have a terminal window created for those.
oefe answered:
Console and Windows applications behave differently when called interactively from the command prompt:
When you start a console application, the command prompt doesn't return until the console application exits. When you start a windows application, the command returns immediately.
This is not true for batch files; they will always wait until the application exits.
The difference in this bahviour between cmd and batch made you think that it worked before.