Re: Claymore's Dual Ethereum AMD+NVIDIA GPU Miner v11.7 (Windows/Linux)

We are having the same problem that Marius 85 and others seem to be having.

Quote from: marius85 on May 26, 2018, 10:34:54 PM

How may i fix this? I get a loop with this and it doesn't start mining..

Reloading epools.txt
ETH: 7 pools are specified
Main Ethereum pool is eth-eu1.nanopool.org:9999
ETH: Stratum - connecting to 'eth-eu1.nanopool.org' <79.137.82.70> port 9999 (unsecure)
ETH: Stratum - Connected (eth-eu1.nanopool.org:9999) (unsecure)
ETH: Authorized
Reloading epools.txt
ETH: 7 pools are specified
Main Ethereum pool is eth-eu1.nanopool.org:9999
ETH: Stratum - connecting to 'eth-eu1.nanopool.org' <79.137.82.70> port 9999 (unsecure)
ETH: Stratum - Connected (eth-eu1.nanopool.org:9999) (unsecure)

We reformatted our hard drive, reinstalled windows 10...had to go with 1803 as we did not have an older version available. Downloaded Radeon driver 18.5.2 and Claymore 11.7. We put the EthDcrminer64.exe into windows defender exceptions and still shuts off as soon as we start. Here is the last log

20:26:15:884   e38   Check and remove old log files...
20:26:15:884   e38   args: -epool us2.ethermine.org:4444 -ewal xxxxxxxxxxxxxxxxx -epsw x
20:26:15:884   e38
20:26:15:899   e38   ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
20:26:15:899   e38   º Claymore's Dual GPU Miner - v11.7 º
20:26:15:899   e38   º ETH + DCR/SIA/LBC/PASC/BLAKE2S/KECCAK º
20:26:15:899   e38   ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ¼
20:26:15:899   e38
20:26:15:899   e38   b583
20:26:16:149   e38   ETH: 1 pool is specified
20:26:16:149   e38   Main Ethereum pool is us2.ethermine.org:4444
20:26:16:149   e38   DCR: 0 pool is specified

We even went into the console and tried to run the program...exactly the same log as this one. Just keeps shutting down as soon as it starts.

Very frustrated as the miner was running so well for the past four months. We're newbies so we're at the limit of our knowledge base.
We are running three RX 570's with moded bios....ran patch...they are recognized and in compute mode. One XFX RX 570 not moded on compute mode....we had stable 111mh/s on previous windows and Claymore 11.0.

Is there any hope? Huh

Clone the SSD from another working rig. Update drivers only, if required.

I know that we are super small fish and this might work but we just have the one little 4 card rig. I mistyped and we are running adrenaline 18.5.1. It won't even run through the console as recommended by isux on page 1205. I have seen this same issue on several other posts but no fix that works for us. What other things should we be looking at? We copied the setx commands into the bat file and the log shows the only commands we have after that. Config file is all #'ed out so no interference or double commands. Even if it is an overclock issue we should at least be seeing the stock card run something.

That sounds frustrating.
What do you have Virtual memory set to?
With 4GPU, 16GB should be fine, but if you want to absolutely exclude this possibility, set VM to 48000, (I have some 13 GPU rigs running that, and it's fine).

Also, side note, actually, I'll do a new post on this bit, hibernation!

If you didn't try it already, turn on debug and see if Claymore log adds some clues.

And if you really hit the wall, remove all the GPU but 1, boot to safe mode, run DDU, reboot, and install AMD driver with that single GPU, set to compute, reboot, and see if that works. Then add back the other GPU, build up to that etc, but get a proof of concept first.

Don't forget to switch off debug when things are running.

Good luck

Foot note: As always, if you get stuck, post your complete batch file content.
There are a lot of possible causes to this, so there is no one answer, but another common error is to command a clock the hardware can't deliver on. Claymore is waiting for some ack, which depending on what you sent to the hw, the driver, and probably the hw ability to cope with the impossible, might not send an ack, and Claymore can only wait, (and have the smarts to not wait forever, but trip a reset after 5 min).

But going back to basics, break it down, is a good method for debugging. Yes, it might be painful, but if done right and systematically, DOES deliver a good probability of finding a solution. Far more so than blindly stumbling around in the dark, hoping to get lucky, hmmm that reminds me of something else, hahaha.