Application error (0xc0000005) in Event Viewer every time after running ryzenadj.exe

[tomasz1986]

Basically, I get this error logged in the Event Viewer every time after running ryzenadj.exe. The exact command I run is ryzenadj.exe --stapm-limit=15000 --slow-limit=20000 --fast-limit=30000 --tctl-temp=80, and the values themselves get applied correctly, so I'm not sure what the problem is really about.

The error details are as follows.

Faulting application name: ryzenadj.exe, version: 0.0.0.0, time stamp: 0x6836dbd0
Faulting module name: ryzenadj.exe, version: 0.0.0.0, time stamp: 0x6836dbd0
Exception code: 0xc0000005
Fault offset: 0x000000000000ed9d
Faulting process id: 0x3064
Faulting application start time: 0x01dc19070e406073
Faulting application path: ryzenadj.exe
Faulting module path: ryzenadj.exe
Report Id: 837267ef-27e3-4c06-b25d-416b5aefe886
Faulting package full name: 
Faulting package-relative application ID: 

This is happening with RyzenAdj v0.17.0. The OS is Windows 10 x64.

[kulvind3r]

Are there any plans to address this bug. Happening for me as well.

[kulvind3r]

Ended up creating a replacement command line tool for my specific processor type (Ryzen 7 250) based on Ryzenadj / UXTU, for my needs. Uses PawnIO for safety instead of WinRing0

https://github.com/kulvind3r/R7250Adj

[Falcosc]

I would not be able to port that to RyzenAdj.

Looks painfull, I don't understand why it has to memcopy the function name to call them instead of having symbols.

static bool pawnioExecute(const char* fn, LONG64* in, int inCount, LONG64* out, int outCount) {
    ...
    memcpy(inBuf, fn, fnLen < (size_t)(FN_NAME_BYTES - 1) ? fnLen : (size_t)(FN_NAME_BYTES - 1));
    ...
    DeviceIoControl(g_device, IOCTL_PAWNIO_EXECUTE,inBuf, (DWORD)inBufSize, outBuf, (DWORD)outBufSize,&returned, NULL);
    ...
}

And it would need more changes since I expected since ryzenAdj currently uses the memory interface instead of a module function for each memory region

pawnioExecute("ioctl_resolve_pm_table", NULL, 0, resolveOut, 2);
pawnioExecute("ioctl_update_pm_table", NULL, 0, NULL, 0)
pawnioExecute("ioctl_read_pm_table", NULL, 0, (LONG64*)tableData, (int)(PM_TABLE_FLOATS / 2))

pawnioExecute("ioctl_read_smu_register", inBuf, 1, outBuf, 1)
pawnioExecute("ioctl_get_code_name", NULL, 0, codeNameOut, 1);
pawnioExecute("ioctl_write_smu_register", inBuf, 2, NULL, 0)

But it has everything needed to implement, thank you. Unfortunately that's out of my comfort zone, if I would do it, it would most likely not be perfect, which means thousands of users would get issues even if my try of implementing it would work fine on my computer.

[kulvind3r]

I am not a C++ dev and built this for personal use using LLM, so i can understand you as a C++ dev spotting some weird things in LLM's implementation approach. I cannot judge it. I can only try to make it as safe as possible within my limited knowledge.

No expectations on porting it. I just wanted to share that at least for Ryzen 7 250 processor used in very popular Lenovo LOQ Models being sold in india, if a user needs something without this bug, it is available.

Been using it for 2 days on my personal laptop in an automated script that polls power limits and resets them to desired level if the laptop firmware changes them. No issues so far.

Having said that, the functions being called by using a memcopy seems like the way PawnIO driver does thing. The modules in the 2nd set of code are also a PawnIO way of doing things.

I originally took this pattern from LibreHardwareMonitor's implementation of PawnIO when i wrote an Embedded Controller reader to replace the EC Probe functionality in NBFC (Notebook Fan Control) which was using WinRing0 and MS Defender kept flagging it.