Wrye-bash: Improper INI unicode handling causes crash

[StormDancer46]

I am running Windows 10 with UAC disabled and I recently tried opening Wrye Bash (Oblivion Standalone version 307.201807040057) and received this error message:

Wrye Bash encountered an error.
Please post the information below to the official thread at:
https://afkmods.com/index.php?/topic/4966-wrye-bash-all-games/& or
https://bethesda.net/community/topic/38798/relz-wrye-bash-oblivion-skyrim-skyrim-se-fallout-4/

Traceback (most recent call last):
File "bash\bash.pyo", line 227, in main
File "bash\bash.pyo", line 393, in _main
File "bash\basher__init__.pyo", line 3981, in Init
File "bash\basher__init__.pyo", line 4024, in InitData
File "bash\bosh__init__.pyo", line 1617, in refresh
File "bash\bosh__init__.pyo", line 1594, in _refresh_infos
File "bash\bosh__init__.pyo", line 1490, in ini_info_factory
File "bash\bosh\ini_files.pyo", line 63, in formatMatch
UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 0: ordinal not in range(128)

Wrye Bash was functioning fine and this error appeared out of no where. It has happened before and the only resolution was to reinstall Oblivion entirely.

LoadOrder_Oblivion_2018-11-04T14-46-14.txt
NOTE: I tried reinstalling Wrye Bash which is why the Bashed Patch is missing from the load order

[Utumno]

Did you post at the forums? Post there - the last nightly build should not have this bug

[deanec64]

similar error. and why must I post in a forum?

Wrye Bash encountered an error.
Please post the information below to the official thread at:
https://afkmods.com/index.php?/topic/4966-wrye-bash-all-games/& or
https://bethesda.net/community/topic/38798/relz-wrye-bash-oblivion-skyrim-skyrim-se-fallout-4/

Traceback (most recent call last):
  File "bash\bash.pyo", line 227, in main
  File "bash\bash.pyo", line 393, in _main
  File "bash\basher\__init__.pyo", line 3986, in Init
  File "bash\basher\__init__.pyo", line 3645, in __init__
  File "bash\basher\__init__.pyo", line 3418, in __init__
  File "bash\basher\__init__.pyo", line 1734, in __init__
  File "bash\basher\__init__.pyo", line 251, in __init__
  File "bash\basher\__init__.pyo", line 212, in __init__
  File "bash\balt.pyo", line 1702, in __init__
  File "bash\balt.pyo", line 1815, in PopulateItems
  File "bash\balt.pyo", line 1760, in PopulateItem
  File "bash\basher\__init__.pyo", line 760, in <lambda>
  File "bash\bolt.pyo", line 188, in formatDate
  File "bash\bolt.pyo", line 124, in decode
LookupError: unknown encoding: cp65001

[Utumno]

similar error. and why must I post in a forum?

Because you are requested to do so by the developers of the _free_ application you are using.

As I said this is fixed in latest nightly

[MilesBHuff]

I'm having the same issue as @deanec64 (the cp65001 one). I believe it's happening because I set my system codepage to Unicode. Glad to hear it should be fixed now.

[Utumno]

I'm having the same issue. I believe it's the result of setting your system to unicode. Glad to hear it should be fixed now.

Try the last nightly from https://afkmods.com/index.php?/topic/4966-wrye-bash-all-games/&do=findComment&comment=166863

[MilesBHuff]

Thanks. I tried it (EDIT: I actually tried the bleeding-edge Python release, not the standalone.), but I can't get it to work either, albeit for a different reason.

Thankfully, though, someone the forums, someone posted a standalone version that works on my computer. Any chance you could release it as the fourth beta for this version? It's been about six months since beta3, iirc.
Here's the link to the post: https://afkmods.com/index.php?/topic/4966-wrye-bash-all-games/&do=findComment&comment=174625

[Utumno]

That someone is me :P - can you please post me the error you are getting with the standalone on the second post? It's important I see that

[Utumno]

Please run bash with debug options i need to see the full bugdump - see reporting a bug wiki here

[MilesBHuff]

Oh, sure. It's technically a different cause than the one in the OP for this thread, though.

---

No matter which version of Wrye Bash I use, I always get only the following output:

fail bash\windows.py
testing UAC

And then nothing happens. There is no other information. Running it in debug mode outputs exactly the same thing, and nothing else. The bugdump is empty.
I spent 6-8 hours messing with this. It's quite frustrating. I did install the correct dependencies, and the directory in which Wrye Bash resides is not protected by UAC.
Here's the output of pip list:

Package    Version
---------- -------
comtypes   0.6.4
pip        18.1
pywin32    220
scandir    1.6
setuptools 40.6.3

And I made sure to install the exact wxPython that was linked to in the readme.
My comtypes is 0.0.2 versions higher than the reference comtypes. I've tried other versions as well, but I get the same result. I stuck with this one, since I can pip install it.

[Utumno]

Ahem - bugdump?

