Jump to content

Question

Posted

So, i have MO2 installed and been trying to run Wrye's Bash from it but when i try i get a window asking if i want to overwrite a temporary file inside a folder on my "C:/Users/Username/AppData/Local/Temp". It then doesn't open at all regardless of the option selected. The BashBugDump.log ends with the line "WindowsError: [Error 32] The process cannot access the file because it is being used by another process: u'c:\\users\\tabris\\appdata\\local\\temp\\WryeBash__e61yq'" that appears to be the cause of the problem. The folder and the file, however, only are created when i run Wrye's Bash and the file is deleted after it crashes (Then when i run it again it creates another folder with another name). I have even tried reinstalling the whole thing but it didn't help.
 
I noticed that the logs tend to appear in c:\users\tabris\appdata\local\ModOrganizer\logs instead of in the folder where i installed Mod Organizer, and then tried using the default folder for the profiles (also inside /appdata/local/ModOrganizer) as i suspected that might be the cause of the problem but it also didn't fix it. Both MO2 and Wrye's Bash are outside the Program Files folder or other UAC folder (although it shouldn't matter as i have UAC turned off). Logs below (do tell me if i'm missing something):

 

BashBugDump.log: https://pastebin.com/iXsWEisp
usvfs-2017-07-03_01-36-09.log: https://pastebin.com/6V1miiGP

mo_interface.log: https://pastebin.com/B1Tu6haY

Recommended Posts

  • 0
Posted (edited)

I have exactly the same issue, upon inspection of logs and sys internals' procmon, mod explorer is redirecting the '_tempfile.tmp' to the overwrite directory but wryebash is looking for it in the original temp folder it created the file in (as far as it's concerned) and the error is thrown.

 

I'm at work at the moment so I cant provide logage, but I can say that my MO is  installed at 'c:\mo2skySE' in portable mode and wrye is installed under 'c:\motools\wrye' and steam is installed to 'c:\steam'.  So in nothing is in a UAC folder (UAC is disabled anyway).  All exe's are run as administrator.

 

At the moment I'm trying to use the python version but the install fails at installing pywin32 (download failed) trying to find a manual download of pywin32 version that works is not going well (they all keep saying python is not installed)

Edited by mscheetham
  • 0
Posted
  On 7/5/2017 at 1:45 PM, mscheetham said:

I have exactly the same issue, upon inspection of logs and sys internals' procmon, mod explorer is redirecting the '_tempfile.tmp' to the overwrite directory but wryebash is looking for it in the original temp folder it created the file in (as far as it's concerned) and the error is thrown.

 

I'm at work at the moment so I cant provide logage, but I can say that my MO is  installed at 'c:\mo2skySE' in portable mode and wrye is installed under 'c:\motools\wrye' and steam is installed to 'c:\steam'.  So in nothing is in a UAC folder (UAC is disabled anyway).  All exe's are run as administrator.

 

At the moment I'm trying to use the python version but the install fails at installing pywin32 (download failed) trying to find a manual download of pywin32 version that works is not going well (they all keep saying python is not installed)

Any luck with regards to that? Which version of Windows are you using? I was suspecting that the problem might have been caused by me using the new unstable version of Windows 10 available through Windows Insider that includes the fix for DX9 applications that use 4gb+ VRAM which is needed to use 4gb+ VRAM on Oldrim. I then found this thread here: https://forum.step-project.com/topic/12162-windows-7-update-possibly-broke-the-usvfs-proxy/

 

I'm going to try doing the same thing on my computer just in case the problem is the same.

  • 0
Posted
  On 7/5/2017 at 10:15 PM, Tabris said:

Any luck with regards to that? Which version of Windows are you using? I was suspecting that the problem might have been caused by me using the new unstable version of Windows 10 available through Windows Insider that includes the fix for DX9 applications that use 4gb+ VRAM which is needed to use 4gb+ VRAM on Oldrim. I then found this thread here: https://forum.step-project.com/topic/12162-windows-7-update-possibly-broke-the-usvfs-proxy/

 

I'm going to try doing the same thing on my computer just in case the problem is the same.

Sadly didn't work :(

  • 0
Posted

Make sure you have no other processes running that might try and access those files, specifically AV software or firewalls. Windows errors, though notoriously vague, are never wrong so there is some software trying to access that temp file or the temp folder.

Temporarily deactivate your AV and similar software and try again.

 

I have just done some tests on my setup with SSE and MO2 using both WB versions 306 & 307 with no issues. I will make this note though: it is never a good idea to run MO/MO2, or tools from within it, as admin.

Doing so may make the files you create or even the process itself unreadable by other software that is run at a user level. Only run as admin when specifically instructed to by the mod authors.

  • 0
Posted
  On 7/5/2017 at 10:51 PM, Tabris said:

Sadly didn't work :(

Nor me too, just tried it, different issue I suspect. 

 

