Freeze windows 10

[anon-erpk]

          @anon-erpk @seatsea Can you tell me if new lines in the XvB tab console appears every minutes instead of every ten minutes when the UI is freezed or does it freeze also without this issue ?

Originally posted by @Cyrix126 in #6 (comment)

I'm not able to see if that's the problem, when the UI freezes I'm not able to check any tab, in 1.0 and 1.1 releases I had the "not responding" error, in 1.2 the UI just freezes, and everything stops (p2pool, xmrig, proxy and XvB), I have to Force Close all the process tree to be able to restart gupaxx.

I'm Windows 10

[Cyrix126]

Since 1.1.1 Gupaxx should lower the priority of xmrig which was taking all the cpu time, letting Gupaxx to crash. At least it solved the issue in the VM of W10 I was testing. Can you check in your task manager if xmrig start with a lower priority ? and also do you still have the crash if you put Gupaxx with a higher priority ?

[anon-erpk]

no, I'm lowering xmrig priority by myself, now I will test Gupaxx with a higher priority.

edit: even with this priority configuration, it freezes after sometime, I'm not able to see if it's the XvB algo

[anon-erpk]

I'm sorry for chainposting , but I need to update this situation:

yesterday I tried again to change the processes priority xmrig was on Idle, and GUPAXX on Above Normal, it was running until now with almost no problems, the UI was not maximized (I was doing it before), p2pool, xmrig, and proxy were still running, but the XvB tab was "yellow" but it never finished to restart, and I was not able to do it manually, the buttons were all disabled.

[Cyrix126]

I'm sorry for chainposting

I prefer to have updates, no worries.
The maximization of the UI should not make a difference.
What you are describing however appears to be a different issue.
Yellow means the process is in the middle of a start. If it is not getting to a failed state or alive after a few seconds, then it is a bug where a situation has not been taken into account.
Did it get into yellow after a while ? what was saying the console of XvB ? does the rest of the UI were responsive ?

[anon-erpk]

Ok, new update, today I was able to see the moment when the UI freezes, and, unfortunately, is just it, I had to restart gupaxx sometimes today, due the freezing, sometimes the XvB algo doesn't start (it stays yellow and don't get triggered when p2pool finishes to sync), sometimes it just freeze all UI interface, XvB console messages are normal, no errors, just pointing to p2pool or donating.

Is there a way to get logs to investigate what is happening?

[Cyrix126]

Is there a way to get logs to investigate what is happening?

The output in the terminal should show the logs, but it seems to not be working on Windows.
I made a commit to add a command line option --logfile, that will simply write the output to a file in the directory of Gupaxx. You can download the binary on the github actions

Do you have freezes even if the priority of xmrig is lower and the one of gupaxx is higher ? you didn't mentioned if you changed them on your last message. It is expected to freeze if the priority of xmrig is not lower. Gupaxx should set it automatically, so if it's not, that's the first issue to fix.

[anon-erpk]

Yesterday I had 3 or 4 freezes during the first hours of the morning when I wrote the last update, in a time spam of 20 minutes, after that, gupaxx is running with no issues until now,but i'll run this binary to see if something shows up on the logs

[Cyrix126]

Yesterday I had 3 or 4 freezes during the first hours of the morning when I wrote the last update, in a time spam of 20 minute

Yes but was it with xmrig set at lower priority ?

[anon-erpk]

Yesterday I had 3 or 4 freezes during the first hours of the morning when I wrote the last update, in a time spam of 20 minute

Yes but was it with xmrig set at lower priority ?

No, I had no issues since my last post, BUT i had to change the priority by myself (with process explorer (not task manager), I put xmrig at the lowest priority), aaand... everything is running smooth since then.

[Cyrix126]

ok thanks, so apparently this is not active in your situation. I'll check with the VM.

gupaxx/src/helper/xrig/xmrig.rs

Lines 472 to 485 in 0865fe2

	// needs xmrig to be in belownormal priority or else Gupaxx will be in trouble if it does not have enough cpu time.
	#[cfg(target_os = "windows")]
	std::process::Command::new("cmd")
	.args(["/c", "/q", "wmic"])
	.args([
	"process",
	"where",
	"name='xmrig.exe'",
	"CALL",
	"setpriority",
	"below normal",
	])
	.spawn()
	.expect("failure to execute command wmic");

[anon-erpk]

Hey, I forgot to mention, after the first freeze, the program is not starting again (some configuration file maybe?), since then, I have to run it in compatibility mode (win7 or 8).

[Cyrix126]

Can you try https://github.com/Cyrix126/gupaxx/actions/runs/9991285994 ? there should not be any freeze anymore since the command to lower xmrig priority is now working.

[iamdeka]

I have the same issue of Gupaxx freezing and not responding after a while on the 1.2.0 release, but this doesn't happen using the gupaxx_b.exe binary from the action and i currently have 2 days of uptime on it
Windows 11 24H2

[Cyrix126]

I have the same issue of Gupaxx freezing and not responding after a while on the 1.2.0 release, but this doesn't happen using the gupaxx_b.exe binary from the action and i currently have 2 days of uptime on it Windows 11 24H2

The only difference between the two are that _b will update bundled binairies by default.

I'll close the issue after the 1.3.0 release, except if you tell me you have a freeze with latest action binary.

[iamdeka]

Running on the same binary with 3 days of uptime now. It seems to be fixed

[Cyrix126]

fixed in 1.3.0