search

ModOrganizer2 / modorganizer

Mod manager for various PC games. Discord Server: https://discord.gg/ewUVAqyrQX if you would like to be more involved
http://www.nexusmods.com/skyrimspecialedition/mods/6194
GNU General Public License v3.0
2.07k stars 155 forks source link

WB fails to complete on v2.1.1 #189

Closed TechAngel85 closed 6 years ago

TechAngel85 commented 6 years ago

The problem

The current version of WB for SE, when ran through the v2.1.1 of MO, hangs and stops responding during the process of rebuilding the Bashed Patch.

Environment

Details

Have the latest of both managers installed. (I have a good size mod list) Run WB through MO2. Rebuild the Bashed Patch. It hangs.

Link to Mod Organizer logs

USVFS

I shorted the log. https://pastebin.com/XkcUQPna

MO Interface

https://pastebin.com/6xA5yuiW

erasmux commented 6 years ago

Can you please generate a dump file of the hung process. You can use task manager or process explorer for this (right click the process). I suggest compressing the dump for easier upload.

TechAngel85 commented 6 years ago

Here's the dump: https://mega.nz/#!d1NDmZbL!ofU5yaxbx8rAQIPxRuXK-5yJC3dbYWJ6VUJpObT7ymA

I tried the Beta 1 version of WB and it hung on moving the files, but still completed the process. In Beta 2 they've changed some things revolving around the Batched Patch.

TechAngel85 commented 6 years ago

Upon further investigation, it seems the Bashed Patch is being created, the program is just hanging in MO, though, so there is no indication that it's completing its job. The Bashed Patch is being placed directly into the game's Data folder instead of into Overwrite. Inspection of the Bashed Patch looks good. Seems it's the the process getting hung up somewhere.

erasmux commented 6 years ago

That dump you attached most likely indicates a problem with usvfs (the injection part of MO). It already has a small lead I will look into. I am currently working on a usvfs version with many fixes and would like to first finish that. Since none of those fixes seem directly related to this issue, there is a good chance the issue will persist. In such a case, if possible, I would like to work with you and investigate and solve the issue. First lets wait and see what happens with this new usvfs version.

TechAngel85 commented 6 years ago

Okay, thanks. I'm following this issue so let me know if you need anything.

erasmux commented 6 years ago

Retest with the usvfs 0.3 beta available on the discord channel (link on main github page). If the problem persists let me know (preferably also on the discord channel).

TechAngel85 commented 6 years ago

Sorry it took be a while to get to this. WB is still freezing with the Beta5 that is on the channel. Here's the new dump: https://mega.nz/#!cts3zRiY!wewz9W5U8bCcjS3syBxSclYYij2jWb1DX84iJB4_u6w

I'd also like to note that it's putting the Bashed Patch plugin directly into the Data folder instead of in Overwrite.

erasmux commented 6 years ago

First, regarding the Bashed Patch location, if the Bashed Patched already exists in the Data folder it will be updated there. If you wish it to be placed in a mod, create a mod with it and it will be updated in that mod. Finally if the Bashed Patch file does not exist at all, it will be created in the overwrite folder.

Regarding the WB freeze, this is not the same issue as before. Before the dump showed that usvfs is directly responsible and that bug has (hopefully) been fixed. Now the freeze "apparently" has nothing to do with MO/usvfs. Although, it could still be caused indirectly by usvfs but without further information there is not much I can do about that.

If you would like to further pursue the issue, it would greatly help if I could reproduce the issue on my machine. To that end I suggest the following:

  1. Extract the latest MO dev release to a new empty directory with a short path and no spaces (i.e. C:\MOTest). For now the "latest MO dev release" is the MO 2.1.1 Standalone from nexus + the usvfs 0.3.1 beta5 from discord but I intended to release a new one soon.
  2. Run MO and select portable install, change the log level to the maximum level ("debug" with MO 2.1.1 but might change for newer versions see release notes).
  3. Without installing any mods and without changing any other settings, reproduce the issue.

If the issue reproduces this way, please upload a dump file and usvfs log generated together by this case (you should compress them for easier upload/download). Also please detail exactly how you reproduced the issue (i.e. run WB from MO, press button A, button B and then when I press button C it freezes).