In order to get wrye bash to work for what I want it to do (create bashed patch) I knocked up a batch script that rebuilds the skyrim install with all the mods based on the load order in MO2 it worked for me.  Takes ages on large mod setup and about as kludgy as one can get but it works for me, to create bashed patches.  To use it you will need to modify it for your own paths and it needs somewhere between the size of a skyrim install and your Mod organizer folder to run, save as anyfilename.bat it your MO mods folder, and run. 

 

Tested only on my setup USE AT OWN RISK but it is here if any one wants it:

@echo off
set _Output=c:\xeditTEMP\Skyrim Special Edition
set _SteamPath=c:\steam\steamapps\common\Skyrim Special Edition
set _ModList=..\profiles\Default\modlist.txt

echo Deleting old dir...
RD /S /Q "%_Output%"
cls
echo Ready to start.
pause

robocopy /s "%_SteamPath%" "%_Output%"

echo copying skyrim mods according to MO2 modlist order...
title copying skyrim mods according to MO2 modlist order...
md "%_Output%\dataTEMP"
::get total amount of mods
Set /a _Lines=0
For /f %%j in ('Find "%_ModList%" /v /c ^< %_ModList%') Do Set /a _Lines=%%j
SET /A XCOUNT=0
setlocal enableextensions enabledelayedexpansion

::start looping through mod folders  from modlist.txt and copy to temp folder

FOR /f "tokens=1,2* delims=+" %%G IN (%_Modlist%) DO (
    cls
    SET /A _XCOUNT+=1
    echo Copying skyrim mods according to MO2 modlist order...
    title Copying skyrim mods according to MO2 modlist order...
    echo Copying mod !_XCOUNT! of %_Lines%
    echo Copying mod "%%G"
    IF NOT "%_XCOUNT%" == "1" robocopy /s /xc /xn /xo /xx "%%G" "%_Output%\dataTEMP" >nul
)
cls
echo Copying skyrim mods to final folder...
Title Copying skyrim mods to final folder...
robocopy /MOV /S /IS "%_Output%\dataTemp" "%_Output%\data"
cls
echo All done... copying your plugins file to beth folder now
copy "..\profiles\Default\plugins.txt" "C:\Users\mark\AppData\Local\Skyrim Special Edition\plugins.txt"
pause
"C:\modOrganizerSky\tools\WBskyrim\Wrye Bash.exe" -g "Skyrim Special Edition" -o "c:\xeditTEMP\Skyrim Special Edition"
  • +1 1
  • 0
Posted
  On 7/5/2017 at 11:30 PM, GrantSP said:

Make sure you have no other processes running that might try and access those files, specifically AV software or firewalls. Windows errors, though notoriously vague, are never wrong so there is some software trying to access that temp file or the temp folder.

Temporarily deactivate your AV and similar software and try again.

 

I have just done some tests on my setup with SSE and MO2 using both WB versions 306 & 307 with no issues. I will make this note though: it is never a good idea to run MO/MO2, or tools from within it, as admin.

Doing so may make the files you create or even the process itself unreadable by other software that is run at a user level. Only run as admin when specifically instructed to by the mod authors.

Thanks for replying, I only tried running as admin when this issue arose I dont normally.

 

I don't have any AV aside for Windows 10's Windows Defender.  But as I said I ran procmon and the only applications that accessed that file are MO and Wrye Bash and I agree windows errors are reliable in most cases, however when we are dealing with sandbox enviroments hooking file operations all bets are off in that regard.  Wrye Bash works fine when running outside of MO.   I also disabled windows search after it peeked at the temp file but no joy.  I'm at a loss.

 

oh and scratch what I said earlier about redirected to overwrite it appears it also creates a temp file in data folder which is the one that was redirected not the one from temp.

  • 0
Posted
  On 7/6/2017 at 12:48 AM, mscheetham said:

Thanks for replying, I only tried running as admin when this issue arose I dont normally.

 

I don't have any AV aside for Windows 10's Windows Defender.  But as I said I ran procmon and the only applications that accessed that file are MO and Wrye Bash and I agree windows errors are reliable in most cases, however when we are dealing with sandbox enviroments hooking file operations all bets are off in that regard.  Wrye Bash works fine when running outside of MO.   I also disabled windows search after it peeked at the temp file but no joy.  I'm at a loss.

 

oh and scratch what I said earlier about redirected to overwrite it appears it also creates a temp file in data folder which is the one that was redirected not the one from temp.

I also only have Windows Defender. I tried disabling it but it didn't make any difference. I also don't run anything with admin privilege, i only tried doing it to see if it would solve the issue.

  • 0
Posted

Can all of you please do me a favour and:

  • Delete your current logs
  • Setup a profile with minimal mods, perhaps just vanilla + FNIS + one other mod
  • Run FNIS
  • Run Wrye Bash and create a bashed patch
  • Post only the "usvfs-*" log here or in PasteBin

Also let me know if anyone has Steam installed into a folder called "Program Files (x86)" regardless of the drive it is on.

