PowerShell not loading them DLLs

How to resolve issues when loading DLLs in PowerShell?

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…

Solutions

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
[Environment]::Is64BitProcess

(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.

References

Antti K. Koskela

Antti Koskela is a proud digital native nomadic millennial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as a Solutions Architect for Valo Intranet, the product that will make you fall in love with your intranet. Working with the global partner network, he's responsible for the success of Valo deployments happening all around the world.

He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff.

This is his personal professional (e.g. professional, but definitely personal) blog.
mm

4
Leave a Reply

avatar
5000
2 Comment threads
2 Thread replies
3 Followers
 
Most reacted comment
Hottest comment thread
3 Comment authors
Haywood AlexmmNick Recent comment authors
  Subscribe  
newest oldest most voted
Notify of
Nick
Guest
Nick

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
Guest

[Illegal content removed by the admin]