If the issue does not reproduce this way, please try and find the minimal steps from this clean install which can cause WB to freeze and gather all the above (matching dump + log) and detail all the steps necessary to reproduce the issue from a totally clean install.

TechAngel85 commented 6 years ago

Patch is built successfully under this scenario, however, the Patch is still put directly into the Data folder (when one does not exist in it prior to building...I checked before building). I have had other users report to me (on my guide hosted on STEP) that it's putting it directly into the Data folder for them, as well.

I retested on my full installation and it's now being completed successfully so it looks like a complete reinstalled of WB fixed it. However, even on my full installation the Patch is still placed directly into the Data folder when it doesn't exist. Here are my logs: https://mega.nz/#!AkVBwIAA!9mcAytCzUbkJwe28jeu75QCgGft9X9LTni85dVnZKKY

erasmux commented 6 years ago

Those logs look very wrong (both because you did not follow my instructions and at the very least the log level has not been set to debug and because the single relevant print they have, should not be happening but if it is shows the file is mapped to the right location - so basically nothing makes sense and in more ways then one).

The main thing I asked for is exact instructions on how to reproduce the issue (think instructions for a robot, starting with an empty folder and until the issue reproduces, detailing every single action you take). Clearly you and the other users on STEP are doing something different as it works fine both for me and the other users on the discord channel. I doubt we will be able to get down to bottom of this unless you or possibly someone else which is willing to be more pedantic about instructions can help me reproduce the issue or investigate the issue by following instructions to the letter.

Just to be clear, I am not saying it is not a usvfs bug. In fact if I knew for sure this was not a usvfs bug I wouldn't waste my time on this at all. I do want to investigate this, but I need some pedantic cooperation for this. I did attempt to reproduce the issue myself and I did ask around the discord (well I actually had the bashed patch generated in the Data folder at first because I ran WB outside of MO and didn't notice it put an empty bashed patch file there, so I was asking for myself but its the exact same issue...).

If someone is still having the WB hang issue and is willing to cooperate with me please have him contact me on the discord channel (if it happens with MO and doesn't happen without MO there is a good chance this is a usvfs issue, even if reinstallation of WB or whatever works around it maybe temporarily and maybe not).

dragonshardz commented 6 years ago

Per instructions, starting from a clean installation of MO2 and an installation of the latest version of Wrye Bash (307 Beta 2) and with MO2's log level set to debug:

  1. Launch MO2 by double-clicking on the .exe in Windows Explorer. MO2 is installed in F:\MO2-2.1.2dev6-Silarn-prerelease for the purposes of this test.
  2. Click on the Configure executables button
  3. Enter Wrye Bash in the Title field
  4. Click on the "..." button next to the Binary field and browse to where Wrye Bash is installed. For me, this is F:/Steam/SteamApps/common/Fallout 4/Mopy
  5. Select Wrye Bash.exe in the Select binary dialog and click Open
  6. Click Add in the Modify Executables window.
  7. In the dropdown next to Run, select the Wrye Bash entry.
  8. Click Run. MO2 locks.
  9. A Windows error dialog appears: https://i.imgur.com/VxaH2vM.png
  10. Clicking on Try Again makes the error reappear.
  11. Clicking on Cancel closes the error.
  12. A second error message appears, this time from Wrye Bash: https://i.imgur.com/V9O6avF.png
  13. Unsurprisingly, clicking on the only available option to Quit closes Wrye Bash out and unlocks MO2.
  14. Note that a file named _tempfile.tmp with a size of 0 bytes is now present in the /overwrite/ folder.
  15. Close MO2 by clicking the X button in the upper-right corner so that logs write.

Logs are attached: mo_interface.log usvfs-2018-04-02_09-53-01.log

Silarn commented 6 years ago

We worked through this in discord and either there was an old process still running causing problems or an existing directory had a permissions conflict. This problem appears to be resolved.

Silarn commented 6 years ago

Sorry, there was a bug in our fix. Please see the still-open WB ticket as I believe it is the same issue with custom Temp directories.