Failed to load the plugin 'installer_omod.dll' while start

[GF-Huang]

[Kelniimir]

Passerby here.

Updated 2.4.0->2.4.2 (rev. 2a5dd6c7). NetFrameworks installed, ndp48 couldn't install because "newer one" already installed. MO was installed in C:\ProgramFiles\MO2, therefore update was installed there as well. Issue occurred. Downloading MO 2.4.2 installer from Nexus and overwriting whilst "as admin" did not helped. Uninstalling, installing on "new" default path C:\Modding\MO2 helped (although at first launch, plugin was still making error).

It seems it worked for me...although option to enable it is greyed out.

[Paragonid]

I experienced same error on Windows 10 Mod Organizer version 2.4.2.0 portable installation in order

1. Start Mod Organizer without admin privileges --> Works as expected
2. Start Mod Organizer with admin privileges --> Works as expected
3. Start Mod Organizer without admin privileges --> Error occurs
4. Start Mod Organizer with admin privileges --> Works as expected

Suspecting file access privileges changes after starting with admin privileges for the first time causing the issue.

[Cynthius]

I experienced same error on Windows 10 Mod Organizer version 2.4.2.0 if

1. Start Mod Organizer with admin privileges

2. Start Mod Organizer without admin privileges

3. Error occurs

4. Starting Mod Organizer with admin privileges again works fine

Suspecting file access privileges changes after starting with admin privileges causing the issue.

Can confirm that launching in Admin mode resolves the issue for me too, but still throws the error any time I run without admin privileges.

[AnyOldName3]

Don't start broken software in admin mode. That's like giving a toddler who's shot you with a nerf gun an assault rifle.

As for the requires-admin-when-MO2-is-installed-to-program-files issue, it's resolved in the 2.4.3 alpha builds available from our development Discord server.

[Paragonid]

Don't start broken software in admin mode. That's like giving a toddler who's shot you with a nerf gun an assault rifle.

As for the requires-admin-when-MO2-is-installed-to-program-files issue, it's resolved in the 2.4.3 alpha builds available from our development Discord server.

Enderal doesn't start with settings like FOV from the launcher unless MO2 2.4.2.0 started with admin privileges Suggestion to run MO2 with admin privileges was posted by someone with developer tags on Enderal Steam forum.

What exactly are you calling broken software?

[AnyOldName3]

That's a different issue to this issue, but sounds like it does need fixing. I don't know if it's on our end or theirs, or whether it's just that you've not configured MO2 appropriately for when it's installed into program files. If the Enderal team are telling you to use that as a solution rather than a quick test to diagnose the problem, I'd be inclined to say the problem's on their end as it's something only a moron would suggest as a permanent solution, and morons are much more likely to write software that interacts badly with UAC.

Just in case, though, you should probably check your MO2 is set up right for being installed in Program Files (which is potentially fiddly and we explicitly recommend against putting it in Program Files). If it's in instanced mode, it's probably fine, as all the important data lives in AppData. If it's in portable mode, though, the default paths will be wrong, as portable mode expects MO2 to be put in a directory its got permission to edit, and it's not got permission to edit Program Files. You can change several of the path settings in the Paths tab of the Settings window, and make it use writable directories instead if you haven't already.

[Paragonid]

@AnyOldName3 My MO2 installation folder is non-system-disk:\Games\MO2 My Enderal installation folder is non-system-disk:\Games\SteamLibrary\steamapps\common\Enderal Special Edition So that should be out of the question. I couldn't find the post I referenced as the instruction to run MO2 with admin privileges yet, I'll post when it do

EDIT: okay, I've stated wrong. The original instruction was at https://steamcommunity.com/app/976620/discussions/0/5170673756522198880/ as

does the launcher setting for FOV work? I think the launcher checks if the ini has the same setting as in the launcher. the launcher has to be started with admin permissions

By overdev

I made an extrapolation error to run MO2 with admin privileges for the sake of having launcher started with admin privileges. Although it does fix the problem with settings in the game

Side question: so I'm most probably a moron cuz running it with admin privileges, is overdev still a moron too?

[Paragonid]

Changing 'Users' permissions to include modify and write access to MO2\ModOrganizer.ini fixed the issue, MO2 starts as expected without admin privileges

[AnyOldName3]

Their launcher shouldn't need to be started with admin permissions if none of the files it works on are restricted to admins. Do you maybe accidentally have that whole drive or at least the Games directory restricted?

[Paragonid]

have that whole drive or at least the Games directory restricted?

What do you mean by restricted? In any way, most probably not. As I've stated in reproduction steps https://github.com/ModOrganizer2/modorganizer/issues/1413#issuecomment-939510894 , the issue appears only if MO2 is started with admin privileges, it works properly until that moment.

[Arcitec]

This is the only correct person here:

Changing 'Users' permissions to include modify and write access to MO2\ModOrganizer.ini fixed the issue, MO2 starts as expected without admin privileges

Here's what to do:

• Go to the folder where you installed Mod Organizer.
• Right click that folder, and go edit the security/permissions.
• Give "Users" (regular users) "Full control" permissions, meaning write access too.

That's it. That is the issue. Mod Organizer installs itself without giving itself permission to write to its own folders. It's an easy fix which @isanae @Holt59 @Al12rs @LostDragonist can probably be integrated into the installer automatically.

The issue may perhaps only show up if people edit the default "C:\Modding\MO2" installation path. I installed mine in Program Files. And the guy I am quoting installed his in another drive.

[AnyOldName3]

Putting a portable instance in program files is absolutely not supported. There are a bazillion potential permissions issues that could cause, and working around them can introduce security holes, so we're definitely not going to meddle with permissions in Program Files.

