I have the following cmd command:
C:\Users\spidey\AppData\Local\Programs\Python\Python39\python C:\Users\spidey\Documents\sleepScript\textdocument.py
Inside a .bat file. When I double click and run it, it runs well but when I try to right click and run as administrator it just opens the window and closes adruptly without completing the execution.
The end result of the command is a text file which is created in first case but not when I try to run it as administrator.
The reason for this to run as adminstrator is because I will be running it on cloud and so there it runs as administrator.
Here are the content of textdocument.py:
import datetime
file = open('read.txt', 'w')
file.write('Executed # ' + str(datetime.datetime.now()))
file.close()
Here is another update:
Tried to create a shortcut and setup it's advanced property as run as administrator. But that doesn't work as well.
After doing this, I tried to run the .bat file again as administrator but no effect.
As suggested in the comments, I shifted all the files to C: drive so that it's accesible to everyone. But unfortunately that didn't work as well window just opens and aprubtly closes without giving the end result. On the other hand normal running works here as well.
Here is the command:
C:\Python\Python39\python C:\uiPath\textdocument.py
After a long debugging, I realized that the command was actually running correctly. It's all that it was saving the file into the other default directory after adding in my python script:
os.chdir(path)
Where path is the path where I wanted it to store. Whereas in case of double clicking and running it, by default that path was set to the path where the file was located in.
The problem got fixed. Thank you everyone for the help!
The application moves files from one directory to another, runs an exe, and then moves files from one directory to another.
When I run the application manually it works as expected.
However, when trying to run it as a scheduled task I get the following error: 3762504530
I did some researching and it appears it may have to do with the application trying to run interactively even when there is no user actually logged in.
I have tried to suppress outputs but that didn't seem to have any effect.
Without seeing the code i guess u use console output or similar...
If so change write-host to write-output or alias "echo" pipe it to log file if u want...
Also be sure that your script run "non interactive" (no prompts etc.)
Unchecking compile a graphic windows program (parameter -noConsole), remedied the error.
I have a very simple .bat file. It only has one line:
powercfg -h off
What this does is turn off the computer's ability to hibernate. It works fine when I double click the file. I can confirm this by going into the command prompt and typing "powercfg /a", which shows me that hibernate is indeed off. The problem is that this batch file doesn't seem to be running at logon even though it's in my Startup folder.
I've tested it by turning hibernate on using the command prompt ("powercfg -h on") and then actually putting my computer into hibernation. Then I turn it back on and log in to Windows. But when I open a command prompt and type "powercfg /a" it shows me that hibernate is still on. It seems the batch file doesn't run at logon even though it is in my Startup folder.
I've also tried making it run from a task scheduled to run at logon, but that didn't work either.
Some ideas:
Make sure you set the Start in and Program/script options of the batch file correctly.
If (1) doesn't work then try moving the .bat file to a directory with basic permissions.
Try to schedule the execution of the batch file like this cmd /c "c:\path\batch.bat"
Also take a look at this: Batch runs manually but not in scheduled task.
I got it to work using Task Scheduler. The problem was that I was using the trigger "At log on," when I should have chosen "On workstation unlock."
It's obvious to me now, but I didn't think of it at the time: hybernating didn't actually log me off, it only locked me out.
I have a batch file daily.bat, this is the code:
cd C:\inetpub\wwwroot\infoweb\factuur\cron
c:\PHP\php.exe -f ./cron_pdf.php
ftp -s:ftp_upload.txt ftp.site.be
And I created a task with task scheduler in Windows 7. When I run the batch manually, everything goes fine, but when I try to run it with the task scheduler nothing happens.
My action is
'run script' "C:\inetpub\wwwroot\site\x\cron\daily.bat"
UAC is off and I am Admin.
Any idea why this is not working?
I faced the same problem, but I found another solution without having to modify my batch script.
The only thing that I missed out is at the 'Action' settings - "Start in (Optional)" option.
Go the task properties --> Action tab --> Edit --> Fill up as below:
Action: Start a program
Program/script: path to your batch script e.g. C:\Users\beruk\bodo.bat
Add arguments (optional): <if necessary - depending on your script>
Start in (optional): Put the full path to your batch script location e.g. C:\Users\beruk\(Do not put quotes around Start In)
Then Click OK
It works for me. Good Luck!
None of the above method worked. I tried it this way as said it in a tutorial and it worked.
Action:
Start a program
Program/script:
cmd
Add arguments:
/c start "" "E:\Django-1.4.1\setup.bat"
Worked for me on Win7 Pro. You must have an account with a password (blank passwords are no good)
For those whose bat files are still not working in Windows 8 and 10+ Task Scheduler , one thing I would like to add to Ghazi's answer - after much suffering:
Under Actions, Choose "Create BASIC task", not "Create Task"
That did it for me, plus the other issues not to forget:
Use quotes, if you need to, in your Start a program > program/script entry i.e "C:\my scripts\runme.bat" (or just use the Browse button)...
Use the Start In path to your batch file, even though it says optional - BUT DON'T use quotes in the Start In field. (Crazy but true!)
This worked without any need to trigger a command prompt. And it is the quickest and simplest method.
(Sorry my rep is too low to add my Basic Task tip to Ghazi's comments)
Make sure "Start In " has NO QUOTES.
It is working now. This is what I did. You probably won't need all these steps to make it work but just to be sure try them all:
Check the account parameters of your scheduled task and make sure they are set to run whether or not someone is logged into the machine
check run with most privileges/rights
Make sure you go to the full path first: cd C:\inetpub\wwwroot\infoweb\factuur\cron
Don't use double quotes in your batch files (don't know why but seems to help)
Be super admin, enter 'Net user administrator /active:yes' in command prompt, log out and log in as the super admin, so UAC is off
Make sure "Start In" does NOT end with a BACKSLASH.
My script was to pull latest code from master and publish a new branch
cd D:\dev\repo
git checkout master
git pull
git branch -D my-branch
git push origin --delete my-branch
git checkout -b my-branch
git push -u origin my-branch
exit
Had an issue where my task was not firing simply because it was running on a laptop without a power cord... Under the conditions tab, by default it is checked so that a task will not run while AC power is not connected.
Under Windows7 Pro, I found that Arun's solution worked for me: I could get this to work even with "no user logged on", I did choose use highest priveledges.
From past experience, you must have an account with a password (blank passwords are no good), and if the program doesn't prompt you for the password when you finish the wizard, go back in and edit something till it does!
This is the method in case its not clear which worked
Action: start a program
Program/script : cmd
(doesn't need the .exe bit!)
Add arguments:
/c start "" "E:\Django-1.4.1\setup.bat"
I messed with this for several hours and tried many different suggestions.
I finally got it to work by doing the following:
Action: Start a program
Program/Script: C:\scriptdir\script.bat
Add arguments (optional) script.bat
Start in (optional): c:\scriptdir
run only when user logged in
run with highest privileges
configure for: Windows Vista, Windows Server 2008
If all of the rest fails for you here ensure that the user you are trying to run the task as has access to the file you're trying to use.
In my case I was trying to run a batch file from C:\Users\Administrator\Desktop which the account couldn't access. Moving it to a neutral location on C:\ resolved the issue.
I post the answer to this question here and here.
Using the Run button in the Task Scheduler main window to test several variations finally found the correct settings. This two options must be combined:
-Run only when user is logged on
-Run with highest privileges.
All other variations failed. It's infuriating all the time wasted on this, but at least it works.
OS: WINDOWS 8 CORE (BASIC) VERSION
Please check which user account you use to execute our task. It may happen that you run your task with different user then your default user, and this user requires some extra privileges.
Also it may happen that the task is executed but you cant see any effect because the batch file waits for some user response so please check task manager if you see your process running.
Once it happen that I schedule a batch with svn update of some web page and the process hangs because svn asked for accepting server certificate.
Don't use double quotes in your cmd/batch file
Make sure you go to the full path start in (optional):
C:\Necessary_file\Reqular_task\QDE\cmd_practice\
Try run the task with high privileges.
put a \ at the end of path in "start in folder" such as c:\temp\
I do not know why , but this works for me sometimes.
Action: Start a Program
Program/script: C:\Windows\System32\cmd.exe
Add arguments: /k start "" "E:\scripts\example.bat"
Add exit to the end of your batch file.
The cmd window will not show if you select Run whether user is logged in or not. You need to select Run only when user is logged on to see the window in action.
I'm having a weird problem with running cl.exe that has me stumped. In a large VS2008 solution consisting of C/C++ projects, I have one project that runs some scripts to do some extra processing. The project consists of a pre-build event, which calls a Perl script (ActiveState Perl is on the machine). This Perl script then calls cl.exe with /E to generate preprocessed output which gets redirected to a file. The line in Perl looks like this:
my $foo = `"\path\to\cl.exe" #args.rsp >out.txt 2>err.txt`;
args.rsp is a plain text file that contains a bunch of command line args for cl.exe, including /E to get pre-processor output on stdout.
This exact command line works as expected when run from the VS2008 command prompt. Building the project also works fine on my Windows XP machine. However, on my new Windows 7 box, when I build the project, out.txt ends up blank. I should also add that on some of my coworker's Windows 7 boxes, it works fine, and on some others it doesn't.
Clearly there's some kind of configuration difference going on, but I'm at a loss as to what it may be. We've checked matching versions of VS2008 SP1 and ActiveState Perl. I've tried myriad workarounds within the perl script - using system() instead of backticks, using cl.exe /P to output to a file and then moving the file (the file is blank), unsetting the VS_UNICODE_OUTPUT environment variable (no effect). Nothing has changed the behavior - output is generated when the command line is run manually, but not when it's run inside the pre-build event for this project.
Any ideas on what kind of configuration problem may be causing this? I'm pretty much out of avenues to pursue.
Sounds like an ACL issue to me. You can change windows to log access issues and then check the event log to see what user is getting access denied errors.
I believe the setting is in Local Policy | Audit Policy | Audit Object Access
Wow, the solution to this ended up being a lot stranger than I expected. The machine I'm working on (and the other co-workers who are also experiencing the problem) is a Mac Pro with bootcamp and Windows 7 installed. That causes C: to have the windows drive and E: to have the mac drive. This causes a problem because the pre-build event has a couple lines that test each drive letter to see if there's a drive there, and if there is, adds X:\Perl\bin to the path. Even though E:\Perl\bin doesn't exist, it gets added to the path. Later, the perl script runs and then calls cl.exe, and for some reason, having a directory in the mac drive causes cl.exe to fail. Why? I have no idea. Anyway, removing the mac drive directory from the path fixes the problem!
Thanks for your eyes everyone.
Check out the exit code of your program. You may want to build your executable name in a portable way using something like File::Spec. Also, check that #args is not interpolating. You may want to print your command line before executing to check if that's what you want. What is left your err.txt file?