Keryx 0.15.5 fixes Windows NVIDIA rigs that could not start mining after the H15 self-test
Source report: 2026-10-31 · Editorial analysis published: 2026-10-31
The October 31 release fixes 0.15.4’s Windows environment-setting bug and explains readiness warnings. Linux packages were not affected by that bug; AMD and Apple Silicon still lack the required H15 trace engine.
A ready model could still leave the rig idle
Keryx-miner-supr 0.15.5 was released on October 31 to fix a Windows NVIDIA failure in 0.15.4. According to the developer, no Windows card passed the H15 traced self-test, so no model became ready and the miner did not mine in either solo or pool mode. The release says the model files were fine. For an affected operator, repeatedly downloading those files was therefore not addressing the cause.
This is Keryx GPU mining software, not Bitcoin ASIC firmware. The new failure is also different from the Windows library-export problem fixed in 0.15.2, which this site previously covered. That distinction matters when reading an old support message: successful model loading under an earlier fix does not establish that 0.15.4’s later H15 readiness test can pass on Windows.
Why the settings did not reach the engine
The miner and its inference engine are separate software components. For traced answers, the miner supplies settings that turn off CUDA graphs and engine cache rotation. In 0.15.4 on Windows, the settings reached the operating-system environment but not the C-runtime copy read by the engine library. The result was a failed test even when the correct model was present on disk.
Version 0.15.5 sets those values through the runtime as well and checks at startup that the engine can see them. The author says the Windows build is now tested for that path. Linux, HiveOS, mmpos, SMOS and Docker were not affected by this particular environment bug. That is a defined repair scope, not evidence that every possible problem on those platforms has disappeared.
H15 readiness is more than a successful download
In H15, a private inference answer needs a verifiable trace: a record that lets the node check selected parts of the model’s calculation. The release distinguishes ordinary block mining from serving those private requests. It says 0.15.0–0.15.2 can mine H15 blocks correctly but cannot satisfy the newer private-answer requirements. Missing an answer can create a service-bond strike, a penalty against the service obligation.
The miner therefore performs a traced self-test before declaring a card ready for its tier, meaning the class of model it can serve. A card that cannot produce the required evidence stays out of mining instead of claiming a capability it cannot fulfil. Keep the engine bundled with the selected release; mixing an older library with a newer client can defeat the compatibility the package was intended to provide.
The warning now helps identify the next step
The readiness warning is no longer repeated for every block without explanation. It distinguishes a model still downloading, no staged model, a pending test, a failed test on a named GPU and a build that cannot produce traces. The message appears once and then at most every 60 seconds or when the reason changes. A quieter log is easier to read, but the reason and readiness result remain what the operator should check.
AMD OpenCL/Vulkan and Apple Silicon Metal still lack the required trace engine in these packages. The notes say they do not mine after the gate and explain why. Downloading 0.15.5 does not turn that platform limitation into the Windows problem it fixes. For NVIDIA, choose the documented Windows or Linux package appropriate to the card and driver, rather than treating all archives as interchangeable.
The developer reports package validation, including a Linux RTX 5080 test and checks that Windows exposes the settings to the runtime. These are the author’s tests. We have not installed the binaries, run a GPU benchmark or measured a power saving. The release changes settings delivery and warning text; it does not announce a new hash algorithm or a numerical speed gain.
Check the repair with actual work
Use the official tagged release and its matching SHA256SUMS to check the downloaded archive. A checksum verifies file consistency with the listed digest; it does not replace checking the publisher and release page. Preserve the existing configuration and logs before replacing files so that the old symptoms and the new startup sequence can be compared.
After an update, look for the test result, the declared model tier and accepted work at the pool. A running process or rising GPU utilisation alone does not prove that mining is producing accepted work. Keep the observation window consistent, and separate local readiness from a pool connection or payout delay. This makes it easier to avoid spending hours tuning hardware around a software-startup failure.
For Windows NVIDIA users of 0.15.4, the practical action is the developer’s recommended update followed by a readiness check. For other systems, read the platform-specific cause before changing anything. The useful outcome is a rig that passes the required test and submits valid work, rather than one that merely stops printing a warning. Any income calculation still needs actual accepted work, fees, electricity and runtime.
Source: keryx-miner-supr / ocminer ↗ · Previous0.15.4 release and trace requirements ↗ · Official miner documentation ↗
Mining calculator ↗