With a normally-configured Windows machine, users should already have full control of arbitrary loose directories in the root of the boot drive (provided those directories don't have explicit protection like Program Files does), so there should be no need for the installer to explicitly set that up. Do you perhaps have a non-default setting that changes this? Is it a particularly recent Windows installation (in which case Microsoft might have changed the rules).

[MrStonedOne]

I can confirm this issue occurs on a windows machine with UAC disabled and full permissions while running under an administrator account.

Its not that.

[AnyOldName3]

I can confirm this issue occurs on a windows machine with UAC disabled and full permissions while running under an administrator account.

Its not that.

Then that's a different issue with similar symptoms, so should be tracked separately. Also, scroll up a bit so I don't need to type out the toddler-with-an-uzi analogy again, because it's already like half the posts here.

Can you open a separate issue report and include all the logs and things it suggests, please? It might also be a good idea to try both the latest release and the current beta/dev build, as I think there's some extra logging in the newer build.

[Cenness]

For a blocked file variant on windows:

File name: 'file:///[REDACTED]\mo2\plugins\data\OMODFramework.dll' --->
System.NotSupportedException: An attempt was made to load an assembly from a network location which
would have caused the assembly to be sandboxed in previous versions of the .NET Framework.
This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous.
If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch.
See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.

Solution is following:

1. start powershell
2. cd to mo2 installation folder
3. run dir -Recurse | Unblock-File

[Jownoo]

Not sure if this has already been said, but I had the same issue. Try and completely uninstall Mod Organizer, and all of the files other than the original 4 7z files for the game. Then try again but make sure you unzip the files with 7zip, not Winrar or Winzip. Hope this helps.

[8day]

Had the same issue with 2.4.4 and 2.4.0. Couldn't fix by unpacking archive anew as well as replacing existing data.

I think I might've fixed it either by doing one of these, or all of them:

• did proper installation through executable;
• installed with admin rights;
• disabled HIPS in my security suite (set it to training mode). Something similar happened before due to antivirus, so I think this one may have caused the problem.

[CritLoren]

I'm encountering this issue too on 2.5 where it looks like the problem is OMODFramework dll, which is a new addition. The system is blocking that resource by default because it came from an outside system (i'd imagine it's only really a problem with the portable version of mo2 rather than the one that has an installer) and is presumably unsigned. Getting it signed might help with Windows not marking it as insecure.

[AnyOldName3]

It's not a new addition. It's been there the whole time we've had an OMOD installer. It has been updated a couple of times, so it's possible Windows Defender has taken a dislike to a new version, but it should be more trustworthy than any of the other DLLs that come with MO2 as it comes from Nuget, which Microsoft manage, and if they didn't like it, they'd surely remove it instead of distributing it to people.

[CritLoren]

Yes I was wrong, the place of the DLL just changed. This seems to have always been an issue with the archive version, just make sure the archive is unblocked before you start unzipping it, not sure there is any other fix for this.

[jaspervanbrian]

This bug is still happening for me when trying to install the Portable Version (v2.5+) I am on Windows 11, and I am trying to install it for New Vegas (Epic Games variant).

[CritLoren]

I think the only way they can fix this is make it a self extracting archive or make the installer have a portable install option.

Before you unarchive the portable zip right click it, go to properties, and click unblock. Now you can extract mo2 and it should work fine now.

[Holt59]

I think the only way they can fix this is make it a self extracting archive or make the installer have a portable install option.

Before you unarchive the portable zip right click it, go to properties, and click unblock. Now you can extract mo2 and it should work fine now.

The installer already has a portable option. The archive has been deprecated for a long time, it's here for other tools such as Wabbajack but there is no reason to use it to install MO2 as a standard user.

[taylorjdlee]

For a blocked file variant on windows:

File name: 'file:///[REDACTED]\mo2\plugins\data\OMODFramework.dll' --->
System.NotSupportedException: An attempt was made to load an assembly from a network location which
would have caused the assembly to be sandboxed in previous versions of the .NET Framework.
This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous.
If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch.
See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.

Solution is following:

1. start powershell
2. cd to mo2 installation folder
3. run dir -Recurse | Unblock-File

Beautiful, this just worked for me! Thanks for your help!

[hughesjr]

For a blocked file variant on windows:

File name: 'file:///[REDACTED]\mo2\plugins\data\OMODFramework.dll' --->
System.NotSupportedException: An attempt was made to load an assembly from a network location which
would have caused the assembly to be sandboxed in previous versions of the .NET Framework.
This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous.
If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch.
See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.

Solution is following:

1. start powershell
2. cd to mo2 installation folder
3. run dir -Recurse | Unblock-File

Beautiful, this just worked for me! Thanks for your help!

This also worked on an install I just did to resolve the same error.

[Jake2614]

Hey so I'm mew to PC stuff but i keep getting this error and I've tried some of the solutions above but they didn't work.

[AnyOldName3]

Did you install MO2 with its installer like the instructions above said to, or with the archive, like the instructions above said not to? That error message shouldn't be possible if you used the installer.

[Jake2614]

Did you install MO2 with its installer like the instructions above said to, or with the archive, like the instructions above said not to? That error message shouldn't be possible if you used the installer.

I figured out the problem. I had failed to actually install and setup 7zip and instead extracted MO2 using WinRAR (rookie mistake) so i uninstalled 7Zip and MO2 and correctly reset up everything and it worked. It was completely user error but I am also very new to all of this.

[AnyOldName3]

That still sounds like you're using the archive instead of the installer (the installer's self-extracting, so doesn't need either of those tools), which is asking for trouble for more reasons than just this.