действия powershell exe с кодом возврата 4294770688
Действия 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 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:
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 🙂
Профиль | Отправить PM | Цитировать
