GrantSP

Despite what your detective skills may have told you, you're not the first to see this behaviour. In fact it is listed in the STEP guide and has nothing to do with permissions or admin rights. What you have described are two related, but different, phenomena. Firstly MO failed to delete the folder because another process was actively controlling it. Nothing to worry about here as this will have no bearing on your game. Secondly the plugins were found in the original folder and not MO's 'Overwrite' due to MO's rule of thumb: "If the file exists, edit it. If it is new place it in the 'Overwrite'." As for WB or FNIS and their produced files, the rule still applies and you should see no issue with those. If you want to examine the plugins in LOOT it will report if they are the cleaned ones or the original. Reacquiring the files from Steam and redoing the process may also alleviate any concerns you have.

Nothing wrong with the installation files. I would advise you check your system to see if there is any software that is interfering with the connections. Firewalls, anti-virus or malware software may be stopping the connection from taking place. You may also have a poor internet connection and it is timing out before the connection is complete.

Has anyone actually succeeded in getting past the login screen for this? I keep getting a "Sign in is currently unavailable. Please try again later.' message. I too have been wary of EA games but you can't pass up a freebie.

Yep.

My apologies. I just moved it here as it is the most used FO4 guide that has that mod in its load order.

If you feel the existing bashed patch is broken, just overwrite that or delete it and copy in a new blank template and work on that. My install may be the same as yours and if so just deleting the existing will not be enough, you will have to provide WB with a blank template to work on, also mine gets saved into the original file and never goes into 'Overwrite', this is due to a number of factors but the 'rule of thumb' works here: if a file exists in the MO VFS, edit that. If it doesn't exist but can be created, place it in 'Overwrite'. Since I know of no way for WB to create a blank bashed patch you will need to provide it with one. As for the reasons why your game is crashing there could be many reasons. Since deactivating the bashed patch fixes it, then your bashed patch disables a master plugin that needs to be restored and you haven't done so. Checking the save in MO may show which missing masters are the culprits and you can try and deduce why your bashed patch is doing what it isn't. TL;DR: Missing master are the first cause of CTDs you should look for.

I think you may have better success by asking @Sharlikran either on his WB repo or on the Bethesda forums. Since he's taken over the role of WB guru he probably knows more about this sort of code than anyone else.

No. However since the code that handles the paths will be using Windows base functions I don't think that will make a change. The only time spaces should be a concern is when you are adding arguments to the commandline, then you'll need to enclose them in quotations.

Many YouTubers fail to realise the need to avoid UAC folders, so if the video showed MO being installed where you now have it, then yes it didn't help. MO & MO2 are both 'portable' executables meaning they do not make use of the registry to store settings. All the necessary files are simple text files that can be edited by anyone making it one of the easier managers to use. However as the functionality of MO/MO2 uses a 'hooking' mechanism to attach to processes in memory, it is viewed by Windows with extra scutiny as malware uses a similar method. This is the reason most issues arise, we are trying to trick processes in memory to "see" things in locations that they don't exist in. For now could you create a new blank profile with no mods installed and see if you can past the main menu? If you can then we may have been looking at MO2 when in fact it may be a conflict with a mod. This is a last measure on my part as I have little left to offer without delving into dumpfiles and the source code, something that will need a refresher on my part, C++ is very rusty for me.

I've located and added to both the FO3 and FNV guides additional download links.

Aside from the fact I don't have Fallout 4, which is what your INI is currently geared for, mine is almost identical to yours. The only thing I see in yours is Fallout 4 is in a UAC folder. I have never viewed running MO/MO2, and any tools called from it, as admin as a good idea. The problem that brings is when you call one tool with that access and then another lacks it and permissions become a problem. Whenever mod authors call for running as admin I invariably try without it first to see if issues arise. The only time I can recall I had to do so was with the new FNV 4Gb patch.

I'm currently using the latest 307 version of WB but I just tested all the compatible games with v306 and it too works flawlessly, I can only surmise that the settings you are using are different to mine. Though looking at @Stryfe's files they look like a similar setup to mine so I'm not sure. I'm on Windows10 Anniversary edition running as a user with no admin rights and all my tools are under a non-UAC folder structure. My Steam location is likewise on a dedicated drive, D:, and not under UAC issues. Only using Windows Defender as my AV and I have not had to add anything as an exception.