[MilesBHuff]

Empty, as I mentioned above.

If this were easily debuggable with the given tools, I'd've done it by now. While I'm not a Python dev, I do write JavaScript 40 hours a week and bash the rest of the time, so if you need me to try anything techy, it's not a problem.

[Utumno]

But since you see the testing UAC the process must have reached that point - and the bug dump should have beed generated - do you start with the correct options (-d)

If you do not manage to produce bugdump then you should provide the info manually - OS etc - see the reporting a bug

That's worrying the version in the second post should just work

[Utumno]

I am afraid that it's the commtypes however - it's the python version that fails right? the standalone should not be affected by your python environment

[MilesBHuff]

I just uninstalled and reinstalled everything, using exactly the versions linked to by the readme, with the only exception being that I'm using Python 2.7.15 instead of Python 2.7.12.
Good news, but still mostly bad: The fail bash\windows.py no longer appears in stdout/stderr -- it's just the testing UAC, and nothing else. It still won't actually, start, though, and BashBugDump.log is still empty. To debug, I run Wrye Bash Debug.bat in a terminal; this script calls Wrye Bash Launcher.pyw with the -d flag.
So it would seem that perhaps 1.6.4 of comtypes was an issue; but it also might have been some other quirk of my previous setup.
It can't be a UAC issue, since I made sure to give myself full permissions over everything in the Wrye Bash folder. Plus, it's on a second harddrive, anyway. And running it as admin doesn't make a difference.

And yes, the new standalone works.

[Utumno]

Ok so the new standalone is the one from the second post or the one I posted recently? I would like to get to the bottom of this mystery - do you use wx 2.8?

[MilesBHuff]

The standalone is the one in the post I linked to earlier. Here's a direct link: https://www.dropbox.com/s/ewr6vxwhgq0zhpv/Wrye%20Bash%20307.201812190031%20-%20Standalone%20Executable.7z?dl=0
It appears to have been compiled yesterday, so very hot code.

I do use wx 2.8. Here are the names of the installers I used, in the order that I used them:

• python-2.7.15.msi (to C:\ProgramData\Python2 (Maybe that's the issue? Is something hardcoded to expect C:\Python27?))
• wxPython2.8-win32-unicode-2.8.12.1-py27.exe
• pywin32-220.win32-py2.7.exe
• comtypes-0.6.2.win32.exe
• scandir-1.6-cp27-cp27m-win32.whl (installed with pip)

Earlier, I also tried using virtualenv, but it was the same result.

I'm going to try sticking a symlink at C:\Python27.
Update: No luck.

Is wxPython supposed to show up in pip list? Because it's never shown up in pip with version 2.8, that I can remember.

And restarting my computer didn't fix anything.

[MilesBHuff]

I read back through this discussion, and noticed a minor misunderstanding (my fault) near the beginning. I hope this will clear it up:

When you sent me that link to a nightly earlier, I downloaded the bleeding-edge Python code. I just went back to it and noticed that there was also a standalone, dating back to July.

The standalone I've been using is a different one, and was also posted by you; it dates back to this month.
I've been using the December standalone.

With the exception of the initial bug (the cp65001 issue with beta3), all of my problems have been with the Python version.

[Sharlikran]

Multiple users using your official code have reported that the issue with cp65001 is not resolved.

[MilesBHuff]

It would be nice if official releases came more often, for sure. It would have saved me a lot of time.
Here's the link for the December version again: https://www.dropbox.com/s/ewr6vxwhgq0zhpv/Wrye%20Bash%20307.201812190031%20-%20Standalone%20Executable.7z
It's fixed in this one.

[Utumno]

Multiple users using your official code have reported that the issue with cp65001 is not resolved.

What is my official code? The standalone from July ? This should solve this particular one - in fact formatMatch is not there anymore

@MilesBHuff: do you have multiple python versions on your system?

[Utumno]

It would be nice if official releases came more often, for sure

Well, we need more volunteers to do this - preferably python coders but also testers and user support.

[Utumno]

@MilesBHuff: do you have multiple python versions on your system? I kind of suspect that you run this with another python version - could you try running the launcher directly as in:

C:\path\to\Mopy>c:\path\to\Python27\python.exe "Wrye Bash Launcher.pyw" -d

[MilesBHuff]

While I do have multiple versions of Python installed (I also have v3), I put python2 higher on the PATH. I've also already tried running it directly like that, but I've done it again, just in case. Same effect as usual. If I do run it with python3, I get a syntax error, as you'd expect.

[Utumno]

Thanks @MilesBHuff - when I get round to it I will add some debug prints - we explicitly worked on eliminating CTDs so this is a head scratcher for me

[MilesBHuff]

No worries! Just let me know when, and I'll give it a go. Thanks!

[Utumno]

OP was addressed in bb6c8bd2e7ac22d1218cbad90e404b9739dba7bc (probably e5c16790d78cf6fc12395adb40027be5df3ed7d0 )