Calling PowerShell - x86 vs. x64

Started by seckner, November 18, 2016, 11:07:23 AM

Previous topic - Next topic

seckner

With thanks to Tony I've got Winbatch calling a PowerShell script to delete a bunch of bloatware (3dbuilder, bingfinance, etc.. ) The code that works is below. This will ONLY work if I compile the script as x86 - if I compile it as x64 it throws a COM/CLR exception  System.Management.Automation Object reference not set to an instance of an object. It only happens on an x64 compile - x86 breezes right on through. What am doing wrong?

cRun=FileGet(cScript)
ObjectClrOption("use", "System.Management.Automation,version=1.0.0.0,publicKeyToken=31bf3856ad364e35,culture=neutral")
objAutoPs = ObjectClrNew("System.Management.Automation.PowerShell")
oPshell = objAutoPs.Create()
oScope = ObjectType("BOOL",@TRUE)
oPshell.AddScript(cRun,oScope)
objAsync = oPshell.BeginInvoke()
oPShell.EndInvoke(objAsync)
oPshell.Dispose()
oPshell=0

td

The "System.Management.Automation" assembly has MSIL processor architecture so bitness isn't the issue with regard to the assembly's compatibility.   The script originally posted back in , I think, January that demonstrated using the assembly, works equally well in either 32 or 64 bit WinBatch.  That suggests that the cause may be something in your PowerShell script hat is sensitive to bitness.  First, which line in your WinBatch script  is causing the error?  Obviously, if the error is occurring before you pass the PowerShell script to the assembly class object, the PowerShell script cannot be the problem.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

seckner

I'm sorry - should have put that in there - duh! Also included the ps1 file. This is the error line: oPShell.EndInvoke(objAsync)

td

Nice way to get rid of the bloat but there is nothing that jumps out as bit related in the ps script.  You may (or may not) be running into permission issues since you are working in a Windows 8/10 environment.  Check your compiler settings to make sure your 64-bit UAC settings match your 32-bit compiler UAC settings.   UAC settings seem to be the most common problem users have post Windows 7.  If this isn't the cause, let us know and we will look into it some more.   

 
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade