Jump to content
  • 0

Windows 7 Update possibly broke the USVFS Proxy


CGi

Question

As the title says: After installing the latest Windows updates, the VFS proxy that's used for tools like xEdit and the like stopped working.
The updates i suspect - and can't simply uninstall - seem to be KB4019264 and/or KB4019112.

Everything worked fine before those updates so i suspect those because it's the only change that happened.

Launching the game or the games launcher still works perfect as in those cases the proxy is not used.

Tryed to see what's going on but the USVFS logs are always empty. The proxy just quits with exit code 1 which should be a general error like devide by zero and so on, so no clue there.
The proxy itself has no output at all, so no clue from this side either, so i checked if the correct PiD and TiD is targetted and those are correct as well.

Wrote a tool to check for this stuff. Here it's log:

 

Parameter:
==========
--instance mod_organizer_instance --pid 4028 --tid 4476
 
instance:
=========
 mod_organizer_instance
 
Target Process:
===============
 PiD: 4028 = FO4Edit.exe
 TiD: 4476 = FO4Edit.exe [PiD:4028]
 
USVFS-Proxy Result:
===================
 Exit Code  : 1
 Description: General Error
 Output     : N/A

 

 

 
i'm out of ideas what to do now, because - as already mentioned - i can't just uninstall those updates.
 
 
P.s.: The install location of MO2 and the Tools is a non-UAC monitored drive & folder and MO2 as well as all tools are launched with administrator privileges.
Edited by CGi
Link to comment
Share on other sites

10 answers to this question

Recommended Posts

  • 0

 

... Launching the game or the games launcher still works perfect as in those cases the proxy is not used...

 

This is incorrect. The code used to launch the game is exactly the same as that to run tools. Do the tools run outside of MO2?

Link to comment
Share on other sites

  • 0

Yes, the tools run outside of MO and even pickup manually installed plugins.

And no, the proxy is not used for FO4Edit, xTranslator, BodySlide or Loot (those are the tools i try to run). i replaced the EXE of the Proxy to see if it fires (it at least creates a log if it was stopped before it shows it's GUi) and so far it was only used for those tools.

i even tested Explorer and MO detects that it is Explorer and injects the DLL directly, not using the proxy (Explorer ofc crashed with a memory exception).

 

 

So far i replaced the proxy with my own version that creates SymLinks based on the mod order in MO and got my tools working this way and as launching the game does not call the Proxy executable no SymLinks are created making it perfectly safe to use ... so far.

Edited by CGi
Link to comment
Share on other sites

  • 0

My iNi's are fine. The Proxy stopped working after i updated Windows and the logs of the Proxy are empty, meaning it encounters an error before it even start logging dgb infos.

Edited by CGi
Link to comment
Share on other sites

  • 0

I don't use Win7 so I can not be categorical in my assessment but since no one else on Win7 has posted anything about this, and the updates you linked to would have no bearing that I can see, it looks to me like some other issue(s) is/are at play.

 

Since you aren't providing anything else to work with you'll be left on your own. However since you've circumvented the system by using symlinks the entire question is now moot.

Hope you get the answer you're looking for somewhere and you can continue to play the game.

Link to comment
Share on other sites

  • 0

So i downloaded the USVFS source and noticed the Proxy is only used for x86 applications because it does not handle usvfs_x64.dll.

 

i managed to create a memory dump that points to a stack error in ntdll.dll that is not caused by the proxy but by usvfs_x86.dll itself hence the generic exit code from the proxy.

if anyone has already read into the code, any help is appriciated.

Link to comment
Share on other sites

  • 0

it's not about 64bit aplications, it's about the 32bit applications.

Maybe my english is not the best, but i'm sure i brought across that i worked on the 32bit VFS DLL.

Link to comment
Share on other sites

  • 0

Ok... i figured it out. The updates where the reason. They damaged the side-by-side config.
Had to extend the error handling of the 32bit VFS DLL but else i would have never guessed that this is the reason.

 

if anyone else runs into this problem and can't be arsed to repair the SxS config painstakingly manualy: Just uninstall (yes, do this beforehand) and reinstall the VC++ runtimes.

Their installers scan for SxS errors and fix them when possible. in this case they could fix it, so it was the easiest solution for me as they go thru all configs automaticly.

Anyhow: Problem solved, everything working normal again and i can get rid of my SymLink solution.

 

Thanks for trying to help me out GrantSP, but we both searched in the wrong location for the reason and solution. Cheers!

Edited by CGi
Link to comment
Share on other sites

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.