My current environment is Windows 7 Enterprise Edition(SP1) with PowerShell V5
PSVersion = 5.0.10586.117
For somehow when I try to run the following statement (it worked well before)
new-object System.Net.WebClient
I started to get the following error
I checked
$ExecutionContext.SessionState.LanguageMode
and the result is: ConstrainedLanguage
I am now at a loss on how to change this LanguageMode to "FullLanguage" as mentioned in this URL
I googled around and do not see anything related to my environment, the closest link I see is here in MS technet forum. But in my case, I do not think it is AppLocker enabled (or do I have to ask my network admin to check the group policy?) and I do not see any SRP (Software Restriction Policy) on my local computer either.
Could someone please tell me how to fix this issue or how to check various aspects that lead to this LanguageMode change? or is there a way that I can edit the LangugageMode value?
Thanks in advance for your help.
Ok, after numerous attempts, I finally figured out why. I updated my WMF 5.0 production preview to the WMF 5.0 Production RTM about 10 days ago, but since then, I have not run any scripts including
new-object System.Net.WebClient
and as such, I never encountered the error mentioned.
After I uninstalled this WMF 5.0 Prod RTM version, I am now in PS Version 4.
PSVersion = 4.0
and when I run
$ExecutionContext.SessionState.LanguageMode
I get "FullLanguage" value as shown below
So I think it is kind of a bug for WMF 5.0 to Windows 7.0, and MS should fix it.
I checked my computer with Win 10 OS and WMF 5.0 RTM, the LanguageMode is still "FullLanguage".
[Edit]: 2016.Nov.25
I think I need to update this answer by saying that since the error occurred and I downgraded to V4, it solved the problem, but probably another two weeks later, I reinstalled WMF 5.0 (I believe the downloaded file is different from my initial downloaded file as the download link are different), now this solves the problem as well, i.e. in PS V5.0, the error does not appear again.Here is my current environment
To change the languagemode you can just use the variable:
$ExecutionContext.SessionState.LanguageMode = "FullLanguage"
Related
I have an Azure function app that runs some Powershell and as part of it I am importing a custom Powershell module I wrote. I had tested it and it worked, but when I went to test it again it no longer imports the module correctly, it instead gives the following error and I cannot determine why. Because the Powershell on the Azure function is Powershell Core 7.2 and my module requires Windows Powershell 5.1 (its accessing funtions from the AzureAD Powershell module to update a users password and assign a license to that user) I am calling the Import-Module with the -UseWindowsPowershell parameter to enable compatibility.
I've tried several solutions but none of them seem to address the problem, so any help would be greatly appreciated.
ERROR: Failed to generate proxies for remote module 'AzureCon'. The -OutputModule parameter does not resolve to a path, and a user module path cannot be found for the provided name.
I believe this error is not due to PowerShell Code issue.
It is an environment setting variable (PSModulePath) has to be checked.
($env:PSModulePath).split(";")
It was an issue with PSModulePath. Something put in Windows\System32\WindowsPowerShell\Modules into the PSModulePath. I'm guessing when 7 tried to load utility it loaded 5.1 utility instead and blew up. Fun troubleshooting though. Now need to find root cause.
Refer to the Import-Module: Failed to generate proxies for remote module
Update:
Similar ticket raised in MSFT Q&A and it is identified as a new function runtime release broke this functionality.
Thanks to #MayankBargali for the workaround given to fix this issue.
Apology for the inconvenience due to this issue. The workaround is to update the runtime version to 3.8.2.0 by updating the FUNCTION_EXTENSION_VERSION in tha application configuration of your function app if you are running PowerShell function version 7.
The product team will be fixing the issue in the latest runtime.
For the tracking of this issue, refer to the MSFT Q&A 920865.
I have encountered an error when trying to launch Powershell ISE. The launch starts with 'Loading' displayed in the splash panel, then a dialog box comes up with "An unexpected error has occurred, and Windows PowerShell ISE must close"
I have Googled this error and come up with nothing specific, but I have followed a few steps that have been suggested for fixing other issues.
Platform: Windows 8.1 Pro
Powershell ISE product version: 10.0.14409.1005
(Cannot open shell so cannot run cmdlet to get exect version details)
Things I have tried
1 The plain Powershell shell **does** launch.
2 Tried launching ISE with -NoProfile & -MTA switches no luck
3 Rename powershel_ise.exe.config so it cannot be read in both System32 & WOW64 folders
4 Upgrade .NET Framework to 4.5.1
5 Upgrade Management Framework to 5.1
6 Other machines within our environment with same image and patch level have **not** encountered this problem
7 Cannot find an associated error in the Event viewer logs
I really don't want to blow the machine away and start again so any suggestions or fix would be appreciated !
Angus
I had the same issue, I was able to fix it with recreating my user profile.
You can log as different user and try to run powershell_ise in that profile, if it runs, so more likely you can fix it. Just have somebody with admin rights delete your profile, and then just log back. Or if you have admin rights go create another account with admin, go to system properties / user profiles and remove your current profile ( just save files you need to keep)
"I renamed the C:\Users<name>\Documents\WindowsPowerShell directory and re-ran ISE and it didn't crash. Something up with that profile directory for me... –
Duncan Smart
Feb 10 '21 at 11:07"
Solved my similar issue! :D
Go to Documents C:\Users<loggedinProfileName>\Documents\WindowsPowerShell and re name from WindowsPowerShell to Old_WindowsPowerShell it will work if its crashes because for user profile.
The problem I need to be solved is that the Nuget Package Manager Console in Visual Studio 2013 cannot start because the Windows Powershell raises the error:
The shell cannot be started. A failure occurred during initialization: The type initializer for 'System.Management.Automation.SessionStateScope' threw an exception.
I tried reinstalling nuget, repairing VS2013, changing the execution policy in powershell x86 (the common solution given here in stackoverflow) but the error persists.
Until I realize that the problem is in the x64 powershell(C:\Windows\SysWOW64\WindowsPowerShell\v1.0) because the x86 version is fine.
I'm using Visual Studio Ultimate 2013 Update 4 32-Bits in Windows 8.1 x64
I found out the answer, it has to do with the legacy security policy in .Net
I open the file C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config and set the attribute "enabled" to False in the tag NetFx40_LegacySecurityPolicy and voilá, the powershell of SysWoW64 is working.
In my case I was receiving this same error for an unknown reason and thanks to this hint I looked for the NetFx40_LegacySecurityPolicy in
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config
and
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config
but could not find that tag...
I did see LegacyCasPolicy enabled="true" in
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config
and set it to false...viola, worked like a charm...Had no idea of how this got set but could not find a solution to this problem anywhere, and no, I did not have any corrupted system files.
Same issue different key.
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config
Change to false
NetFx40_LegacySecurityPolicy enabled="true"
Not sure why, but today my workstation refuses to load the Powershell ISE. I can load Powershell just fine and my cmdlets work. I've tried loading both the 32bit and 64bit ISEs and both crash for the same reason.
This is the crashdump:
Problem signature: Problem Event Name: PowerShell NameOfExe:
PowerShell_ISE.exe FileVersionOfSystemManagementAutomation:
6.1.7600.16385 InnermostExceptionType: System.Xml.XmlException OutermostExceptionType: System.Reflection.TargetInvocation
DeepestPowerShellFrame:
indows.PowerShell.GuiExe.Internal.GPowerShell.Main DeepestFrame:
indows.PowerShell.GuiExe.Internal.GPowerShell.Main ThreadName:
unknown OS Version: 6.1.7600.2.0.0.256.48 Locale ID: 1033
Read our privacy statement online:
http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409
If the online privacy statement is not available, please read our
privacy statement offline: C:\Windows\system32\en-US\erofflps.txt
I couldn't find anything on google on this crash so I'm hoping someone here has some guidance.
This may be completely unrelated but in my case, I didn't understand much when I looked through Process Monitor to determine what was causing the crash as a windows update (cherry picked by our Helpdesk team), broke my PowerShell ISE launch, I also tried running without a profile. with Powershell_ISE -NoProfile
I followed the techcommunity thread and was able to fix my issue with Solution #3 GlobalUserInterface.CompositeFont from dotnet github issue
All I had to do was download this font and update it at below locations, PowerShell ISE is a WPF Application and Fonts were corrupted by dotnet upgrade as a part of KB4074906
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\WPF\Fonts and C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\Fonts
I've been writing up a script that runs some server functions using a web-browser interface. I coded up the script on Windows 7 with Internet explorer 8 and it works fine.
As soon as I move it to the production server running Windows 2008 with Internet Explorer 9, it breaks. Finally traced it the point of failure, but I'm a bit stumped how to fix it.
Here's the code that will cause an issue:
$ie = new-object -com "InternetExplorer.Application"
$ie.navigate("http://www.google.com")
$ie.visible = $True
$doc = $ie.document
$Object1 = $doc.getElementByID("pocs")
This pops up an IE windows, and it should be able to search elements by ID. Trouble is, now I get the error
"Cannot find an overload for "getElementById" and the argument count:
"1"."
I can find very very little on this error. The actual issue is actually the variable $doc. If I do a "$doc | get-member" on IE 9 I get:
TypeName: System.__ComObject#{c59c6b12-f6c1-11cf-8835-00a0c911e8b2}
But under IE 8 I get:
TypeName: mshtml.HTMLDocumentClass
So, basically, IE 9 / Windows 2008 is failing to load the web document contents when I call $ie.document. I've tried setting IE9 to compatibility mode, but no luck there.
The $ie.document | get-member does actually show the method of : "getElementById Method Variant getElementById () " so it's in there, but there's no document for it to parse.
Any ideas would be greatly appreciated.
I am equally astonished this has not been fixed yet given the longevity of the issue on various technical forums. However I think I have found the solution, though it would be up to the Microsoft IE team to address at some point.
Like all the threads referenced that have looked into this I have suffered the same issue with the getElementById method, which with no other changes to a couple of test machines (one Windows 2008R2 Enterprise 64bit and one Windows 7 32bit), I can get the same script to work.
Workarounds that worked as temp solution that I didn't like:
Using the dev console in IE11, switch the Document Mode to 8 (9,10,11,Edge (default) don't work) - my automation script works instantly. No changes to IE trusted sites, zone security, protected mode, PowerShell session priveleges). So clearly just a component issue of the IE11 installation of some sort
Installing Office 2013, without ever running or licensing it, the same script works instantly without changing the Document Mode of IE11. Clearly Office does install/register something that fixes the problem (as Rhys Edwards says)
So I set about narrowing down what Office does to enable the COM object required for IE automation by:
Preparing a new Virtual Windows 2008R2 Server , no updates. Ran test script under IE8 - no issues.
Upgraded to IE11. Ran test script - failed as usual.
Took a VM snapshot
Used Regshot to do record the registry and file system
Ran the Office 2013 Pro_SP1 installation, no changes to default options
When Office install completes, did not run office once (at all ever)
Ran test script again - everything works, the IE automation with getElementById calls all back in operation
Took a 2nd VM snapshot
Ran 2nd scan with regshot and analysed the differences
Dumped the properties of my $ie object and also noticed there is far more there than before running Office install. References mshtml.dll and HTMLDocument classes throughout - looks as it should
I can see from the RegShot difference file that MSHTML.dll is ADDED and registered in the GAC (version 7.0.3300.0) by the office installation
What I did next may not be completely approved but:
I located the microsoft.mshtml.dll in the "c:\program files(x86)\Microsoft.net\primary interop assemblies" folder and saved it out of the VM to my local machine desktop
reverted to the pre-office 2013 snapshot
copied the microsoft.mshtml.dll into the VM and installed to the GAC (remember this is a 2008R2 server still on .net 2, I didn't update .net prior to or after IE11 install, only office). I installed to the GAC simply by dragging the file into the c:\windows\assembly view in explorer. In later versions of .Net you need to use gacutil /l
Tested the same script and BOOM, it all works fine. No need to change any IE settings or elevate script privileges or install Office
So to sum up. If you install IE11, to get PowerShell to automate the Document Model, I had to (re-)register the mshtml.dll in the GAC. Why the IE11 installation doesn't ensure this happens is beyond me but I think that the IE team need to look into this.
I also think for those where it 'just works' in IE10/11, you must have a product on the machine that has already registered the mshtml.dll in the GAC (perhaps Office, perhaps Visual Studio or some other MS app). Hence why you are not seeing the same problem that definitely exists.
Hope this helps someone - it was driving me crazy!
Andrew
As detailed in the comments on the question, there seems to be three solutions to this problem.
Upgrade to PowerShell 3.0: Version 2.0 is only compatible with up to IE8 when it comes to web-scraping and using IE as an object. However, version 3.0 will work with IE9. You can get it here.
Turn off protected mode in IE: Turning of protected mode for the Internet zone under the Security tab in settings seemed to do the trick for me. There are security implications to this that should be carefully considered.
Run the script in admin mode: Simply run the script in an elevated PowerShell prompt.
The last two solutions come from a different SO answer.
I had similar kind of issue and it got resolved by following below steps:
Check for the Microsoft.mshtml.dll on your machine. It should be available at location C:\Program Files (x86)\Microsoft.NET\Primary Interop Assemblies. If you don't find it at this location, It might be the case that you don't have this dll and this is the reason you are getting this issue.
Find the dll, and try to load the assembly at run time. You can place the dll at any location on you machine and do it.
Below is the link to a method to load assembly at run time.
https://onedrive.live.com/?cid=21ad54fd70600673&id=21AD54FD70600673%211922