Lastly advise if the WB you are using is the standalone version or not.

 

These are the things that we all are, I believe, have in common:

  • Win10
  • MO2 installed as portable
  • No AV software other than Windows Defender

That being the case there must be a commonality between you three that I am not seeing that is also different to my setup.

 

@Tabris

Your BashBugDump.log is significantly different to mine as all my logs records is "Testing UAC". This makes me believe that despite your deactivating UAC on your system it still is playing an effect on your install.

I have seen other reports of Win10 playing silly-buggers with UAC folders despite the user stating UAC was disabled. Your Steam install location includes a name that is perhaps tricking Windows into believing it is in fact inside a UAC folder.

  • 0
Posted (edited)

Okay, so, doing as you asked.

 

Windows 10, Fast Ring.

Mod Organizer 2, Portable.

Wrye Bash, Standalone.

Steam and skyrim are installed in "C:\Program Files (x86)", but MO2, Wrye bash, and other tools are not in a UAC directory.

I have BitDefender, but I have that disabled when I do mod stuff, as it often bugs out, particularly with DynDOLOD and stuff.

 

New profile

USSEP

Cutting Room Floor

FNIS

Run FNIS -> FNIS Output For Testing

Run Wrye Bash -> Won't Start, no splash screen, bombs back to MO2, Lock disappears.

Wrye Bash ini's are untouched.

 

BashBugDump.log

 

  Quote

 

testing UAC
Traceback (most recent call last):
  File "Wrye Bash Launcher.pyw", line 88, in <module>
  File "bash\bash.pyo", line 370, in main
  File "bash\env.pyo", line 563, in testUAC
  File "bash\bolt.pyo", line 897, in rmtree
  File "shutil.pyo", line 256, in rmtree
  File "shutil.pyo", line 254, in rmtree
WindowsError: [Error 32] The process cannot access the file because it is being used by another process: u'c:\\users\\xxxxxx\\appdata\\local\\temp\\WryeBash_sxmhnu'

I assume that's the log you're after?

 

Nothing is being run as admin, all as standard user (Last time I tried that with MO, I ended up with a directory  I couldn't delete, good times).

 

Thanks for taking an interest and lending a hand. Much appreciated.

Edited by shadow1
  • 0
Posted

Thanks. Actually the logs I'm looking for are from MO2 and they are named similarly to this one: usvfs-2017-07-07_23-50-55.log

 

However your BashBugDump also shows me that UAC is still an issue for some reason in your execution of WB.

See how there is a test of UAC made and then a 'tree' is removed (presumably the files/folders created in the temp folder). That's when the Windows error shows saying the process can't continue because another process is accessing the files/folders. In my educated guess the process is UAC controlling the temp folder in your %AppData%.

 

Interestingly on my system if I try and clear that temp folder the entire folder/file structure created by WB when I ran it earlier is still flagged as under control of a process despite it now being several hours since WB and MO2 were closed. Even executing an "Admin level" delete will not clear it. In my mind this an error. There should be no reason why those files are still being accessed long after the tool is closed.

 

Standby I'm going to do hard reset and see if they free up.

  • 0
Posted

Nope, even after a system restart all the files created by WB in the %AppData%\Local\temp folder are still flagged as being used.

 

Hmm... well would you believe Google Drive was stopping the process? I had that uninstalled ages ago but there still must be services running in the background. But why are they trying to backup temp folders?!

 

Anyway that was a wild goose chase as far as this problem goes... let's keep thinking.

  • 0
Posted

Okay I now have a clean temp folder and these are the folders created on running WB:

\AppData\Local\Temp\comtypes_cache\Wrye Bash-27\

 

And this is what is created after building the patch:

comtypes_cache\
WryeBash_btapp5\
WryeBash_temp\
WryeBash_temp_backup\Bashed Patch, 0.esp, Bashed Patch, 0.espf
 
On closing WB only \AppData\Local\Temp\comtypes_cache\Wrye Bash-27\ remains so the files under process that get locked are the actual bashed patch and the other temp folders.
 
Note: these are tests I'm doing outside of MO2 to ascertain exactly what files/folders the WB process creates, I'll redo these from MO2 to see what the extra layer of code does to the naming schema.
 
EDIT: No change. The random name for the fist WryeBash_ folder is different each time but nothing else significant changes.
  • 0
Posted

Hey

 

Cleared (deleted) logs, and went through the process again. This time MO crash when try to run Wrye Bash.

 

Log here: https://1drv.ms/u/s!ArVX7N5kZgaNnQrPvS8YsSI_pqqC

 

Thanks again mate.


Cleared log, run MO again.

This time just try to run wrye bash:

 

 

  Reveal hidden contents

 

  • 0
Posted

I got nothing else apart from the fact Steam is in Program Files (x86).

 

Do you have old Skyrim? If so does the same thing happen when you try to run WB on that setup?

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.