I have a PowerShell script like this:
$tfExe = path/to/tf.exe
& $tfExt ... do something
On my computer (and other PCs) if I run this script I get the .exe output in my PowerShell window.
When I run the script on another computer (with Windows 7 32-bit) it opens a cmd window, the output displayed there, and the window is immediately closed.
The issue occurs for each .exe tool, even in robocopy.
Why does this happen and how can I change it?
I had another issue with my PowerShell and the solution to that issue also solved this issue.
In my PATHEXT environment variable I didn't have .exe. When I added it, the issue solved and all the .exe tools ran smoothly and the output appears in the PowerShell window.
I had a similar issue and figured out I had deleted the folder I was executing the commands from.
PATHEXT was ok:
But this was not (I had deleted it outside of PowerShell - oops):
Navigating to another path solved the issue.
You are starting an external exe, so it's working as intended. You could however try using cmd.exe /K - more info here https://ss64.com/nt/cmd.html
Related
CONTEXT:
Found a script on SO to download files from URL in PowerShell v2.0 (I am using Windows 7)
PowerShell.exe -ExecutionPolicy Bypass -Command "(New-Object System.Net.WebClient).DownloadFile( 'site.com/file.txt', 'file.txt' )"
Used a batch file .bat to run this script inline.
Works great -- for zip and images!
PROBLEM: Once I try downloading an .exe from URL, the batch file runs WITHOUT executing Powershell script. And Powershell.exe stops working completely in Windows 7...
Powershell (x86) still works, on the other hand.
Opening powershell.exe (x64) directly from folder: C:\WINDOWS\system32\WindowsPowerShell\v1.0 only opens blank window and closes immediately
Tried using sfc /scannow and DISM /Online /Cleanup-image /Restorehealth, but it's not working because Windows 7 doesn't have that option
Running the batch script again works, but the powershell part is skipped
I believe it works again after rebooting (haven't tested properly), but I can't seem to make Powershell (x64) work again without rebooting :/ I don't even know what the problem is as I don't know where to start debugging.
This question might be better suited for superuser.com, but I'm asking here first -- thanks for help :)
As #JCWasmx86 pointed out, it was indeed my Antivirus blocking Powershell.
I tested it extensively with Malwarebytes and Avast in different states -- turned off both of them, then switched them on one by one and ran my script after each state change. Turns out, once Avast got enabled, Powershell (x64, or the default one) got silently blocked after script execution, and persisted inactive until reboot or enough time had passed.
This only happened with .exe files. Avast must not like scripts downloading unverified exe files from the internet.
I have a windows batch script that, depending on the user menu selection, opens a powershell.exe and passing a variable to run a .ps1 script. I then use Bat To Exe Converted (v3.0.10) to convert it to an exe. A few hours ago I made changes to the PS script and copied it to the Win'2019 server and it accepted it. Now, I just changed two letters in a write-host message command and it keeps quarantining the file. Since this will be passed to customers I can't be telling them to ignore it or white list it.
I'm guessing the .bat and .ps1 files are throwing Windows Defender off. Funny how it was fine just a few hrs ago. Even if I undo the 2 letters I added it still deleting the exe.
The .bat is quite big and it'd be very difficult for me to convert and add inside the .ps1 script in hope of not setting off the trojan. What other options do I have to fix this? Is there a process or url to notify MS about this to get them to fix this false positive?
NOTE: No other Windows version or 3rd party antivirus that I've tried is detecting the exe infected. Only Win'2019's Defender is.
It looks like MS has fixed the false-positive with my code. I came in to work this morning and tried to copy the exe again and this time it worked. I didn't even contact MS (we don't have a support contract anyway).
Btw the exe consisted of a bat and ps1 script that just downloads some public install files (such as 7zip) from an https address, saves them and when running the exe the user would just get a menu of which of the downloaded programs they want to install.
The issue can be reproduced creating a simple new console application (Language : C++) with Visual Studio 2019 (Community Edition) and then just run program: Ctrl + F5. The solution that worked for me, to run the program, was to add the folder as an exclusion in Windows Defender Antivirus. I couldn't find any solution on other threads
I usually use the shortcut described here: How do I start PowerShell from Windows Explorer? to open a PS session in a specific folder. Just using powershell to open the sessions
However is no longer working, every time I write powershell on the address bar and hit enter it take me to the folder: C:\Users\MyUser\Documents\PowerShell (I'm in a Windows 10 laptop)
It seems to be related only to this shortcut as I have tried a few other things and they work. List of things I have tried/checked already below:
powershell -noprofile it work opening a PS session as expected
No, my $Profile file does not have anything to set the location of the PS Session.
powershell.exe works as expected
powershell_ise works as expected
going to File --> Open Windows Powershell works as expected
Checked my environment variables and nothing strange there either
It seems to be related to the fact that I installed PS core 6 recently. This installation introduced the folder C:\Users\MyUser\Documents\PowerShell (it's a new folder vs the ones that existed with Windows Powershell) and that's why the windows explorer now opens a folder instead of the command line.
I suppose I will need to get used to powershell.exe instead of powershell from now on.
I'm not sure if I'm being a bit thick, but I have a simple script with three lines:
$iis = 90000
$name = "somesite"
Write-Host("Values are: $iis and $name")
If I set a breakpoint on any of these lines and hit the play button (F5 - start debugging) the script runs but the breakpoints are ignored.
If I start the script with F11 (step into) I can step through just fine, however hitting F5 to run to the next breakpoint again causes PowerGUI to ignore the breakpoints
The script I'm working on is substantial and I don't really want to have to F11 through every line of code.
Why would this be?
I'm running PowerGUI 2.2.0.1358 on Windows 7 64-bit Ultimate Edition.
I tried both the x64 and x32 versions of the PowerGUI script editor without success.
I'm also running the PowerGUI Script Editor as Administrator (launched using right-click on PowerGUI Script Editor shortcut and Run As Administrator)
My PowerShell execution policy is set to Unrestricted.
It looks like there's a problem with PowerShell and square brackets in folder and filenames.
Both PowerGUI and PowerShell ISE won't hit breakpoint if the script being debugged resides in a folder with [ or ] in the name.
I had this problem when the script that I was running was on a remote file share.
E.g. \\serverA\FileShare\script.ps1.
When I saved the script as c:\script\script.ps1 it was ok.
Powershell apparently also has an issue with spaces in the folder names. It did not like 'My Documents' but did for 'Documents'. Once I switched my path in PowerShell within ISE the debugger worked again.
Having failed to get PowerGUI to work properly I've fallen back on PowerShell ISE. However if I run this as Administrator it won't let me set any breakpoints.
If I launch as normal (my login is a member of Administrators) all is well but because I need to script some tasks that require full administrator rights this is no good.
I have saved the script as a proper file (i.e. it's not "untitled1.ps1") but no joy.
I'm running Windows 7 x64 Ultimate.
Strangely this doesn't seem to be a problem on my Windows 2008 R2 dev box (I'm logging in as user that is a member of Administrators then running PS ISE "As Administrator" and breakpoints are set and hit.
Any ideas why this would be?
I also faced the same issue, saving the file to a physical location enabled all debugging capabilities.
It looks like there's a problem with PowerShell and square brackets in folder and filenames.
Both PowerGUI and PowerShell ISE won't hit breakpoint if the script being debugged resides in a folder with [ or ] in the name.
I notice you're running x64. Is there any chance that you're running x64 ISE but have only set the execution policy away from restricted on x86 (or vice-versa).
I am using Visual Studio Code and in my case, I was missing the powershell extension.
Was facing the same issue because I had used other editor to make changes to the ps1 file. After opening the file with PowerShell ISE and clicking "Save" solved the issue for me.