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.
Related
I'm running Powershell ISE as local administrator on Windows Server 2012 R2. The Toggle Breakpoint F9 is greyed out. It looks like with this account, it is bypassing UAC and thus running "as Administrator".
I am opening an existing script file to run and it does not have brackets [] in the file name/path anywhere. Any other ideas to explain what's going on here?
Edit: I just installed the Visual Studio Code editor and it does the same thing. F9 is not greyed out in the menu, but it does not set a breakpoint. Again, this only happens when logged in as the built-in administrator.
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 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
I use the AutoHotKey script to map some the keys under Windows 10 OS . It works very well except that I started Powershell as administrator. All the key mappings does not work after that as if autohotkey has been shut down. However things are all fine when I run PowerShell without administrator. Anyone knows how to fix that?
As Bluecakes said, just running the AutoHotKey as administrator will fix my problem.
You can either set the AutoHotKey to run always as administrator by right-click on AutoHotKey.exe and select property, in the compatiblity Tab , check the run this programme as administrator, or you can add a 'run as administrator' entry in the right-click menu of ahk scripts by editting the registry. Following this link:
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.