Examine your AV software and add MO2 to the exclusions list. If the processes are being flagged by the AV, the file access to 'Overwrite' is often the first to go and files end up in the wrong locations. Then if the tool called can't see what it expects to see, where it expects it to see it, it will most likely crash.

Your log finishes with this: 20:17:02.682 <13232:16348> [E] Crash dump created as "C:\Users\Matthewhrc\AppData\Local\usvfs\uvsfs_x64.dmp". Please send this file to the developerThis is something I am not able to assist with as I am not the developer, unfortunately the developer, @Tannin, has now moved on to working on Nexus' next manager and I'm not sure if the current support crew is able to assist with this as it involves delving into the source code to check for clues that that dumpfile may contain. I will suggest one thing though. You have Steam and MO2 installed under a UAC folder: C:\Program Files (x86)\ , if at all possible I would urge you to move them away from any folder that Windows considers 'vital', such as that one, and see if you are able to proceed. UAC issues are one of the biggest hindrances to smooth MO2 usage we encounter.

Nothing in your description says MO is the cause of anything. Once the game starts, MO has passed on ALL execution to the executable and has NO bearing on in game performance whatsoever. I'd would investigate your INI settings instead.

That's fine. The Project Nevada team created the menu item before they realised they wouldn't be able to complete the entire section. Disregard it, it causes no issues and is not a sign of a broken install.

Hmm... looks like @Darn has let his ownership of that domain lapse. This affects the Fallout 3 DarnUI also, we may have to investigate if hosting those files ourselves violates anything and then see what we can do to rectify this.

I see nothing obviously wrong with your logs. From what they are saying MO2 is working fine and WB is correctly called. Perhaps you can detail, in a new thread, exactly what is happening. However I will offer these general suggestions. You have both MO2 and WB installed as sub-directories below your Steam install. Try and install them into their own folders away from Steam. I use this: D:\Games\ModOrganizer2 & D:\Utils\WryeBash In that last folder is contained everything that is in the "Mopy" folder of the WB archive.

MO2 can be used for Skyrim and SkyrimSE but you need to change the instance via the game selector button, as described. Therefore ALL tools used for each game need to be called from the corresponding instance. You were calling WB to manage Skyrim from within an instance of MO2 for SkyrimSE. Change the instance of MO2 first then call WB from that instance. Treat Skyrim and SkyrimSE as completely different games in the same way you would for Skyrim and Fallout 3 or Fallout New Vegas etc.

@screwyou00 Your problem is not with MO2 or WB, it is because you are trying to run WB for Skyrim from an instance of MO2 set for SkyrimSE! You need to switch MO2 from Skyrim or SkyrimSE by using the game selection dialogue on the far left of MO2's toolbar. @tjax323 If your logs are too big you can either host them on PasteBin or archive them and post the links to the zip file here. You also need not worry about losing anything with those files, there are just logs and can safely be deleted after each run if you want. The geometry section is not crucial, I just noticed some oddities in your logs. If you see no issues with the UI don't worry about it.

Did you try and start Skyrim and load the game? The usvfs seems to indicate otherwise. Perhaps I didn't explain that that step was needed, in which case I apologise. Could you try again and then post the last log.

@screwyou00 From what I see in your logs it looks like it may be down to UAC issues, likely caused by your installation of WB into the Program Files (x86) folder. STEP in general, and MO in particular, recommends installing all tools outside of Windows UAC folders like those. Try removing your existing WB install and place it into a folder all its own. I have a D:\Games\Utils\ folder in which I place my other tools such as WB or xEdit. @tjax323 You needn't worry about your details too much, firstly your password is saved in the INI in an encrypted state so unless someone wants to force break it open it isn't exposed, secondly you can simply delete that line after you paste it into the webpage. Now, unrelated to WB, but you seem to have Qt issues with some UI elements in MO2, try deleting everything inside the [Geometry] section of your INI and then start MO2 again to see if it is corrected. The file: usvfs-2017-01-02_22-27-54.log is actually the most important one for me here as it details what is, or isn't loading.

The scariest part about those numbers is the amount of users that don't use, or think they need, compatibility patches. As for surveys, if seen a few Google surveys to say they will probably be more than sufficient for these purposes.

If you are trying to play the original Skyrim then use MO version 1.3.11 from Nexus, not MO2.

Delete them all and run MO again and then paste the contents here. There should only be two this time, mo_interface.log & usvfs-<%date-time-stamp%>.log