Latest Patch Introduced Two Major New Headaches

EricBloodaxeEricBloodaxe Posts: 10
edited March 2018 in Bugs
They are headaches for me, anyway.

#1 - Client.exe is locked into compatibility mode for Windows XP service pack 3 by default with no option to change. On my system this setting causes the client to crash if I am exposed to roughly 300 houses. ie: If I do a few laps around Luna I will crash. I used to be able to turn compatibility mode OFF and not crash at all. This is highly irritating, can we get the option back please? (see picture, it's grayed out, cannot be changed anymore)

To be clear this is game breaking for me. I cannot run after people in PvP because once I pass too many house I will crash and be killed. It's not fun. 100% repeatable too... I NEED to shut this compatibility off like I used to be able to do. Thanks.

#2 - Equally as frustrating is the innability to run two or more clients at once. While that has never been supported the classic client has always just given a warning that it is not supported but allowed you to do it. Now if I click on the client patcher a second time it no longer gives that warning, instead it simply says "patch error" and refuses to load a second account. I can't hand myself items between accounts and such. Note: You can still use 3rd party programs like Steam or uoassist to open another account, it just can't be done manually on my computer anymore.

edit: I'm not sure why the forum turns me typing #1 or #47 or #555 into a link, but it's not my link.
Ready, Willing and Able


  • RockRock Posts: 567
    Note -- under Windows 10 the enhanced client is not locked into any specific compatibility mode. One could be selected, but until reading this post I never bothered to look. Properties for my classic client does not lock compatibility mode into any specific mode either.

    I know this has little to do with the OP's problem, but I thought feedback from another player might be applicable.
    Rock (formerly Imperterritus VXt, Baja)
  • LexLex Posts: 38
    The problem is due to 2d clients lack of RAM adressing (only allows <2GB RAM or so for the program). This happens to me too, not sure how changing compatibility mode would fix it as each mode still wont allow more than a set amount of RAM.

    I know PVP:ers have suggested patching the 2d client for allowing full 4GB address expansion / PAE. The knowledge is out there, Kyronix has been notified so hopefully it's just a matter of time before Bleak or someone can fix it.
  • EricBloodaxeEricBloodaxe Posts: 10
    edited March 2018
    Lex, that sounds reasonable. With most computers today having 4Gb of ram upwards perhaps it's time to revisit the 2GB hard cap for the classic client. I have some additional information to back that up as well that I've figured out while debugging, as follows.

    *This fixed my own problems but not the underlying issue*

    I turned on my system monitor(Windows Task Manager/Performance Tab/Resource monitor button) and watched as I ran around the map on my computer which would be capable of running 100 instances of UO and not break a sweat performance-wise. As expected, while I ran, the amount of CPU used never exceeded 12%. The amount of virtual memory used never exceeded 18%. These were not the issue. The error stating "memory overflow errror" is just a generic error code, it's not what is going on either.

    I noticed that UO, more than any other program I have, throws "Hard Fault" errors(see resource monitor in your performance tab of windows task manager). An average of 11 hard faults per second in fact, all by client.exe and the spikes coincide with me running past a house. It's more like 0-1 hard faults per second when not near a house and 30+ hard faults when I come too close to one.

    For those who don't know: A "Hard fault" is not an actual error, it's a moment when your computer cannot handle the information within it's ram and so falls back on a paging file. If your settings are wrong, or inadequate, you can cause a lot of these but I have the recommended amount allocated to my paging file(1.5x Ram).

    Knowing that error codes are not always helpful I focused more on what my computer was doing after an error was triggered, and I got somewhere. My computer once had visual studio installed and visual studio has a feature called "Just In Time" debugging. This does what it's name suggests when a problem is detected. HOWEVER, my computer no longer has Visual Studio installed yet a full removal of the program does NOT stop the computer from trying to use "Just in time" debugging. In fact you most likely have to go into your registry to delete two very specific keys manually to get it to stop(or re-install visual studio and turn it off).

    Doing this essentially removed a tool my computer has that calls the debugger when too many hard faults happen. Without triggering the tool my computer is more than capable of soldiering on through even 1000x more "hard faults" per second.

    Devs - Please consider lifting the issue Lex mentioned so that my computer can "breathe" with all it's ram in the classic client. Here is more information about "Just-In-Time" debugging as well. . Ideally however you will look into what is happening to causes houses to throw hard faults on a properly optimized and more than capable computer, and I suspect you'll find it has something to do with ram limitations.

    Normally these cause no problems but I hope I described at least one situation in which is can, and does.

    Hope this helps, would love to hear more as I'm sure I haven't dug deeply enough.


    Ready, Willing and Able
Sign In or Register to comment.