PowerShell not loading them DLLs

How to resolve issues when loading DLLs in PowerShell?

This post was most recently updated on January 25th, 2020.

Reading Time: 3 minutes.

This post describes a few different things that can (and will) go wrong when you’re trying to load DLLs in PowerShell, and a couple of ways you can try to fix them. Typically, you’d run into an error message like “Exception calling LoadFrom with 1 argument(s): Could not load file or assembly…. “

These issues most typically arise when you’re running a PowerShell script that depends on certain DLLs to be loaded (to then execute some of the methods from them). This could happen kind of behind the scenes – if you’re importing modules from a path, you’re still essentially loading DLL files, just by using a wrapper around them.

The script never gets far enough to execute anything, though – the error is thrown already when you try to load them into memory.

My most typical use case that I’d run into, would be to load SharePoint Client DLLs (like Microsoft.SharePoint.Client.dll and friends) in a script. Sometimes they are loaded from a location on disk, but often they’re bundled with the script and just loaded from the execution path, which is quite convenient (when it works)!

An example of such call would be:

# This row loads SharePoint Client dll from the execution folder (if it's packaged with the script!)
$loaded = [System.Reflection.Assembly]::LoadFrom((Get-Location).Path+"\Microsoft.SharePoint.Client.dll")

And this would throw something like this:

Exception calling "LoadFrom" with "1" argument(s): "Could not load file or assembly 'file:///...\Microsoft.SharePoint.Client.dll' or one of its dependencies. ..."

The important part is actually what comes AFTER that error. See more below…


These 2 separate issues and their respective solutions are the most typical ones I’ve run into.

Solution to “An attempt was made to load a program with an incorrect format.”

This is kind of the simpler case: wrong architecture. You’re trying to load 32b files into 64b PowerShell session or vice versa.

In a case like this, the solution is fairly simple. You can’t (easily) run modules (DLLs) compiled against different architecture in PowerShell. In case the DLLs have been compiled for 64-bit architecture, you need to run 64-bit PowerShell as well.

How to test if you’re running 64-bit PowerShell:

# this'll return true or false

(this should work starting from PowerShell 3.0)

Where to find different versions of PowerShell:

  • By default, these are the installation locations:
    • 32-bit PowerShell:
      • C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
    • 64-bit PowerShell:
      • C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Solution to “Operation is not supported. (Exception from HRESULT: 0x80131515)”

Okay – so this part is a lot more complicated. Not because the error would be so obscure, but rather because there’s a bunch of possible solutions that work or do not work. The issue is typically caused by a blocked or reserved file, but determining what exactly is wrong might not be straightforward.

Start by trying if the error persists when running the console as administrator.

If that didn’t help, proceed by opening the properties of the DLLs, and checking if you can unblock them (see picture below). Then close the shell, and open it up again – this time it might work.

Unblocking a file in the properties window
Unblocking a file in the properties window

Still doesn’t work? Try restarting your PowerShell – and if even that doesn’t work, restart your laptop.

It’s weird, but this has helped multiple times! I suspect it’s a file handle being left open (from an earlier PowerShell session, maybe?), and the PowerShell instance being unable to load the file because of that. Powershell is kind of notorious for caching things very aggressively, and holding on to file handles even after the window has been closed, so sometimes a reboot might be the easiest path.


0 0 vote
Article Rating
Notify of
Inline Feedbacks
View all comments

Antti – I ran into this same issue this week but my solution was something not mentioned on your site. Since you already have a good list of potential solutions I thought this might be the best place to list yet another.

So the problem for me was that my *.dll file was included in a Git repository and was imported into a PowerShell script during a deployment process. I was using fairly generic Git settings and because of this my *.dll file was being stored in text mode instead of binary. For whatever reason this caused the file to be corrupted during deploy for one of my repositories, but not the other.

The solution was to update the .gitattributes file to add the following line – *.dll binary – and then delete the *.dll file fromthe repo, commit the change, then re-add it back in.

By doing this the *.dll file was freshly added to the repository in binary-mode where it would no longer throw the “BadImageFormatException” on import.

Hope that helps someone spend less time on it than me!

Haywood Alex

[Illegal content removed by the admin]


I’m having real issues loading a dll in a script from the local drive via Powershell – Windows protects all the system locations and this seems to prevent load e.g.

This will fail:
Add-Type -Path ‘C:\Program Files\WindowsPowerShell\Modules\MyModule\Microsoft.WindowsAPICodePack.Shell.dll’

This will work:
Add-Type -Path ‘C:\temp\MyModule\Microsoft.WindowsAPICodePack.Shell.dll’

Any suggestions?


Thanks for your reply.
I finally tracked down the error – it was my own stupidity, – the dll had a parent dependency dll whcih I wasn’t copying as I didn’t know about it – and all the error said was “Cannot find file”. Of course in my test location it was always loaded….
Once I broke out procmon to trace the erro in detail I noticed that the dll it was failing on had a differnt name and when I copied the other dll there all started working.