Powershell exit code 4294770688 (FFFD0000) during vagrant up #10438
Comments
czukowski commented Nov 22, 2018
Vagrant version
Vagrant 2.2.1, (actually noticed the issue on 2.2.0 and upgraded in hope for a quick fix)
Host operating system
Expected behavior
vagrant up should have started successfully, as it has for a long time before today.
Actual behavior
Error message is displayed (excerpts from debug output):
My research
I think the error code indicates the command has not been executed because it was malformed. I tried to debug Vagrant::Util::PowerShell around here:
Lines 216 to 227 in 45766ad
I found that the EncodedCommand it has produced what appears to be a broken base64 string, see gist: https://gist.github.com/czukowski/9dba0e991ae3515a730ad13ef58f9411
The content of dpath variable was: C:/Users/CZUKOW
It breaks exactly at the tilde char in short path. The user directory name (czukowski) does not have any weird characters in it. Everything was working perfectly just yesterday.
I’m not very familiar with Ruby, but I suppose Dir.mktmpdir(«vagrant») is a built-in method?
Steps to reproduce
This must be something in my system. I am a long time Vagrant user, but today was the 1st time I encountered the issue, now it happens consistently on SMB share creation or pruning 🙁
The text was updated successfully, but these errors were encountered:
We are unable to convert the task to an issue at this time. Please try again.
The issue was successfully created but we are unable to update the comment at this time.
gerardog commented Nov 27, 2018
Decrypting the base64 confirms there is an issue there.
czukowski commented Nov 28, 2018
fwiw, my current workaround is to change TEMP and TMP environment variables to a full path name, then vagrant up works correctly.
I have to do it in a cmd window and keep it handy because each new program has these values reverted to original. In the registry they’re both set to %USERPROFILE%\AppData\Local\Temp and USERPROFILE is a full path (not 8.3), but somehow they become this:
gerardog commented Nov 28, 2018
I can confirm this issue does not occur on previous Vagrant version 2.1.5.
czukowski commented Dec 6, 2018
So I thought I’d give it a shot and try to debug it some more. I added a spec to powershell_test.rb to cover powerup_command method and try to figure out what values cause decoding issue. I’ve found that both path and args can affect it.
There are four test cases here:
From that I’ve produced four combinations which the test runs on:
Yes, I discovered there is more than one method to encode with Base64 in Ruby 🙂
Действия powershell exe с кодом возврата 4294770688
This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.
Answered by:
Question
I know it has already posted many times but I have already tried everything and still I can’t get it to work.
The script is a simple send email function and it works if executed from the command prompt:
But in the task scheduler it doesn’t work and no email is sent. The exit code of the task is 0xFFFD0000:
The task is configured to run under the SYSTEM account with highest privilege, powershell ist configured with unrestricted execution policy, why it doesn’t work?
I have tried also with a simpler task to create a text file
But it doesn’t work too, so it should be some other missing privilege somewhere but I couldn’t find anything in internet.
Thanks for any help
Answers
If you find that my post has answered your question, please mark it as the answer. If you find my post to be helpful in anyway, please click vote as helpful.
Depends on your operating system. There are 32-bit and 64-bit versions of PowerShell.exe, if you’re running a 64-bit OS.
All replies
I was able to reproduce this error by putting a bad path to a PS1 file in the command. When I used a path to a script that actually exists, it executed fine, and had a «Last Run Result» of 0.
If you find that my post has answered your question, please mark it as the answer. If you find my post to be helpful in anyway, please click vote as helpful.
@David Wyatt and @clayman2
Thanks, but the task had also a «Start in» path, although I tried to give the full path of the ps1 file but it didn’t work too.
At the end I have changed the «program» of the task from «powershell.exe» to «c:\windows\system32\windowspowershell\v1.0\powershell.exe» and not it works, but I don’t understand it, is there another powershell.exe?
Depends on your operating system. There are 32-bit and 64-bit versions of PowerShell.exe, if you’re running a 64-bit OS.
I found another possible issue while looking at a similar problem. I was unable to execute a PowerShell script as a Task Scheduler action, even though the script ran correctly when logged into Windows as the target user and running within PowerShell.
Task Scheduler would consistently display the 0xFFFD0000 error when I nominated the script in the task’s action arguments using what I believed to be normal PowerShell quoting rules:
PowerShell acquiesced and Task Scheduler fired off the task immediately and without issue when I changed the quotes I used from single to double:
Dropping to a command prompt and executing the full command immediately revealed the problem:
Notice the strange use of two single quotes before the path and one single quote after.
The moral of the story: When feeding the full path of a script to PowerShell as a command line parameter, use double quotes!
I know this is an older post. however I just ran across it trying to figure out why my PS script would not run in Task Scheduler and would run fine from PS.
In my case my script was collecting a list of computers from a text file and I did not have the full path name.
$servers = Get-Content ‘.\servers.txt’ (doesn’t work in Task Scheduler) $servers = Get-Content ‘c:\scripts\servers.txt’ (DOES Work in Task Scheduler)
Hope that might help someone out in the future.
In general, you want to avoid using relative paths in scripts anyway. When using PowerShell 3.0 or later, if you’re referring to something based on the folder the script is in, use «$PSScriptRoot\servers.txt» instead of «.\servers.txt»
I found another possible issue while looking at a similar problem. I was unable to execute a PowerShell script as a Task Scheduler action, even though the script ran correctly when logged into Windows as the target user and running within PowerShell.
Task Scheduler would consistently display the 0xFFFD0000 error when I nominated the script in the task’s action arguments using what I believed to be normal PowerShell quoting rules:
PowerShell acquiesced and Task Scheduler fired off the task immediately and without issue when I changed the quotes I used from single to double:
Dropping to a command prompt and executing the full command immediately revealed the problem:
Notice the strange use of two single quotes before the path and one single quote after.
The moral of the story: When feeding the full path of a script to PowerShell as a command line parameter, use double quotes!
To Reiterate the double versus single quote. Same issue on scripts I had used for years and in Task Scheduler. Script would seem to run, but no results. changed to double quotes an «Viola» worked right out of the chute.
Действия powershell exe с кодом возврата 4294770688
Сообщения: 14 Благодарности: 2
Профиль | Отправить PM | Цитировать
Добрового времени суток, господа автоматизирующие. Есть у меня PowerShell скрипты, автоматизирующие некоторые действия в моей системе (Windows 10) посредством запуска из планировщика заданий (Task Scheduler) по расписанию и по некоторым триггерам. Проблема состоит в том, что после каждого их выполнения задача висит со статусом «Работает» даже, если скрипт свои задачи выполнил. Вопрос в том, как вернуть код ошибки из скрипта, если он вызывается планировщиком заданий. К примеру, эффекта не даёт ни return, ни exit.
Ниже представлен один из моих скриптов. Конкретно этот перезагружает видео драйвер Intel HD Graphics после разблокировки экрана.
Конфигурация Профиль | Отправить PM | Цитировать | Сообщить модератору Цитата Kazun: Для начала проверить, что запускается скрипт и корректно завершается » Скрипт работает и завершается корректно, так как я проверял его работу в PoserShell ISE. »
Powershell script gives err 2147942401 in task scheduler:
It runs on a 64 bit PC; runs OK in powershell ISE and also in powershell itself.
The error massage is: Launche failure:
Task Scheduler failed to start «\zendRecentGPG» task for user «DESKTOP-OVGENM6\pinte». Additional Data: Error Value: 2147942402.
My executionpolicy is : unrestricted
Anybody an idea of the cause or how to debug further?
14 Replies
Create a bat file and schedule the bat file to run, the bat file should contain your PowerShell as above
Error Value: 2147942402 means file not found.
maybe also read here
thanks, I added GPEDIT.MSC since I have a home version of W10 and added my account at the «logon as a batch job», if that is what you ment.
It still gives the same error. I presume I do not have to add a env: path since it is fully specified in my arguments.
I ran the task with following checked:
v run hen logged on or not
v do not store psw
v run with highest priviledges.
That is not what I meant. I mean bat file, such as script.bat
But as Neally pointed out, the error is file not found
is not a full path, you need to complete this with
or whatever drive letter and location the file actually is.
Indeed I must have overwritten the drive letter when I recently added «Bypass». After re-adding D:\ [path]…. where the script is located, I still have the same error after double checking path and filename.
Task Scheduler failed to start «\zendRecentGPG»
Is this the task name or something else, why does it have a \ at the start and should it not be PGP instead of GPG?
I prefer not to use a bat of vbs file, but if it is not possible without it, I ll do that. In that case can I hide the execution of the bath and the PS1 from being displayed.
@rodit: my powershell script : d:\DATA-MEDION\soft_ontwikkeling\powershell\zendRecentPGP16.ps1
rodit: and indeed, you are right, the taskname is zendGPG while the correct filename is zendRecentPGP16.PS1, but this isn’t important, only confusing indeed.
rod-it; as for the \ at the beginning of the «\zendRecentGPG» name, I do not know where it comes from.
I found the error. My path to the powershell.exe was incomplete: it should have been
After correction it return code 0
Thanks to all for yr kind help!!
I found the error. My path to the powershell.exe was incomplete: it should have been
After correction it return code 0
Thanks to all for yr kind help!!
It should work if you just put «powershell.exe», usually no need for the full path
For what it’s worth, I was having a lot of trouble getting my scripts to run automatically via task scheduler. I’ve found that creating scheduled jobs via PS directly is far easier. Using the below code to set up the automatic jobs has saved me a bunch of headaches. Plus it can be run with whichever credentials needed, or set up on a remote computer easily.
batch file from scheduled task returns code 2147942401
I am trying to schedule a job to run a batch file with Windows 10 Task Scheduler, but it results in return code 2147942401.
The batch file is on remote location so I am giving the absolute path «\\server1\file transfers\data files\inbound\abc\csv\excel-to-csv.bat»
If I run the batch script with command prompt then it work fine.
The batch script is to convert excel to file to csv.
Content of the script is:
Its calling another VB script which is to-cvs.vbs
If i make changes in Action tab as mention by @Steinspecht(Task scheduler- task completed “successfully” with exit code 0x8007001) then also i am getting the code 2147942401 Not sure whether Add a arguments is written correct
6 Answers 6
The error codes for Task Scheduler are listed as hexadecimal at msdn, and your code 2147942401 converts to hex as 0x80070001 (which is not listed there), but this superuser describes it as an «Illegal Function». He fixed his problem by using «the simplest task scheduler settings and now it works». I note that he only runs his task when the user is logged in, so he doesn’t need «Log on as a batch job».
If you want to run the batch job when you’re not logged in, you need a special privilege called «Log on as a batch job». Note that there is also a «DENY log on as a batch job» privilege, which you wouldn’t want.
From Social Technet, you can assign that privilege with
This error code can also result from a bug/mistake in the actual Powershell script or Batch (.bat) file, even if all task scheduler settings, permissions, etc. are correct; in my case I was referencing a directory that doesn’t exist.
An old question I know, but I was getting 2147942401 error on windows 2016 server.
If you look at the scheduled task properties, on the bottom of the General Tab, it was defaulted to Configure for: Windows Vista, Windows Server 2008.
Changed to Windows Server 2016 and the problem was solved.
Throwing another common cause of the error action «powershell.exe» with return code 2147942401 here. If your action arguments are not correct you will also get this error message. Check that the action argument parameters and parameter values are spaced correctly.
Broken Example (no space between the ‘file’ parameter and it’s value):
M Herbener’s answer led to me attempting to run the script manually, to see if the script had an error. It did not, but it did highlight what the problem was as I received the error message:
[my script] cannot be loaded because running scripts is disabled on this system.
The solution, of course, was to run Set-ExecutionPolicy to allow Powershell scripts to run.
In this case, there was no point messing with the Group Policy settings because sometimes it would work. But not everytime. Which means it’s a timing problem, not a Policy problem.
Recreating, reconfiguring my task (as suggested in this SuperUser Q&A) did not fix the problem.
I did also consider butchering my batch file and getting rid of the standard output redirection, thus abandonning the logging capability (and becoming blind). Or simply running an actual «*.exe» process, instead of using a batch file at all. This could potentially have been a solution.
I also considered replacing the «At startup» scheduled task by a full-blown Service, but this would have been an expensive experiment for such a trivial problem.
Ultimately, I remembered that services can be delayed: «Automatic» vs. «Automatic (Delayed Start)». So I imitated this by added a delay on the scheduled task, in the Tasks Scheduler. For «At startup» scheduled tasks, it’s the trigger that have individual properties of its own, and that’s where the delay can be configured:
I believe my scheduled task was sometimes being started a few milliseconds too early and some OS service or functionality was not yet available or allowed. Simply adding a small delay on the trigger fixed the problem.
Профиль | Отправить PM | Цитировать
