Strange anti-malware exception in C# code executing a PowerShell script

Question

I have powershell code in my C# application that works great. It executes a script using the code snippet below.

using (PowerShell powerShell = PowerShell.Create())
    {
        powerShell.AddScript(@"D:\C.ps1");

        Collection<PSObject> output = powerShell.Invoke();
    }

Like I said, it works. However, recently I wanted to add a Windows Form to the script. The very first thing I did was add the following line to the top of the script and nothing else. Without doing anything else, I just ran the C# app that executes the previously working script to make sure that loading of the assembly does what it's supposed too.

[void][System.Reflection.Assembly]::Load('System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a')

Immediately I get the strange following exception.

System.Exception {System.EntryPointNotFoundException}

Unable to find an entry point named 'AmsiNotifyOperation' in DLL 'amsi.dll'

I've search online for days and found nothing like this. I can't even get started adding my new script code because of this exception for the assembly load line.

Oh, very important, When I run that script with that new line from the Powershell ISE app, the command line, or several other powershell script tools I have. THE PROBLEM DOESN'T HAPPEN.

Anyone got any ideas?

Here is the nuget packages that the code is using, and the stack trace.

Nuget packages:

System.Management.Automation

Microsoft.Powershell.SDK

Stack: Source "System.Management.Automation" at System.Management.Automation.AmsiUtils.AmsiNativeMethods.AmsiNotifyOperation(IntPtr amsiContext, IntPtr buffer, UInt32 length, String contentName, AMSI_RESULT& result) at System.Management.Automation.AmsiUtils.WinReportContent(String name, String content)

TargetSite {Int32 AmsiNotifyOperation(IntPtr, IntPtr, UInt32, System.String, AMSI_RESULT ByRef)}

