Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Thursday, December 6, 2018 8:23 PM
After a lot of experimentation and research I have the following behavior that I still do not understand.
I'm using PowerShell ISE:
PSVersion 5.1.17763.134
PSEdition Desktop
PSCompatibleVersions {1.0,2.0,3.0,4.0...}
BuildVersion 10.0.17763.134
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
The symptom is that if I right click on certain .ps1 files and select Edit, then Run Script (F5) in PS ISE, I get the following message:
Cannot dot-source this command because it was defined in a different language mode. To invoke this command without importing its contents, omit the '.' operator
If I then type .\script>.ps1 in the prompt window and hit return, the script runs. Based on this, I get the impression that F5 dot sources the script it is about to run. Thing is, this happens on a signed script consisting of just a "#", so the script itself is not the issue... right? But...
(1) The current language mode is Constrained. What is PS consulting to determine the script was "defined in a different language mode?"
(2) Why does this only happen to certain scripts?
Note that I am not asking for a workaround, so please no suggestions about how to change language modes. I'm trying to understand what PS is doing behind the scenes that is resulting in the error for only some scripts.
Thank you
All replies (18)
Thursday, December 6, 2018 9:38 PM
Are you trying to remote a command? Language mode is usually in reference to a remote connection (PS endpoint).
Run this in ISE:
$ExecutionContext.SessionState.LanguageMode
If it shows "Contraied" then someone or something has added retrictions to PowerShell perhaps through Group Policy.
See: https://www.petri.com/protect-malware-enforcing-powershell-constrained-language-mode
\(ツ)_/
Friday, December 7, 2018 12:58 AM
The result of running the command is "ConstrainedLanguage" and I'm aware of that part, thank you.
In File Explorer, right clicking on x.ps1 > Edit invokes PS ISE and then F5 yields the error in red above. Subsequently typing .\x.ps1 to the prompt in PS ISE and hitting return runs x.ps1 without issue. x.ps1 is signed and Get-ExecutionPolicy -List yields AllSigned for CurrentUser and Undefined for everything else. The body of x.ps1 consists of a single "#".
In File Explorer, right clicking on y.ps1 > Edit invokes PS ISE and then F5 runs without issue. Subsequently typing .\y.ps1 to the prompt in PS ISE and hitting return runs y.ps1 without issue. y.ps1 is signed. The body of x.ps1 consists of effectively a single line "& C:\w\z.ps1".
Since neither x.ps1 nor y.ps1 dot source, is it a correct assumption that F5 attempts the dot source? It kind of makes sense to me that when you click F5 and "play" a script the first action of PS ISE is to dot source the script into the debugging environment. Note that the message tells me to correct the error by no doing something I'm not doing in the first place.
The error reported is that the script "was defined in a different language mode" which sounds like PS ISE is referring to an action that occurred in the past. What source would PS ISE be consulting to determine that x.ps1 was defined in other than ConstrainedLanguage but y.ps1 was not? x.ps1 was copied from another machine and was created in FullLanguage mode but unless there is an embedded resource or list somewhere I don't see how that matters.
Thank you
Friday, December 7, 2018 1:16 AM
PowerShell does not natively run in constrained mode. Someone has changed that. You need to find out why. It is possible that you accidently changed it.
PowerShell cannot normally be executed from explorer. "Open"/Edit opens file ISE. There is no default too execute PowerShell PS1 file. You can add a registry entry that can execute from Explorer.
Somewhere you or someone else has altered your system. It is also possible that something has changed the trust settings for you system.
Since this is not a break/fix forum you will have to contact MS support and have them help you troubleshoot this if you do not know how to do this.
\(ツ)_/
Friday, December 7, 2018 1:18 AM
Also note that using .\file.ps1 is NOT dot sourcing a file. It is specifying that the current path is to be used to find the file.
\(ツ)_/
Friday, December 7, 2018 1:43 AM
Thank you for your insights.
I understand that .\file.ps1 is not dot sourcing a file. My theory is that F5 in PowerShell ISE (the equivalent of Debug > Run/Continue) dot sources the script in the active script window because that is the only way I can get the error to make any sense.
FWIIW I have used PS installations on three machines and never performed a special installation. On all three, double clicking on a .ps1 file opens it in Notepad and right click > Edit opens it in PS ISE. On two, when I upgraded to PS v4 ContrainedLanguage was turned on and I set it to FullLanguage.
As a payback for your time when I figure this out would it be beneficial to post the resolution here? Or not?
Friday, December 7, 2018 1:50 AM
...and you raise a good point regarding group policy. I'm really just trying to understand why PS is complaining about one script and not the other. Thank you.
Friday, December 7, 2018 1:57 AM
No. Debugging does not dot source anything. dot sourcing is used for something completely different. You need to do some research to learn the basics of PowerShell as you seem to be going on guesswork.
If you find the cause it might be helpful to others so feel free to update us on the outcome.
\(ツ)_/
Friday, December 7, 2018 2:17 AM
I am going on experimentation and I researched this prior to posting to this forum, hence the script consisting of a comment.
Given that the script in the PS ISE window consists of a single # and a signature block, and given that when I click F5 I immediately get the error below, what is your explanation as to why PS ISE is reporting that I "cannot dot-source this command" when the script itself does not dot-source? Aside from that, why does PS ISE have no issue executing the script directly from the prompt? From PS ISE's perspective, what is the significant difference between those two actions?
Thank you.
Cannot dot-source this command because it was defined in a different language mode. To invoke this command without importing its contents, omit the '.' operator
Friday, December 7, 2018 2:35 AM
Start by fixing your system.
There is definitely an issue that we cannot see or determine. Contact MS Support for help.
\(ツ)_/
Friday, December 7, 2018 2:41 AM
Fair enough. I'll let you know what I find out. Thank you for your help.
Friday, December 7, 2018 2:52 AM
Good luck.
Sorry I can't be of more help but I would need access to your system and about a half hour to analyze it.
\(ツ)_/
Friday, December 7, 2018 4:16 AM
I think the following proves my first point:
The script was opened with PS ISE by right clicking > Edit. I then invoked the script from the command prompt, then hit return to exit. Note that when I then inspect the variable $Root it is undefined, which makes sense because the script has terminated.
I then ran the script by clicking F5 and exited. Note that the value of $Root remains defined.
So clicking F5 or selecting Debug > Run/Continue results in PS ISE dot-sourcing the script into the current debug session so you can inspect variables after the script has terminated. In Constrained Language mode on my system, PS is preventing this in other cases because it doesn't trust the scripts for some reason yet to be determined. But at least this explains the error message and why you can get a dot-source error when debugging, which is useful to know.
Whew.
Friday, December 7, 2018 4:27 AM
No. That is the normal behavior of ISE. It does not explain your issue.
\(ツ)_/
Friday, December 7, 2018 7:21 AM
"No. Debugging does not dot source anything. dot sourcing is used for something completely different."
"No. That is the normal behavior of ISE. It does not explain your issue."
If the normal behavior of ISE when you click F5 is to dot-source the script into the debug environment, then debugging dot-sources the script!
Correct, for some other completely different reason ISE thinks the language mode of the debug environment is different from the language mode some of the scripts were created in because they are not trusted even though they are signed; it doesn't explain that.
But it explains why ISE has an issue with F5 but not with running those scripts from the command prompt because the latter does not dot-source the script but the former does. That' what the message means; F5 successfully dot-sourced hsUnarchive.ps1 into the debug environment but it cannot dot-source other scripts into the debug environment:
Cannot dot-source this command because it was defined in a different language mode
Friday, December 7, 2018 11:11 AM
First fix your system. The rest will become obvious.
\(ツ)_/
Friday, December 7, 2018 5:58 PM
I appreciate your patience, help, and insight.
Monday, December 10, 2018 6:04 AM
Hi,
Was your issue resolved?
If you resolved it using our solution, please "mark it as answer" to help other community members find the helpful reply quickly.
If you resolve it using your own solution, please share your experience and solution here. It will be very beneficial for other community members who have similar questions.
If no, please reply and tell us the current situation in order to provide further help.
Best Regards,
Lee
Just do it.
Tuesday, December 11, 2018 6:31 AM
Hi,
Was your issue resolved?
If you resolved it using our solution, please "mark it as answer" to help other community members find the helpful reply quickly.
If you resolve it using your own solution, please share your experience and solution here. It will be very beneficial for other community members who have similar questions.
If no, please reply and tell us the current situation in order to provide further help.
Best Regards,
Lee
Just do it.