5.1.3 crashing perhaps due to incorrectly applied optimizations[BUG]

[Intoxicus]

Describe the bug Appears to apply optimization settings even if set to manual. Will crash and also the hashrate changes as if lite settings were applied. It will apply lite settings even if the installer is told not to.

To Reproduce Run 5.1.3 normally while set to manual and using custom OC settings on my system.

Expected behavior NHQM crashes(all mining processes terminates) and asks to set optimizations to manual on restart

Screenshots If applicable, add screenshots to help explain your problem.

Version affected (please complete the following information):

• 5.1.3
• RC or STABLE? Both

NVIDIA driver version 466.11(All drivers are as update to as possible assuming I know there is an update available)

Hardware EVGA RTX 3080 FTW3 w/Hybrid Kit on XOC Bios(450W) w/ ReBAR Enabled (Optimizations don't account for hybrid kits and XOC bios, please let me hard disable them) Ryzen 3800x ASUS ROG Strix X470f

Logs I already downgraded to 4.5.5 and I'm not going to spend any more hours messing around with this with all respect. This has already been time consuming, frustrating, and lost me a couple nights of mining. You can use your own knowledge of what you changed between the two versions to figure this out

Additional context This appears to be an issue with the optimizations and nothing to do with Webroot or AV. This does not happen on 4.5.5 This can potentially be quickly hotfixed by allowing users to hard disable optimizations in the desktop app so that they can't cause any issues for people like myself. A checkbox for "disable all optimizations: for manual OC only" or something similar could solve this relatively quickly. Is there a way to do this using the config file?

[nicehashdev]

If you are using webroot, please read this: https://github.com/nicehash/NiceHashQuickMiner/issues/438

[Intoxicus]

This is not a webroot issue. I did test this with webroot disabled and it is not related to AV killing the process. It is crashing, especially noted by the "NHQM crashed, do you want to apply manual optimizations" error message when I reopen NHQM.

Add in a manual, app side, hard disable of optimizations please.

[nicehashdev]

Please, read stated issue again - the issue is that webroot still blocks NHQM regardless of being whitelisted/disabled. It is a webroot bug/issue which is being refused by webroot company to be an issue at all.

[nicehashdev]

The stated message would appear any time NHQM is closed by force - this include being killed/blocked by AV.

[Intoxicus]

Again:

I tested with Webroot disabled and problem is still present.

Also has the symptom of hashrate changing to what I would expect from Lite Optimization.

I can tell it's changed me from manual because of the hashrate changing so drastically. I'm normally at 95-100ish and when it forces applies Lite(or whatever optimization it's forcing on me) it goes down to a solid and steady 85ish. Regardless the option to fully disable optimizations and hard force manual only is a must to avoid potential weirdness with optimizations and people not wanting to use them.

Look at it this way: You add in that hard disable for optimizations and troubleshooting certain issues becomes a lot easier.

It's a relatively simple thing to add in. It adds more value having that option to hard disable all optimizations than to not have it.

Truly a full hard disabling of all OC optimizations is something that we should have as an option/feature for troubleshooting reasons.

[nicehashdev]

A default installation of NHQM with checkbox apply LITE optimization disabled should not modify any clocks except GPU memory (VRAM) if being OCed for the time of DAG being generated. You can disable that one as well by launching excavator with added switch -g. Let me know if that helps you.

[nicehashdev]

This is not a webroot issue. I did test this with webroot disabled and it is not related to AV killing the process. It is crashing, especially noted by the "NHQM crashed, do you want to apply manual optimizations" error message when I reopen NHQM.

Add in a manual, app side, hard disable of optimizations please.

When NHQM crashes or is forcefully stopped by any 3rd app, then this is the default starting dialog which of course, waits for user input. If you wish to start NHQM without waiting for user input regardless of unstable configuration, you should append --count exec command line when launching it (just like being done when auto started with task scheduler). This does 10 second (or depending how it is configured) count down before it is launched to give user ability to stop/reset execution and prevent crash again.

[Intoxicus]

Yes,

With all respect some of these things need to be options in the GUI and not be command line switches. As much as I literally grew up on DOS and know how to deal with such things I also don't have the time to go deep on all this.

Clear options for these things in the GUI would add a ton of value to NHQM and make it easier for casual miners to get into it. It would also make troubleshooting all around easier and make bug hunting and quashing less tedious.

The point I'm getting at is that if these were clear option in the GUI instead of command line switches I have to research to know about it would make a lot of things simpler and easier for everyone.

For example instead of the -count command line switch it's better, easier for the user, and simpler for troubleshooting to have a GUI hard disable for optimizations.

I understand from the coders/devs perspective command line switches are all day everyday and you do them without thinking. You're not making this program for you or for devs. You're making this program for non devs that don't always deal with commands line switches on the daily and strongly prefer a GUI for all the reasons we have GUIs in the first place.

I should be able to set all options and settings from the GUI on the desktop app and not need the website for anything other that to verify stuff is working correctly.

Ideally stats, monitoring, everything should be accessible through the NHQM app. Even if it's an "advanced users only" option to access the deeper menus.

I haven't coded since high school and need to correct my error in not keeping up with it. Otherwise I would volunteer to do the work I am speaking of.

Please integrate advanced and detailed options into the GUI because it would enhance NHQM greatly and add a lot of value overall to NHQM.

[Intoxicus]

A default installation of NHQM with checkbox apply LITE optimization disabled should not modify any clocks except GPU memory (VRAM) if being OCed for the time of DAG being generated. You can disable that one as well by launching excavator with added switch -g. Let me know if that helps you.

If I set it to manual NONE of the clocks should be altered at all. Period. Not even memory clocks.

You're telling me "manual" settings are not even truly and fully manual?

This is why you need to allow a hard and full disable for ALL optimizations.

How can you properly troubleshoot anything without being able to control for variables? You're quite likely causing crashes with that for all sorts of reasons that could easily be avoided by having the manual setting actually do what it advertises.

Besides the fundamental idea of manual means manual. Still controlling my VRAM clock for me is NOT "manual."

We need a true manual setting that does not do anything at all to my OC settings.

Please have it be a GUI checkbox for "disable ALL optimizations" which makes it so that whatever I set via my OC app is what is actually going to happen.

If not for us, then do it for your own troubleshooting efforts.

[nicehashdev]

If memory OC is not modified (set to default) for the time of generating DAG then 80% of users would get share above target due to invalid DAG.

UI options are made when enough users need it. Currently, it is possible to disable any OC modifications by setting manual and -g switch for Excavator and this is enough, because so far, you are the only one requesting/needing this feature. To the contrary majority of users need mem OC reduction during DAG generation to avoid invalid shares thus it is automated and turned on by default.

[Intoxicus]

I'm not deep into the technical details of coding miners. Being that OC is common enough why not make adjustments to accommodate for the OC instead of forcing a downclock?

Anyway it doesn't force it default as much as it changes the offset so I don't get as much as a mem OC as I set.

I suspect however you're doing this is causing problems. Perhaps might be partly what's triggering A/V programs?

And telling me to turn off Afterburner and use your optimizations is NOT a solution.

Everyone should be able to run their own custom overclocks without NHQM messing with them.

[nicehashdev]

Like I said, if you want 3rd party tool to control clocks, you will have issues with invalid shares due to incorrectly built DAG data. If you want DAG to be built correctly, you cannot use so high VRAM OC as when it is used only for reading. 3rd party tools cannot detect when new DAG needs to be built - only Excavator can do that thus it has ability to modify clocks to delta 0 when DAG is being built. I suggest you to study this issue first, then you will understand why this feature is on by default.

The feature you suggest would be used by very very small percentage of users due to the problem I explained. Therefore, there is no UI for it, because it is not needed for majority of users. You can still configure it by setting Manual and add launch parameter -g to Excavator.

[Intoxicus]

I almost never have invalid share errors when I watch the Excavator console.... My mem is OC is at 10626 because instead of setting it to default it offsets and reduces clocks. What you say it's doing is not even what is happening...

"In the Beginner's Mind there are many possibilities. In the Expert's Mind there are few." Perhaps put some though into that quote.

-I do not want to use optimizations. I am not the only one. -Manual should mean manual. There's no debate on that. If it is not actually manual then do not call it that. Change the label and explain what is going on so people know what it actually really does(transparency) -4.5.5 does not have this issue and does show the symptom of being forced into an optimization profile when I set manual. I can mine fine on 4.5.5. -5.1.3 crashes(IT IS NOT WEBROOT I TESTED THAT!!!!) and it does appear to be because optimizations are being applied when I have selected "manual" -Whatever you did with 5.1.3 is causing problems. I've seen other bug reports about similar crashes. Look into the optimizations.

[Intoxicus]

Basically what you're telling me about DAG generation doesn't hold up to the fact I am running my memclocks very over clocked and not getting DAG generation error like you say should be happening.

If allowing me to OC my memory creates DAG errors then how is it I have OC'ed memory and no DAG errors on 4.5.5?

I do not have the time or desire to become a crypto mining dev.

Often times there are solutions that people are unable or unwilling to see because of various factors including Expert's Mind.

[nicehashdev]

You are making statements according to one GPU. We have all GeForce models made by NVIDIA. Our settings are made according to tests using all of them. It seems you have an issue with drivers then. Make sure to install latest one and if that is still causing issues, use DDU to reinstall them.

There is no difference in 0.4.5.5 when it comes to handling Manual. Mem OC to 0 still happens when generating DAG.

There are more than 100k users of latest stable version. If there was such a huge issue with crashing, then these numbers would show this. Also, we have plenty of testing rigs, all of them are working just fine on latest version, but of course, we take care and check that NVIDIA drivers are properly installed, because sometimes, it can happen, that they are not.

Also, we do not use any extra security software that may interfere with the processes. There is only Windows Defender where we whitelist/make folder exclusion.

[Intoxicus]

How do you jump to the conclusion it's a driver issue? There is nothing at all that points to drivers. Literally not a single symptom points to anything driver related.

I am using the latest driver and always use DDU btw so your generic advice for noobs is almost like you think I'm some noob...

You're clearly grasping at straws because you don't want to admit you might be wrong.

What my symptoms do point to is that something is different with how 5.1.3 deals with overclocks and optimizations.

If you want to be all stubborn expert mind about it then that is your choice to be like that. And it is your choice to fail to address issues because you don't want to admit you might be wrong.

I'll use 4.5.5 which actually works until you guys can actually make things work properly in future versions.

[ZORO735]

hey have you tried to delete the old rig and make new one from the main page of nicehash

[nicehashdev]

How do you jump to the conclusion it's a driver issue? There is nothing at all that points to drivers. Literally not a single symptom points to anything driver related.

I am using the latest driver and always use DDU btw so your generic advice for noobs is almost like you think I'm some noob...

You're clearly grasping at straws because you don't want to admit you might be wrong.

What my symptoms do point to is that something is different with how 5.1.3 deals with overclocks and optimizations.

If you want to be all stubborn expert mind about it then that is your choice to be like that. And it is your choice to fail to address issues because you don't want to admit you might be wrong.

I'll use 4.5.5 which actually works until you guys can actually make things work properly in future versions.

Because in version 0.5.1.3, CUDA version was advanced from 11.1 to 11.2. CUDA version 11.1 works fine for you, 11.2 does not. This is it then.