Jump to content


  • Content Count

  • Joined

  • Last visited

About Joat_Mon

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Joat_Mon

    Windows 10

    A lot of customization replaced by what MS thinks I need. No easy roll back to 1709. Half a dozen machines so far and it appears that past USB problems are fixed.
  2. Joat_Mon

    Wrye Bash - All Games

    I tried it out, unpacked SRO, seemed to go okay, took ~7 minutes. When I tried to repack I got an error (see attached screen shot). Trying to pack SRO again now without restarting WB, it is taking a long time but Process Explorer shows me that it is "doing it's thing". I will let it run for awhile and let you know what happens. Update: It did finish packing after ~40 minutes.
  3. Joat_Mon

    InSpectre - New Steve Gibson utility

    MS has rolled out KB 4058258, 2018-01 Cumulative Update for Windows 10 Version 1709 (loading it up now). I seem to have gotten all updates through out this debacle, without issue, on all my computers, core i7 1st, 3rd and 4th gen as well as core2quad, despite having MalwareBytes free on all of them.
  4. Joat_Mon

    7-Zip Security Update

    You may want to up date 7-Zip ASAP, see article: https://www.computerworld.com/article/3252031/microsoft-windows/multiple-vulnerabilities-in-7-zip-get-it-updated-now.html
  5. Joat_Mon

    Wrye Bash - All Games

    This fits in with one aspect of the crashes that I observed when resizing the icons. I can have Pythonw (Wrye Bash) set up to crash most of the time (95%+) or not crash most of the time (95%+) or randomly crash. I can toggle between crashing most of the time and not crashing most of the time by doing the following: In the installer tab, right click on the columns header and select "Full Refresh" from the drop down menu. So far this works every time. If its crashing it changes to not crashing. It its not crashing it changes to crashing. To be correct Pythonw does not actually crash. The process is suspended by MS Windows and can't be restarted without choosing to close the program, which is the only option available from the dialogue box that Windows pops on screen.
  6. Joat_Mon

    Wrye Bash - All Games

    I am running AMD graphics on my two test machines. 2560 x 1440 and 2560 x 1600 I do have two nVidia graphics equipped machines but I don't usually game on them.
  7. Joat_Mon

    Wrye Bash - All Games

    I'm not running in compat mode on either of my test set ups. I have accumulated a lot of info over the past several weeks of testing. I don't really know what to do with it. I have consistent crash on icon resize with certain combinations of set up and inconsistent crash with other set ups. I'm leaning toward a combo of MS ASLR, MS DEP and Fault Tolerant Heap interaction as a significant part of the problem for the inconsistent crashing. I'm leaning toward memory call or write to disk surrounding the .dat files as the cause of the consistent crash and as a catalyst for the inconsistent crashing.
  8. Joat_Mon

    Wrye Bash - All Games

    I have worked on this since my last report. The machine I reported about, i7 4770k, 32Gb, one SSD for OS, one SSD for game, one HDD for data, SkyrimSE, did not yield consistent enough result for a sane analysis. So I resurrected my gaming machine, i7 3930k (rest hdwe. same as other machine) which had Win 7U, Wrye Bash (306) and Skyrim installed and did not crash when the status bar icons were resized. I nuked the OS on the gaming rig and wiped the other drives, then installed Win 10P 1709 16299.125 from a new image downloaded from MS. Have reinstalled Steam, SkyrimSE, Wrye Bash (latest Utumno wip python version) and a lot of other stuff. At first the status bar icons resized without crashing Wrye Bash. It wasn't until I populated the bash installer directory with 75 to 80 mods and started running wizards that the status bar started to crash Wrye Bash when the icons were resized. No mods were actually installed. The failure mode on the 3930k machine is very consistent. The event viewer shows the following Faulting application name: pythonw.exe, version:, time stamp: 0x59bd8782 Faulting module name: ntdll.dll, version: 10.0.16299.64, time stamp: 0xac8afc81 Exception code: 0xc0000005 Fault offset: 0x0002cfd6 Faulting process id: 0x13c0 Faulting application start time: 0x01d38574035b3cc1 Faulting application path: C:\Python27\pythonw.exe Faulting module path: C:\Windows\SYSTEM32\ntdll.dll Report Id: 2a4a8c55-d0d3-4479-9930-38672dc44c19 Faulting package full name: Faulting package-relative application ID: Attached is a WER file with more details, both reports are substantially the same for both machines. I looked at most of the code and learned that it will be a while before I understand python well enough to be of assistance there. I have several hunches as to possible causes now that I have observed the behavior for a couple weeks on a machine that fails consistently, I'm hoping someone sees something in the data presented so I can eliminate some of the possibilities. BTW Exception code: 0xc0000005 is often but not always a memory address being accessed wrong or not found, but it is kind of a default fall back code for MS and ntdll.dll covers a lot of territory. Report.wer
  9. Joat_Mon

    Wrye Bash - All Games

    I see it now, thanks.
  10. Joat_Mon

    Wrye Bash - All Games

    Keeping your statement above in mind. While skimming the code to try to determine what was happening in the installers tab I ran across this: github utumno-wip wrye-bash/Mopy/bash/basher/installer_links.py Open parentheses which begins in line 979 appears to be missing close parentheses I don't know enough about python to know if this is a problem that needs to be brought to your attention or not.
  11. Joat_Mon

    Wrye Bash - All Games

    Adding C:\Python27 to my system path statement seems to have solved the problem where Wrye Bash would crash on resize of icons in the status bar. To Update: This is not a complete fix. It works in all tabs except the installers tab. Resizing status bar icons while in the installers tab still crashes Wrye Bash. Also if you switch to the installers tab (doing nothing else) then switch to any other tab, resizing icons in the status bar can still crash Wrye Bash.
  12. Joat_Mon

    Wrye Bash - All Games

    Bleeding Edge Python Code 12/9/2017. Let me know if you need me to pursue this further with debug active. So far I've observed: Even with no apps added to the status bar changing the icon size can crash Wrye Bash. It is hard to prove a negative but it only seems to occurs at some point after changing the icon size at least 3 times. When certain apps are added to the status bar Wrye Bash will crash first time, every time that the icon size is changed on the status bar. Other apps when add to the status bar will exhibit the same failure as noted for no apps added to the status bar. WYRE I'm sorry, can I plead old age as a defense? Thanks again for your help. Edit: The apps that cause Wrye Bash to crash "first time, every time" when added to the status bar have something in common, they are installed in a folder on my f:\ drive. That means that this behavior is likely a windows path error and most likely can be ignored. I will test more later. The apps that when added to the the status bar cause the same result as no apps added are all on my OS drive.
  13. Joat_Mon

    Wrye Bash - All Games

    Thank you alt3rn1ty & RavenMind, I fully uninstalled Wrye Bash Standalone after using it for a year. I seldom use Win start menu, I'm sure the Icons where there but I don't remember them. I understood a mod manager's job was done when the game started, don't know why I said that, in fact I will prefer Wrye Bash to close for the SSE memory use testing I am trying to do now. A couple days ago I installed Python, the Utumno-wip Wrye Bash, and all the dependencies. I encountered one problem and thought I should report this. After reading the bug reporting guidelines I realized that I need to reproduce the error while running in debug mode, but I also realized that I needed to read everything related to Wrye Bash @ github to determine if my error was a known issue and I now think that it is a known issue. Just to be sure I will state it (unofficially) here: When I resized the icons at the bottom of the Wrye Bash window Wrye Bash closed/exited/crashed. Otherwise Wrye Bash has preformed admirably so far. The python version seems faster than the stand alone executable but that may be due to scandir more than anything else. I have been in the habit of leaving the Wrye Bash window open when I run SSE as I will often drop out of game to make changes while testing. I will need to break that habit as I have decided to create a memory use baseline of the absolute minimum game install using VMMap and I will need as few things running in the background as possible. That is why the command prompt window caught my attention, I did not want to leave it running when the game started. For some reason my brain decided that I would always run in debug mode from now on, just being stupid. Thanks again for the help and reminders. I have some questions (not problems) about Wyre Bash, if I can't figure them out from the documentation I hope I can ask the here without being too annoying.
  14. Joat_Mon

    Wrye Bash - All Games

    Thank you RavenMind, I have just changed from the stand alone to the Utumno-wip python version. I have only seen one GUI error that I did not cause. It is related to icons and I think it is a known issue. The problem with Wrye Bash not returning focus to the command prompt window is that I can't do anything else at command prompt unless I close Wrye Bash. I guess I will only be able to use debug mode during game play.

Support us on Patreon!