MO2 Has Problems With Malwarebytes A/V - I Know, It's A/V, Please Read Anyway :)

[Kraggy]

So I've read the info in the Github "troubleshooting" page telling you to disable A/V, but are the MO devs really not interested in trying to make MO work with such critical tools?

 

In the hope that they may at least be interested in this problem I'll post this here even though it may simply be deleted as breaking the rules. 

 

I'm using MO2 2.1.5 on Skyrim SE, and have a totally repeatable problem; the first time I run something from MO2 (usually of course SKSE) it'll work, the game will run just fine, but most of the time after the first time it won't run.  Sometimes, maybe 1 in 10 or so, it will, mostly it doesn't.

 

Exiting MO2 and re-loading doesn't work, however 100% of the time if I Quit Malwarebytes it works and carries on working.

 

Comparing the SKE64 logs for the 'good' and 'bad' cases shows no difference in SKSE64.log and SKSE64_loader.log except for process IDs, memory handles, etc., but SKSE64_steam_loader.log shows the problem.  In the 'good' case there's this:

 

 

skse64 loader 020000A0 (steam) 01D48047650F3190 6.2 (9200)

loader base addr = 00007FFA3D7A0000

exe base addr = 00007FF775F90000

found iat at 00007FF7774B3898

original thunk 00007FFA489D1000

patched iat

HookMain: thread = 12124 retaddr = 00007FF7772F2529

runtimePath = C:\Steam\steamapps\common\Skyrim Special Edition\SkyrimSE.exe

 

<snip of uninteresting stuff>

 

productVersionStr = 1.5.53.0

version = 0001000500350000

product name = TESV: Skyrim

steam exe

dll = C:\Steam\steamapps\common\Skyrim Special Edition\\skse64_1_5_53.dll

while in the 'bad' case all there is is this:

 

skse64 loader 020000A0 (steam) 01D480459EA924D2 6.2 (9200)

loader base addr = 00007FFD20410000

exe base addr = 00007FF637A70000

found iat at 00007FF638F93898

original thunk 00007FFD1A001000

patched iat

 

Clearly the A/V is causing some process hooking mechanic to fail (I'm not deep enough into process hooking to begin to know what may be going on) and it seems MO2 is exiting without any error information to go on.

 

Like I say, I know A/Vs are supposed to be disabled if they cause problems but frankly, with a tool like MO being used to run a game the MUST connect to the Internet (and of course it does so itself too) disable A/V isn't really appealing. :)

Edited November 20, 2018 by Kraggy

[Kraggy]

Forgot to say, there are no USVFS logs in MO2's log folder for the failed sessions .. also, the problem will occur running any tool, such as the Skyrim launcher directly instead of via SKSE64 so it doesn't seem to be an SKSE64 problem, even though the 'bad' SKSE log seems to show SKSE has a problem that couldn't be the case running, say, LOOT.

Edited November 20, 2018 by Kraggy

[GSDFan]

Mod Organizers program hooking is seen by all AV programs as a problem and thus they will block and even remove executables from your system as well as any script extender you have installed.

 

There are things you can do to mitigate this though. You can exclude the executables from the AV program. When you download an archive or installer, before you extract or install, right click on the download and select properties and check for the "Unblock" box. This will tell Windows you trust the download.

 

Never install Mod Organizer in the games directory. It should be installed into it own directory away from Windows UAC controlled folders, like C:\Program Files or C:\Program Files (x86), as these are UAC controlled folders.

 

Cracked versions of the game will also break the USVFS system and give varying problems that are hard to pinpoint.

[Kraggy]

I thought the hooking mechanic was likely to be the cause of the A/V taking interest, but there's no complaints from it, MO simply goes into its locked state then shortly after unlocks and the output pane shows the sub-process has ended.

 

I DID get a moan from the Acronis imaging system I use for backups, it has some kind of anti-malware in it that I wasn't aware of till now (and is now disabled) but Malwarebytes has never uttered a peep.

 

Thanks for at least letting me know this is a 'tech' issue that's likely not avoidable, I'll have to find some way of controlling the A/V when running MO.

[Greg]

The issue is that some malware is also using the hooking process to intercept Windows system calls to attempt to hide from view (e.g. intercepting file system calls so Windows Explorer can't see the malware files on disk and intercepting process calls so Task Manager can't see the malware process(es) running as well as to do really bad things) so antivirus software has taken the blind approach that hooking == malware and blocks it without notification. Windows 10 even blocks the hooking process if ModOrganizer.exe is blocked so it's not just antivirus software.

[Kraggy]

Hi Greg, I'm returning to this subject and understand about how A/V packages are very, very suspicious of programs that use hooks .. as an old mainframe O/S guy I was appalled at how PC 'operating system' allowed such exploitable mechanics to be so freely available in user-land space. :(

 

Anyhow, due to this issue I'm looking for a way to benefit from MO2's mod management (which now I've some experience of it from following videos from folks such as Gopher, GP and DWM I find so much more powerful than NMM or Vortex) while at the same time not having to disable my A/V for long periods of game-play, as well as be able to use a few tools I have I want to be able to use side-by-side, which of course MO2 doesn't allow for.

 

If I understand what MO2's VFS does for apps which run from MO2's 'Run' button, they fool the external app into thinking that there are files in the Data tree that aren't really there and fakes the O/S file APIs so that the external program thinks it's reading and writing files in the \Data tree but which are in fact elsewhere.

 

It seems to be easily seen by running, say,  Free Commander both from within MO2 and separately from it, side-by-side and comparing 'fiction' with 'reality', if you see what I mean. :)

 

So, if I were to simply drag/drop the the entire steamapps\common\Skyrim tree to, say, c:\Skyrim, would I end up with a complete 'copy' of the virtual tree which the game sees, and end up with a playable game disconnected from MO2?

 

Obviously there's the stuff in "My Games" to consider and maybe any registry entries Steam may use for its DRM garbage, but that would be easily handled by a simple batch script or somesuch.

 

It would seem to be a perfectly obvious "yes" from the theory of what the VFS does and the reality of seeing the results of the drag/drop, however, somewhere is some documentation about MO (1 or 2, I'm not sure) there's a comment which sadly I can't locate right now which says something about the .BSAs not appearing exactly the way they do to the game; I forget the context of the comment so now don't know what the issue may be.

 

Do you recognise this comment I think I read and is there an issue here in the context of what I'm trying to achieve?

 

I'd appreciate any thoughts you may have as this is something I'd really like to do if it's possible.

 

Thanks.

[Greg]

In theory you can do this, but I doubt Skyrim will work from this backup folder because of the interaction with Steam.

[Kraggy]

Well I guess that's possible, in which case I'd use the method Vortex uses to deploy mods, I'd use a Hard Link to 'point' steamapps\common\skyrim to the new tree's location or the 'real' one used by MO, which I see must work as Steam would be none the wiser.

 

Thanks for confirming that in theory the tree resulting from this copy is going to be intact as far as the game itself is concerned.