It's not clear what you are trying to accomplish. If you're using C# to run PowerShell, then why try to run C# code using PowerShell? According to [Resolving PowerShell module assembly dependency conflicts](https://learn.microsoft.com/en-us/powershell/scripting/dev-cross-plat/resolving-dependency-conflicts?view=powershell-7.3#powershell-and-net): _... PowerShell 5.1 and below run on .NET Framework, while PowerShell 6 and above run on .NET Core._. — Tu deschizi eu inchid, Jul 24 '23 at 14:15
According to [Choosing the right PowerShell NuGet package for your .NET project](https://learn.microsoft.com/en-us/powershell/scripting/dev-cross-plat/choosing-the-right-nuget-package?view=powershell-7.3): _PowerShell 6+ provides its own shim assemblies for type forwarding from .NET Framework 4.6.1 (and above) to .NET Core. This means that as long as a module uses only APIs that exist in .NET Core, PowerShell 6+ can load and run it_ — Tu deschizi eu inchid, Jul 24 '23 at 14:18
Don't load assembly. Instead add to top of script : using assembly System.Drawing — jdweng, Jul 24 '23 at 14:42
@jdweng Thanks for the comment, but can you explain why the line doesn't work, and why it does work in Powershell ISE and other tools. Oh, and what the exception is. Thanks — K. Carter Sr., Jul 24 '23 at 14:47
@ Tu deschizi eu inchid, using C# to run PowerShell, there a many reasons and quite common to run C# code using PowerShell I believe. I'm reviewing your links to see what information I can glean from them. Thanks — K. Carter Sr., Jul 24 '23 at 14:54
Powershell is written in the Net Library and works like any c# application. In c# you add library references. You do not load the Net Library dlls. — jdweng, Jul 24 '23 at 15:03
@K.CarterSr.: While I'm not quite sure how _common_ it is, it seems that you're trying to use C# to run a PowerShell script that contains C# code. Is this correct? — Tu deschizi eu inchid, Jul 24 '23 at 15:23
@Tudeschizieuinchid, no, the PowerShell script merely happens to use .NET APIs (WinForms) directly. — mklement0, Jul 25 '23 at 21:17
@jdweng, a `using assembly` _parse-time_ statement is indeed preferable to loading an assembly at _runtime_, e.g. with `[System.Reflection.Assembly]::Load()` or `Add-Type -Assembly`. Given that _all_ these approaches _work_, you should make it clear that you're making a _general recommendation_ that is _incidental to the question at hand_. In that vein: Regrettably, up to at least PowerShell (Core) 7.3.6, `using assembly` statements are _broken_ - see [GitHub issue #11856](https://github.com/PowerShell/PowerShell/issues/11856). Here, the problem is that the assemblies _aren't available_. — mklement0, Jul 25 '23 at 21:36

mklement0 · Accepted Answer · 2023-07-25T21:26:26.113

I'm not sure if the following will solve all your problems - notably with respect to the AMSI (Antimalware Scan Interface) errors - but the following steps worked for me:

The PowerShell SDK itself does not include the WinForms assemblies as part of its Microsoft.PowerShell.SDK NuGet package (which is the NuGet package for PowerShell (Core) 7+).
- Note that this is the only package needed to host PowerShell (Core) in a .NET application - do not also include the System.Management.Automation package, whose direct use is recommended against.
- See also: Choosing the right PowerShell NuGet package for your .NET project
Therefore, you need to make sure that your .NET application comes with the WinForms assemblies:
- The simplest approach is to initialize your .NET SDK project as follows (which targets .NET (Core) rather than .NET Framework, just like your own attempt):
```
dotnet new winforms
```
  - You can then remove the unneeded Form1.cs and Form1.cs.designer files (which you would only need if you want to interact with WinForms from C#), and replace the startup code in Program.cs
Then, in your PowerShell script file (.ps1), load the WinForms assemblies as follows, which should use the ones that come bundled with your .NET application:
```
# Loads the WinForm assembly/ies, produces no output if successful.
Add-Type -AssemblyName System.Windows.Forms
```
- Optionally place statements such as using namespace System.Windows.Forms at the start of your script, to allow you to refer to the Form class as just [Form] rather than as [System.Windows.Forms.Form], for instance.
  - Note: Replacing the Add-Type call with using assembly System.Windows.Forms is called for too, but, regrettably, up to at least PowerShell (Core) 7.3.6 (unlike in Windows PowerShell), attempting to do so is broken - see GitHub issue #11856.
- A simple test to see if loading succeeded is to execute the following PowerShell statement in your script, after the Add-Type call:
```
 # Create as sample form and shows it modally.
 [System.Windows.Forms.Form]::new().ShowDialog()
```
As an aside:
- Unless you need to execute a piece of PowerShell code, it is better to use the .AddCommand() rather than the .AddScript() SDK method:
```
 powerShell.AddCommand(@"D:\C.ps1");
```
- See this answer for an explanation.

score 1 · Answer 2 · edited Jul 25 '23 at 15:49

@mklement0 Thanks for your detailed answer. It definitely put me on the right path. I'm marking your answer as the solution.

So as you suggested, first I had to find a way to bring in the Forms dll's into the project. The problem is that this is a .Net MAUI application. I couldn't think of a good way to do that. But I thought about it and decided to create a second project that was just a Windows forms class and use it as a dependency for the first project. That pulled in the Forms dll's into the first project. The problem is that this pulls them in for the Android, IOS, Mac OS platfroms too. So I modified the MAUI .csproj file to prevent that. It worked. Then I removed everything from the script file and only added the first line you suggested, so that I could test things out. Then I added the second line. More on that later on in my replay See the code below.

SECOND PROJECT:

public class DependencyClass
{
  public Form DoNothing()
  {
   var form = new System.Windows.Forms.Form();
   return form;
  }
}

MAUI PROJECT FILE MODIFICATION:

<ItemGroup Condition="$(TargetFramework.Contains('-windows')) != false "> 
  <ProjectReference Include="..\WinFormsLibrary\WinFormsLibrary.csproj" />
</ItemGroup>

CHANGE TO MAUI PROJECT PSHELL CODE:

      . (code)
      .
      .
var doNothingClass = new WinFormsLibrary.DependencyClass();
var doNothingForm = p.Test();
      .
      . (code)
      .
      .
powerShell.AddScript(@"D:\test.ps1") // Will change to AddCommand
      .
      .
      . (code)
      .

So, after I added the first line,

Add-Type -AssemblyName System.Windows.Forms

the script ran fine.

After I added the second line,

[System.Windows.Forms.Form]::new().ShowDialog()

if failed with the AMSI Exception

I had a hunch that if I just ignored the exception in a FirstChanceException handler that the code would execute. It worked and the form was displayed!

I'm leaving some related changes and detail out of the conversation to try to keep this short.

If you know a better way to bring in the needed dll's let me know.

I have to add code to the second class project for every dll I need in the Maui project. e.g.
new System.Runtime.Serialization.Formatters.Binary.BinaryFormatter() for the resource file stuff, and etc stuff.

As far the exception is concerned, I have no idea. But it doesn't seem to prevent anything from working.

Cheers K. L. Carter Sr.

Strange anti-malware exception in C# code executing a PowerShell script

2 Answers2