This thing is a great way to brick (until you offline reflash, which all AM5 boards have a USB port for) your ASUS AM5 board, since they seemed to have relocated settings on the NVRAM for some unknown reason.
Another way is resetting BIOS to factory settings. I am using a screwdriver to short two pins. Needed that because I was overclocking RAM for a better throughput for LLM.
Hopefully you saved your last working settings. You can save to USB from BIOS.
By the way, I think for my system this tool is not really neccessary because BIOS seems to offer at least the same settings (BIOS >= Master Utility).
I just use Buildzoid's standard baseline timings for Hynix (on Youtube, highly recommended) and then set it to 6000, I remember them pretty well by now. I'm more annoyed about it turning on the AC Installer WUBT backdoor every time.
Also its self-update is so genius, it opens a terminal window on the foreground that just hangs in there and does something (I guess?), mind you this is without you running the actual app... once I've seen it do this about 3 times it was going to the trash, where it belongs.
Not at all, I really rather like it when I'm playing a game and Windows tabs out to switch to a blank, unresponsive terminal to contemplate my life choices. It's like those "time to stand" reminders on an Apple Watch, except for throwing the computer out the windows.
Makes sens though. Overclocking APUs in laptops is much more trickier and riskier than desktop CPUs, especially that the optimal settings have already been tuned by the OEM and locked in firmware based on known thermal and VRM power design limitations, so overclocking won't get you any gains anyway but might brick your system.
If you really do want to tinker with your laptop APU in less risky ways, try this:
UXTU is unfortunately not very well written. I actually have a commit on this repo (actually the handheld version because for some reason, that's a hard fork) to stop it from leaking process handles (a resource that can't be reclaimed on Windows, except with a reboot)... and it adds up fast since UXTU runs `powercfg` every 2 seconds or so.
Last time I tried to slack around with it a bit after an upgrade it didn't even run on Windows 11, and this had been an issue for many months IIRC. So...
Isn't it vastly more convenient to iterate on overclocking changes directly from your desktop instead of having to reboot to UEFI every time you want to tweak something?
The automatic testing and setting of stable undervolt VF offsets per core is a great feature and something I miss on my current intel build. I don't know of any motherboard or other software that offers that.
Fun fact: Ryzen Master needs a kernel driver installed in order to function. This driver was signed with a cert that expired a while back. For years they required you to disable virtualization based security (because as a side effect it would also disable driver signature enforcement). When this first popped up, rather the fix the signature, they added a check to detect VBS and block starting if it's enabled. Then Microsoft made VBS and DSE separate settings, so now it gives a misleading error message. There was a patcher program that would workaround the issue, but it doesn't work for the most recent versions, unfortunately.
I went round and round with AMD support between December 2022 and April 2023, explaining exactly where the issue was, sending the event logs showing the driver was being blocked because of the signature, sent screenshots of the certificates showing the expired dates, etc. I kept getting sent to random articles, told to do useless steps, the usual stuff you get from "technical" "support" nowadays. Eventually they acknowledged the problem, and said that it would be fixed in an upcoming update:
> I've now looked into this and we are already aware of this issue and have an engineering ticket logged against it.
> It is only affecting the older Ryzen and Threadripper parts and it occurred since Ryzen Master Tool (RMT) received a significant update to improve the look and feel of the application.
> We do have a fix planned that will be incorporated into a future release build of Ryzen Master Tool, however I don't have a specific date of when that build will become public for you to download.
> The initial estimate is mid July, however this could change. My recommendation is to periodically check our website for the Ryzen Master Tool release notes as the issue will be documented as a fixed issue when the build becomes publicly available.
I check regularly, and I haven't seen a new version released that mentioned this. Plus, never versions don't work with the VBS bypass hack I was using.
And here's the email that finally got them to even admit it was a problem:
> Again, I'm frustrated. I've clearly explained over and over that the VBS setting doesn't affect this problem. So having you come back and say "this is expected behavior" is infuriating. You insisted I send my system info, which clearly showed VBS is off.
> I say again: even with VBS disabled, the driver won't load unless you ALSO disable the driver blocklist. And once again, forcing users to bypass important security features is borderline negligence, when this could easily be solved by getting the driver signed correctly.
> The true culprit is the expired/revoked signature on the driver. You can see this in the event log (as I included in my last message) showing the driver being rejected from loading into Windows because of the failed signature. The purpose of the VBS check is clearly because this used to cause the driver blocklist to be enabled, so disabling VBS also disabled the driver blocklist. THIS IS NO LONGER TRUE. Recent Windows updates have made the blocklist enabled by default, so that the only way to run Ryzen Master on affected systems is to disable both VBS (to get through the check) and disable the driver blocklist (to allow the driver to load).
I've never run into that issue with Ryzen Master, but only because using Intel's overclocking tools had already trained me to disable virtualization-based security. Intel's tools also had issues with that feature, and it took them a surprisingly long time to update their error messages to explain what was preventing XTU from running.
Aside from any driver signing issues, I think there's also an underlying common issue that the virtualization layer needs to pass through the CPU model-specific registers (MSRs) that are the hardware interface for tweaking power and clock limits.
I have never overclocked my 32-core 5975WX and I'm very interested in other people's experience, but I cannot imagine being convinced to do it myself. With 256 Gb ECC RAM it pumps out 3D massive renders with incredible stability.
26 comments
[ 1.8 ms ] story [ 70.5 ms ] threadHopefully you saved your last working settings. You can save to USB from BIOS.
By the way, I think for my system this tool is not really neccessary because BIOS seems to offer at least the same settings (BIOS >= Master Utility).
If you really do want to tinker with your laptop APU in less risky ways, try this:
https://github.com/JamesCJ60/Universal-x86-Tuning-Utility
Cool utility though.
I say it most definitely is.
> I've now looked into this and we are already aware of this issue and have an engineering ticket logged against it.
> It is only affecting the older Ryzen and Threadripper parts and it occurred since Ryzen Master Tool (RMT) received a significant update to improve the look and feel of the application.
> We do have a fix planned that will be incorporated into a future release build of Ryzen Master Tool, however I don't have a specific date of when that build will become public for you to download.
> The initial estimate is mid July, however this could change. My recommendation is to periodically check our website for the Ryzen Master Tool release notes as the issue will be documented as a fixed issue when the build becomes publicly available.
I check regularly, and I haven't seen a new version released that mentioned this. Plus, never versions don't work with the VBS bypass hack I was using.
And here's the email that finally got them to even admit it was a problem:
> Again, I'm frustrated. I've clearly explained over and over that the VBS setting doesn't affect this problem. So having you come back and say "this is expected behavior" is infuriating. You insisted I send my system info, which clearly showed VBS is off.
> I say again: even with VBS disabled, the driver won't load unless you ALSO disable the driver blocklist. And once again, forcing users to bypass important security features is borderline negligence, when this could easily be solved by getting the driver signed correctly.
> The true culprit is the expired/revoked signature on the driver. You can see this in the event log (as I included in my last message) showing the driver being rejected from loading into Windows because of the failed signature. The purpose of the VBS check is clearly because this used to cause the driver blocklist to be enabled, so disabling VBS also disabled the driver blocklist. THIS IS NO LONGER TRUE. Recent Windows updates have made the blocklist enabled by default, so that the only way to run Ryzen Master on affected systems is to disable both VBS (to get through the check) and disable the driver blocklist (to allow the driver to load).
Aside from any driver signing issues, I think there's also an underlying common issue that the virtualization layer needs to pass through the CPU model-specific registers (MSRs) that are the hardware interface for tweaking power and clock limits.