I have a long running process that spans robocopy windows to parallelize copying process. It goes well under cmd.exe, but when I try it under conemu, child windows has the following message:
ConEmuC: Root process was alive less than 10 sec, ExitCode=1.
Press Enter or Esc to close console...
And parent window:
[2015-07-08 09:57:20] Error: Could not copy xxxxx. Robocopy ExitCode: 121.
How can I debug and fix that?
Perhaps your batch uses start to start new console with robocopy. You may disable start processing in the ConEmu's Settings. Or may be you are using old ConEmu version. Actually there may be other issues but without exact information nobody can tell you more.
Related
When I run powershell ISE, I can execute commands/scripts without issue. When I launch either the 32 or 64 bit command line, the window takes about 30 seconds to load and then it is frozen. It will not accept inputs of any kind (keyboard or copy/paste). I have tried doing a system check, no errors. I even tried updating to powershell 4.0, the install was successful but the command line still locks on launch. Can anyone advise how to fix this? I am using windows server 2008 R2.
Update
It appears that the powershell is in fact accepting input, except at a glacial speed. I left the window open while I was writing this post initially, and then grabbed a coffee. Upon my return I found that what I have tried to copy/paste and type was now in the powershell command line. I have now attempted to execute $PSVersionTable.PSVersion, and going on 3 minutes now I still have no response. My guess is it will come back at some point but this is obviously not acceptable. Any ideas on how to debug/fix this?
Update2
As far as I can tell all the locations listed in $PROFILE | Select * don't exist. I also tried launching: powershell.exe -noprofile, but this did not help
After reading this post I decided to try that tool and see if I had a similar problem and discovered that there were literally hundreds of writes per second happening when powershell command line was running and they were all to the FusionLog. Disabling the Fusion logging fixed the issue completely (this was enabled a while ago to debug a different issue with an app and I must have forgotten to disable it). Everything else on the machine seemed to hum along just fine with FusionLogging in the background but powershell was horribly crippled. Hope this helps someone some day.
I have a scheduled task on a Windows 2008 R2 server. The task includes a Start In directory entry. The task runs, and the batch file it runs does what it is supposed to do. When I run the batch file from a command prompt, I see no errors. The problem is that the "Last run result" is 0x1 (incorrect function call).
I did get this at one time with an incorrect DOS statement IF EXISTS file.txt DO (Copy file.txt file1.txt) that was corrected by dropping the DO statement. The current batch file does not show me any errors or warnings.
Why am I getting a 0x1 result?
Batch file that is run:
PUSHD \\JUKEBOX4\Archives\CallRecording
REM only move csv and wma together. wma should be created last.
IF NOT EXIST C:\CallRecording (MKDIR C:\CallRecording)
FOR /f %%f IN ('DIR /b *.wma') DO (
IF EXIST %%~nf.csv (MOVE /Y %%~nf.* C:\CallRecording\)
)
POPD
CD /D "C:\Program Files (x86)\Olim, LLC\Collybus DR Upload"
CollybusUpload.exe
POPD
Info on scheduled task setup:
Program to run: C:\Program Files (x86)\Olim, LLC\Collybus DR Upload\CallRecordingUploadFromH.cmd
Start in: C:\Program Files (x86)\Olim, LLC\Collybus DR Upload
Run whether user is logged on or not, highest privileges.
History screen, task completed entry
"Task Scheduler successfully completed task "\Call recording upload to portal from NH" , instance "{1449ad42-2210-427a-bd69-2c15e35340e6}" , action "C:\Windows\SYSTEM32\cmd.exe" with return code 1."
First screen of Task Scheduler shows "Run Result" of "Success"
It seems many users are having issues with this. Here are some fixes:
Right click on your task > "Properties" > "Actions" > "Edit" |
Put ONLY the file name under 'Program/Script', no quotes and ONLY the directory under 'Start in' as described, again no quotes.
Right click on your task > "Properties" > "General"
| Test with any/all of the following:
"Run with highest privileges" (test both options)
"Run wheter user is logged on or not" (test both options)
Check that "Configure for" is set to your machine's OS version
Make sure the user account running the program has the right permissions
I found that I have ticked "Run whether user is logged on or not" and it returns a silent failure.
When I changed tick "Run only when user is logged on" instead it works for me.
I've had the same problem. It is just a batch-file, working when manually started, but not working as a scheduled task.
there were drive-letters in the batch-file like this:
put z:\folder\file.ext
seems like you should not use drive-letters, they are bound to the user, who created them - for me this little change made it work again:
put \\server\folder\file.ext
For Powershell scripts
I have seen this problem multiple times while scheduling Powershell scripts with parameters on multiple Windows servers.
The solution has always been to use the -File parameter:
Under "Actions" --> "Program / Script" Type: "Powershell"
Under "Add arguments", instead of just typeing "C:/script/test.ps1" use -File "C:/script/test.ps1"
Happy scheduling!
Windows Task scheduler (Windows server 2008r2)
Same error for me (last run result: 0x1)
Tabs
Action: remove quotes/double-quotes in
program/script
and
start in
even if there is spaces in the path name...
General:
Run with highest privileges
and
configure for your OS...
Now it work!
last run result: The operation completed successfully
Probably not the cause of the OP's problem; for me the problem was caused by the fact that my program called a SQL function, and the service account the windows task was set up with did not have the required SQL permissions. That also gives a 0x1
This answer was originally edited into the question by the asker.
The problem was that the batch file WAS throwing a silent error. The final POPD was doing no work and was incorrectly called with no opening PUSHD.
Broken code:
CD /D "C:\Program Files (x86)\Olim, LLC\Collybus DR Upload" CALL CollybusUpload.exe POPD
Correct code:
PUSHD "C:\Program Files (x86)\Olim, LLC\Collybus DR Upload" CALL CollybusUpload.exe POPD
In my case it was an encoding issue. We wanted to start en existing batch file, and it resulted in "return code 1", and the desired action wasn't performed. I've accidentally found that the batch file was shown in Notepad as one with UTF-8 encoding (actually without any reason, as we have no special characters in the text). I saved it as ANSI, and it solved the problem for us. Might be, that it was a kind of encoding corruption in the file that prohibited Task Scheduler and cmd.exe to open the file, although it was displayed correctly in Notepad.
On our servers it was a problem with the system path. After upgrading PHP runtime (using installation directory whose name includes version number) and updating the path in system variable PATH we were getting status 0x1. System restart corrected the issue. Restarting Task Manager service might have done it, too.
I was running a PowerShell script into the task scheduller but i forgot to enable the execution-policy to unrestricted, in an elevated PowerShell console:
Set-ExecutionPolicy Unrestricted
After that, the error disappeared (0x1).
Just had the same problem here. In my case, the bat files had space " "
After getting rid of spaces from filename and change into underscore, bat file worked
sample before it wont start
"x:\Update & pull.bat"
after rename
"x:\Update_and_pull.bat"
For me the problem was the PowerShell script being ran had #Requires -RunAsAdministrator at the top, meaning it needs to run in an elevated command prompt as an Admin, but the user the Scheduled Task was set to run as wasn't an admin on the local computer. So even though Run with highest privileges was checked in the scheduled task, I still had to make the user an Administrator on the computer. Once I did that, the script ran as expected.
Since there is always more than one reason this could happen I thought I'd share some troubleshooting tips that helped me diagnose my issue.
Always adding a "start in" parameter first since thats an easy fix, even just adding the drive letter can help, e.g. C:\
If you're running "whether user is logged on or not" and it is failing it might be an issue with your user and/or user environment.
Switch the task to run only when user is logged in temporarily for
troubleshooting purposes.
Make sure you're actually logged in AS the user you're telling the task
to run as. (PATH and other environment variables are different by user
and if you see the task running on one user successfully that doesn't
necessarily mean it will run successfully for another user even if they're in the same security group.)
Add pauses or some other type of debugging to your script to give you
time to see any errors that may pop up.
Perform a manual run from the task scheduler window.
Fix any errors you see from your debugging statements. Rinse and repeat.
If it runs successfully switch back to run "whether user is logged on
or not" and try another manual run. If it works now you're all set.
If nothing has helped so far you might need to dig in deeper to your user and file privileges. My troubleshooting tips assume that you have been able to get a past task running using a specific user login already. They don't cover building a scheduled task from a fresh install necessarily. Luckily I haven't had to do that.
What solved it for me was that I was using a local administrator account instead of the domain account so I changed the "Run as" to the domain account.
It turns out that a FTP download call using winscp as last thing to do in the batch caused the problem. After inserting the echo command it works fine. Guess the problems source could be the winscp.exe which do not correctly report the end of the current task to the OS.
del "C:\_ftpcrawler\Account Export.csv" /S /Q
"C:\Program Files (x86)\WinSCP\WinSCP.exe" /console /script="C:\_isource\scripte\data.txt"
echo Download ausgeführt am %date%%time% >> C:\_isource\scripte\data.log
I got some strange behaviour when executing a powershell script.
When I run my script using the ISE it works just fine.
When I open Powershell.exe and run my script it works just fine.
When I open cmd, and start my script using powershell.exe -noexit
./myscript.ps1, myscript works just fine.
When I double-click myscript however, powershell opens for some milliseconds, I see that it shows some error (red font) and the powershell window closes. I'm unable to track down the error causing this problem since the powershell windows closes to fast.
I even tried one single big try-catch block around my hole script, catching any [Exception] and writing it down to a log file. However: the log file is not generated (catch is not called).
How can I track that issue? What could possibly be causing the trouble?
Please note that my execution-policy is set to unrestricted.
Before trying the suggestion invoke this to see your current settings (if you want restore them later):
cmd /c FType Microsoft.PowerShellScript.1
Then invoke this (note that you will change how your scripts are invoked "from explorer" by this):
cmd /c #"
FType Microsoft.PowerShellScript.1=$PSHOME\powershell.exe -NoExit . "'%1'" %*
"#
Then double-click the script, it should not exit, -NoExit does the trick. See your error messages and solve the problems.
But now all your scripts invoked "from explorer" keep their console opened. You may then
remove -NoExit from the above command and run it again or restore your
original settings.
Some details and one good way to invoke scripts in PS v2 is here.
Unfortunately it is broken in PS v3 - submitted issue.
by default, for security reason when you double clic on a .ps1 file the action is : Edit file, not Run file .
to execute your script : right-click on it and choose run with powershell
I also wasn’t able to run a script by double clicking it although running it manually worked without a problem. I have found out that the problem was in the path. When I ran a script from a path that contained spaces, such as:
C:\Users\john doe\Documents\Sample.ps1
The scipt failed to run. Moving the script to:
C:\Scripts\Sample.ps1
Which has no spaces, solved the problem.
This is most likely an issue with your local Execution Policy.
By default, Powershell is configured to NOT run scripts that are unsigned (even local ones). If you've not signed your scripts, then changing your default double-click 'action' in Windows will have no effect - Powershell will open, read the execution policy, check the script's signature, and finding none, will abort with an error.
In Powershell:
Help about_execution_policies
gives you all the gory details, as well as ways to allow unsigned scripts to run (within reason - you'd probably not want to run remote ones, only ones you've saved onto the system).
EDIT: I see at the tail end of your question that you've set Execution Policy to 'unrestricted' which SHOULD allow the script to run. However, this might be useful info for others running into execution policy issues.
If you would catch the error you will most likely see this
The file cannot be loaded. The file is not
digitally signed. The script will not execute on the system. Please
see "Get-Help about_signing" for more details.
Because you are able to run it from the shell you started yourself, and not with the right mouse button click "Run With PowerShell", I bet you have x64 system. Manually you are starting the one version of PowerShell where execution policy is configured, while with the right click the other version of the PowerShell is started.
Try to start both version x64 and x86 version and check for security policies in each
Get-ExecutionPolicy
I was in exactly the same situation as described in the question : my script worked everywhere except when double-clicking.* When I double-clicked a powershell windows would open but then it will close after a second or so. My execution-policy is also set to unrestricted.
I tried the selected answer concerning FType Microsoft.PowerShellScript.1 but it didn't change anything.
The only solution I found was a work around: create a bat file which start the powershell.
Create a file, copy this and modify the path : powershell.exe -File "C:\Users\user\script\myscript.ps1"
Save it as a .bat
Double-click the bat
I also used .ahk to start my powershell with a shorcut and it didn't work when pointing directly to the powershell. I had to point to the .bat
I have a startup task for my webrole that download some executable file from a blob and then proceed to the installation.
From a .cmd file, I start a power shell script that download the files, then I start the file from the .cmd.
The script works fine if I run it manually through RDP after the publishing is done.
But, when running as startup script, it sometimes (often) fail at different points.
The taskType is set to background.
Last time, the error was that the command PowerShell does not exists...
Also, I use powershell -command set-executionpolicy unrestricted before running my PS script, but I read here that other task may reset this setting and make mine fail.
Quite a mess.
So that makes me think that if I could wait for all other task to perform before starting mine, it would eliminate these kinds of problems
I suppose I could check if some process is running and wait for it to finish, but I have no clue wich process to check.
Or maybe there's another solution.
~edit~
I read here that the error about powershell not existing may be caused by the batch file being saved as UTF-8 in visual studio. I re-writed it from scratch in notepad++ and made sure it is save as ANSI. Then, same error. The full message is :
'PowerShell' is not recognized as an internal or external command,
operable program or batch file.
Again, the script run perfectly from command line in remote desktop.
It would be possible to set an environment variable at the end of the script that is required to finish, then in the script which is awaiting the dependencies, loop until the environment variable is set, then kick off its activities.
You could also run everything from a single powershell script and use the '-asjob' switch on your installer statement, use the 'wait-job' cmdlet to block until the task is complete then carry on. Powershell also offers a '?!' operator which ensures the last statement executed properly.
This might be caused by an encoding issue. As mentioned in this answer you should save your file in ASCII to ensure correct interpretation of your script.
From the linked answer:
Open your whatever.cmd file with your VS 2012 Ultimate. Click on File->Save whatever.cmd as -> on the dialog there is little arrow next to the [save] button. It will show up a menu that will have the option Save with Encoding.
Select it. Now choose "US-ASCII Codepage 20127" from the list of available encodings.
During an install of PostgreSQL 9.1.2 on my Windows 7 64-bit Home Premium box, the installation hung. After a long furious search I discovered the problem was that an installer VB Script was hung waiting for a batch file to complete in a hidden window.
I isolated the problem to the following line of code:
Dim objShell
Set objShell = WScript.CreateObject("WScript.Shell")
objShell.Run "hello.bat", 1, True
(where 1 sets WindowStyle to Visible and True waits for completion). The Run call had launched the command prompt but was not executing the batch file. Thus, it would never complete.
I solved the problem by launching cmd.exe instead of the batch file directly, according to numerous online sources:
objShell.Run "%COMSPEC% /c hello.bat", 1, True
Since the fix is buried in the PostgreSQL installer (and I've submitted a bug report), I can only work around the problem unless the installer is modified.
But my main questions are:
Why does the first call hang?
Why use %COMSPEC% instead of calling the batch directly?
In regards to #2, could this be because executing a .bat directly makes an assumption that the default action associated with a .bat file is to execute it? I've in the past (on other machines) changed this default action to 'Edit'. And if I'd done that, I would have hung the PostgreSQL installer as well! (I imagine)
The batch file executes normally on other machines. So there is something weird on this one laptop. So in regards to #1, I need to figure out why this one laptop is different. I should note that there are some weird behaviors with batch files on this machine (one which I just noticed):
The context menu actions contain only "Open" and are missing "Edit", "Run", "Run As"
Double-clicking a batch file opens a command prompt but does not execute the batch file
I just noticed #2 while writing this. Clearly the default action for .bat is messed up. Yesterday I nearly bricked my computer removing Context Menu Handlers from my registry as recommended by several sites trying to restore my "Edit", "Run", etc. entries.
Any advice on questions 1 and 2 would be appreciated.
Thanks,
Eric
The problem was an HKCU override on .bat which created an association to cmd.exe, as noted on this wonderful post. Additional help was found here.
My registry looked like this:
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.bat
\OpenWithList
(Default) REG_SZ (value not set)
a REG_SZ NOTEPAD.EXE
MRUList REG_SZ a
\OpenWithProgids
(Default) REG_SZ (value not set)
batfile REG_NONE (zero-length binary value)
\UserChoice
(Default) REG_SZ (value not set)
Progid REG_SZ (Applications\cmd.exe)
Removing the entire .bat entry fixed everything. All context menu items were restored properly (Open, Edit, Print, Run as Administrator, and Troubleshoot Compatability) and double clicking on the batch file executed the batch.
The .bat key re-generated automatically sometime after I deleted it and double-clicked my test batch file. This automatically generated entry was:
HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.bat
\OpenWithList
(Default) REG_SZ (value not set)
\OpenWithProgids
(Default) REG_SZ (value not set)
batfile REG_NONE (zero-length binary value)
Ultimately it was the \UserChoice key that was causing my problem. So I'm all cleared up now. My test scripts run properly and I re-installed PostgreSQL from scratch and the install went smoothly.
E
The 1st call launches a window that remains open until something tells it to close. Prsumably hello.bat terminates with an EXIT command, which would of course close the window, and your installation can then continue on its way.
But hello.bat fails to run on your one machine, so of course the window never closes, and your installation hangs.
The 2nd call through %COMSPEC% is opening a window and running CMD.EXE with the /C "command" option. The specifiation for the /C option states that CMD.EXE will terminate once the "command" completes (or fails). Your "command" is "hello.bat". Closure of the window is no longer dependent on an EXIT command in the hello.bat file. The window will close even if hello.bat fails to run.