简介这是加密货币挖矿软件 cgminer 的 3.7.2 Windows 编译版面向矿工、技术爱好者及矿场运维人员用于在 Windows 平台下驱动 GPU、ASIC、FPGA 等矿机设备并监控算力与温度等运行状态。压缩包共 36 个文件大小 3.12MB主要包含 exe 主程序cgminer.exe 与无 GPU 版本 cgminer-nogpu.exe、dll 运行库如 libcurl、libssh、OpenSSL、cl 内核脚本如 scrypt130511.cl、diakgcn 等、conf 配置示例、txt 说明文档以及 API 调用示例c/php/python可满足从基础配置到二次开发的多种需求。已有 170 人学习下载。借助 COPYING、ChangeLog、API-README、SCRYPT-README 等资料用户可快速了解版本差异、接口定义与 Scrypt 算法配置方式适合希望深入掌握 cgminer 内核结构、参数调优和 API 集成的读者。1. 老矿工软件包现在解压它的人大多想要一个能跑的实验环境cgminer-3.7.2-windows.rar 是早期广泛使用的开源挖矿程序在 Windows 平台上的 3.7.2 版本压缩包。它曾经是显卡矿机和早期 ASIC 矿机最常用的控制端之一如今再被翻出来通常不是为了算力收益而是为了三件事复现老的矿机控制环境、研究矿机与服务器之间的通信协议、或者拿它给特定型号的显卡和 USB 设备做低层调试。这包的优势在于控制逻辑几乎都集中在命令行和纯文本配置里不依赖网页控制台也不会在后台挂一堆无关服务同时它自带的 API 足够简单适合写监控脚本。对想弄清“矿机程序到底在和服务器说什么”的从业者来说它的体量刚刚好比看协议文档直观又比现代一体化的挖矿套件更容易拆开观察。它适合配合本地假矿池做协议验证和参数实验但不适合被当作现役的生产工具更不适合作为投资获利的入口。下文按解压校验、最小启动、参数配置、协议分析、故障排查的顺序展开把这条路走通。2. 解压与先跑起来cgminer 在 Windows 上的最小可用路径2.1 解压前先做三个动作校验哈希、隔离安全软件、补齐运行库下载到本地后不要急着双击解压。老版本程序经常被安全软件标记而且你很难凭文件名判断压缩包是否被改过。我一般先打开 PowerShell切换到包所在目录计算 SHA256 并与发布方留档的哈希值比对。重点不是把哈希背下来而是建立“拿到的文件和别人发布的文件一致”这个前提否则后面所有参数调整都是在替错误版本排错。Get-FileHash .\cgminer-3.7.2-windows.rar -Algorithm SHA256 | Format-List这段命令输出文件的 SHA256 值-Algorithm SHA256指定算法Format-List是为了让长哈希完整换行显示方便和参考值逐字符对照。如果下载页没有提供参考哈希至少把算出来的值单独记到文本里以后程序行为异常时重新算一次能快速排除“文件被替换”这类问题。第二个动作是处理安全软件。老程序的数字签名基本都已过期行为特征也容易被误判。不要为了让它跑起来把防护整个关掉正确做法是把整个实验目录加进白名单。比如把解压目标统一放在D:\mine-lab这类专用目录下再在安全软件的排除列表里加入这个目录。这样启动时不会被拦截其余目录仍然处于保护范围内。第三个动作是补齐运行库。这个年代的 Windows 程序大多依赖 VC 运行库新装系统经常缺。与其等到启动报错再临时装不如在解压前先把运行库集合装好。装完后不用重启直接在当前终端执行cgminer.exe --help能弹出帮助文本就说明最基本的运行依赖已经满足。2.2 看目录先分类哪些文件必须留哪些可以丢解压后先别急着找 exe花两分钟把目录里的文件按类型分一下类。老版本程序的包内文件不多但混着文档、日志和示例配置全部保留反而干扰判断。文件类型作用处理建议主程序 .exe程序入口所有参数从这里进入保留动态库 .dll提供设备枚举、算法库等能力保留不要单独升级示例配置 .conf / .txt参数模板和启动说明保留一份作为参考运行日志 .log记录历史启动和运行信息可删除不影响运行说明文档 / 更新记录了解参数变化与已知问题建议保留.dll文件是最容易出问题的。老程序对动态库版本很敏感用新版本替换旧版本常常导致启动阶段直接报“找不到入口点”反过来系统里已经装了更新版本的 VC 运行库老程序反而会因为找不到旧版 API 而拒绝启动。我的习惯是整个目录维持解压原样只删日志不替换任何动态库。2.3 用命令行把程序拉起来最小启动参数与输出判读第一次跑命令越短越好。把矿池地址指向本地127.0.0.1既避免一开始就依赖公网矿池的连接质量也能让后续的协议排查在一个完全可控的环境里进行。cgminer.exe --scrypt -o stratumtcp://127.0.0.1:3333 -u test.worker1 -p 123456 -I 9 -w 256解释一下每个参数的作用--scrypt把算法切换到 scrypt 路径不指定时默认走 SHA256-o指定矿池地址这里用stratumtcp://前缀表明走长连接协议而不是 HTTP 轮询-u和-p是登录名和密码本地实验环境没有账号校验占位即可-I 9是显卡强度保守值-w 256是工作大小也是从稳妥档起步。需要注意不同来源的 cgminer 3.7.2 包可能存在编译选项差异。先运行一次cgminer.exe --help确认输出里确实包含--scrypt这个开关如果帮助文本里没有说明这份包是精简编译版后面的参数组合需要相应调整。启动后程序会进入全屏字符界面顶部显示矿池地址、算法和运行时间下方滚动输出连接日志。这个阶段只要看到窗口不闪退、日志在持续刷新就说明程序本身已经跑起来了。如果本地矿池服务还没启动日志里会反复出现连接失败的重试信息这属于正常现象接下来补上矿池服务即可。2.4 启动失败的三种典型现象与检查顺序启动阶段最容易遇到三类问题按出现频率排序。第一类双击无反应或弹出缺少 DLL 的提示。绝大多数情况是 VC 运行库缺失按 2.1 补装后重启终端再试。第二类程序被安全软件拦截文件刚解压出来就被隔离。检查排除目录是否生效把整个实验目录加白后再解压一次。第三类窗口一闪而过什么信息都看不到。这通常发生在显卡枚举失败或参数写错时用cmd /k cgminer.exe --help包一层让报错信息停留在屏幕上再逐条查看。如果以上都排除还是秒退打开系统事件查看器看应用程序日志里对应进程的报错模块名能定位到是显卡驱动层的问题还是运行库缺失。老矿工程序对显卡驱动的枚举方式比较敏感显卡驱动过新或过旧都可能让它拒绝启动这一点到后面排查章节还会再提到。3. 参数调到肉从启动参数到 conf 文件的整套配置写法3.1 核心参数分三类算法、GPU、网络把参数分成三类来记配置时才不会为了调一个风扇转速把矿池地址弄丢。算法类参数决定运行在哪条计算路径上GPU 类参数决定显卡资源的占用方式网络类参数管矿池连接和监控入口。分类常用项作用备注算法--scrypt切到 scrypt 算法路径不指定时走默认 SHA256GPU-I/--intensity数值越高显卡占用越高以--help输出范围为准从低往高调GPU-w/--work-size单批次工作缓冲大小对驱动敏感过高容易黑屏GPU-g/--gpu-threads每张显卡的线程数增加线程同时增加整机功耗GPU--temp-target目标温度配合自动风扇策略使用网络-o/--url矿池地址scheme 要写全网络-u/-p登录名和密码本地实验可随意填写网络--api-listen开启 API 监听配合监控脚本使用理解这三类的作用范围比背参数更重要。GPU 参数调的是本机资源的分配方式调错了最多驱动崩溃、黑屏重启网络参数调的是与外部的连接契约写错 scheme 或端口程序日志会一直报连接失败但显卡本身没有任何问题。3.2 conf 文件长命令转成可维护配置命令行的优点是直观缺点是参数一多就难以维护。实际使用中我几乎不会把超过五个参数写在命令行里而是把整套配置写进 conf 文件用-c指定加载。{ pools: [ { url: stratumtcp://127.0.0.1:3333, user: test.worker1, pass: 123456 } ], scrypt: true, intensity: 9, worksize: 256, gpu-threads: 2, temp-target: 70, auto-fan: true, api-listen: true, api-network: false, log: cgminer.log }这份配置把第 2 章的命令行参数转成了 JSON 格式。要点有两个布尔开关写成true或false不要写成字符串数值类参数保持与程序示例一致避免类型混用导致解析失败。api-listen打开本机监听而api-network保持关闭这样 API 只对本机开放避免实验目录里的工具被局域网其他设备扫到。启动时执行cgminer.exe -c cgminer.conf即可。注意修改 conf 后需要重启程序才生效程序不会热加载配置文件。另一个常见误用是矿池前缀写错把stratumtcp://写成http://程序会退回老式的 getwork 轮询方式现象是连接不报错但迟迟拿不到任务。这个差异在第 4 章会详细展开。3.3 GPU 三件套intensity、worksize 与 gpu-threads这三个参数是调优时最常动的地方也是翻车最多的地方。我的经验是固定两个只动一个每次调整后观察至少十分钟不要一次改三个。intensity 是最直观的负载旋钮。第一次跑实验从 8 到 9 起步确认驱动不崩溃、温度可控后再每次加 1 档往上探。加到某个档位后出现屏幕闪烁或驱动重置就回退两档作为日常使用值。worksize 和显卡内存带宽相关老卡通常适合 128 或 256驱动版本较新时可以试 512如果程序开始频繁报错优先往下调而不是往上调。gpu-threads 默认是 2加到 3 或 4 会明显增加整机功耗但对实际产出的提升往往不是线性的需要结合整机电源余量判断。推荐一轮调参顺序固定-I 9 -w 128 -g 1跑 15 分钟确认驱动和温度。只把-I升到 10观察 10 分钟。-w升到 256观察是否出现画面异常。最后再把-g提到 2观察 30 分钟。每一步只看两件事显卡驱动是否重置温度是否逼近目标上限。实验阶段没有真实矿池可看 Accepted 数字只要驱动不崩、温度可控这组参数就是可用的。3.4 参数改崩了怎样恢复按层回退的验证顺序参数调崩的表现通常是驱动重置、屏幕突然黑一下、或者程序闪退。恢复时不要急着删配置文件因为 conf 里的矿池地址和账号信息也是好不容易才调对的。我的恢复顺序是先杀进程再用一条保守命令启动cgminer.exe -I 8 -w 128 -g 1 -o stratumtcp://127.0.0.1:3333 -u test.worker1 -p 123456。如果这条能稳定跑说明问题出在 GPU 参数组合与网络配置无关。然后把 conf 里的 GPU 段全部改成保守值保留 pools 段不动重启验证。需要注意 JSON 格式不支持注释不要试图在 conf 里写解释文字程序解析时会直接报错。我会在旁边建一个tuning.txt每次改了哪个参数、当时的温度、跑了多久、是否崩了都记一笔。这个习惯比任何参数表都管用尤其是隔了几天再回来调时没有记录就等于从头再来。改崩之后的验证顺序进程能起来API 能返回数据日志在推进温度在目标范围以内最后才考虑恢复强度。每一步都确认了再走下一步不要一次性把参数拉回崩溃前的状态。4. 别只看界面cgminer 与矿池的通信细节和日志判读4.1 stratum 消息模型四条关键消息与状态机cgminer 3.7.2 是通过 TCP 长连接与矿池服务的通信协议是 stratum v1消息格式是一行一行的 JSON。掌握这套消息顺序比盯着界面上的 Accepted 数字有用得多。整个会话可以拆成四步。客户端启动后先发mining.subscribe订阅服务服务端返回会话标识和算力拼接参数接着客户端发mining.authorize提交账号信息服务端返回是否授权通过授权通过后服务端会主动推送mining.notify下发任务客户端算完后通过mining.submit提交结果。四种消息各有各的失败形态观察停在哪一步问题就定位在哪一层。这套模型让我在排障时不用读源码只看到达顺序就能缩小范围。如果消息一直停留在 subscribe 阶段说明双方协议版本对不上如果 subscribe 成功但 authorize 被拒绝问题在账号或地址如果 authorize 通过了但一直收不到 notify说明服务端认为客户端无法承接当前任务常见于新旧协议不兼容。4.2 日志判读哪三类问题分别长什么样3.7.2 的界面没有现代工具那种网页统计判断是否正常主要靠窗口顶部的状态行和下方日志区。状态行显示连接地址、算法、已运行时间以及右侧的 Accepted 与 Rejected 计数。日志区我只看四类信号。连接类问题会表现为反复出现连接失败提示先查端口通不通再看地址前缀是否写错。授权类问题会表现为账号登录失败一类的提示去核对用户名和 worker 名称是否完整。任务类问题比较隐蔽连接正常、授权通过但长时间没有新任务下发这时最可能是矿池服务端认为这个老客户端不兼容。结果类问题看 Rejected 计数是否异常上涨突然增多时要先确认系统时间是否准确再检查驱动是否已经处于不稳定状态不要急着去调强度。全屏终端日志滚动很快在慢速远程桌面环境下可能看起来像卡死。我的习惯是把窗口拉大先看右侧计数器是否在变化如果计数器在动只是界面刷新慢不用处理。不要一看界面不动就杀进程它可以靠 API 查询来做二次确认。4.3 本地跑一个最小 mock 矿池验证配置把外部矿池这个变量彻底拿掉通信链路的每一环就都可解释了。这里用 Python 的 socket 写一个最小 mock 服务监听本地 3333 端口实现 subscribe 和 authorize 的应答并在授权通过后周期性推送任务通知。import socket import json import threading import time def send_line(conn, obj): try: conn.sendall((json.dumps(obj) \n).encode()) except OSError: pass def push_jobs(conn): # 授权通过后模拟服务端周期下发任务通知 while True: time.sleep(5) notify { id: None, method: mining.notify, params: [ mock-job-001, # job_id 00 * 32, # prevhash占位 01000000, # coinb1占位 ffffffff, # coinb2占位 [], # merkle_branch 20000000, # version ffff001d, # nbits 00000000, # ntime True # clean_job ] } send_line(conn, notify) def handle(conn, addr): buf b authed False print(connected:, addr) while True: try: chunk conn.recv(4096) except OSError: break if not chunk: break buf chunk while b\n in buf: line, buf buf.split(b\n, 1) if not line.strip(): continue try: msg json.loads(line) except ValueError: continue mid msg.get(id) method msg.get(method) if method mining.subscribe: result [[[mining.set_difficulty, 00000002]], 4d6f636b, 4] send_line(conn, {id: mid, result: result, error: None}) elif method mining.authorize: send_line(conn, {id: mid, result: True, error: None}) if not authed: authed True threading.Thread(targetpush_jobs, args(conn,), daemonTrue).start() else: # mining.submit 等消息实验环境一律回 true send_line(conn, {id: mid, result: True, error: None}) conn.close() srv socket.socket() srv.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) srv.bind((127.0.0.1, 3333)) srv.listen(5) print(mock pool listening on 127.0.0.1:3333) while True: conn, addr srv.accept() threading.Thread(targethandle, args(conn, addr), daemonTrue).start()把这段保存为mock_pool.py先执行python mock_pool.py启动服务再在另一个窗口启动 cgminer。此时 cgminer 的日志里不会再刷连接失败而是能看到授权通过后的任务推送。mock 端每收到一条客户端消息都会打印出来双方的消息流可以直接对照。这个 mock 实现到“收到任务通知”这一层就够用了。要验证完整的提交行为还需要从真实矿池日志里抄一条完整的mining.notify作为模板替换到代码里注意字段顺序不能换。mock 的价值在于客户端本身的协议行为可以被单独验证参数调整产生的变化不会被矿池网络波动干扰。4.4 老版本与现网矿池的兼容边界3.7.2 发布年代对应的协议主要是 stratum v1 和 getwork 轮询。现在很多矿池服务端默认下发的任务格式已经不同体现在实际使用中就是连接正常、授权也通过但长时间等不到新任务或者任务刚下发就超时。这不是网络质量问题而是客户端与服务端在任务参数协商上不一致。遇到这种情况先回到本地 mock 环境确认客户端本身能正常收到任务通知再逐步排查服务端兼容策略。不要一上来就调强度、换驱动那样只会掩盖问题不会解决问题。URL 写法也是一个隐含边界。stratumtcp://走长连接协议http://走 getwork 轮询。老版本对两种方式都支持但同一份配置里混用前缀会让日志里的状态行变得难以解读。建议实验环境全部统一用stratumtcp://把变量控制在一处。5. 避坑清单这个老 Windows 包的五类翻车现场与排查顺序5.1 显卡驱动无响应屏幕闪一下后程序消失现象是运行一段时间后屏幕突然黑一下随后程序窗口消失事件查看器里能看到驱动程序已停止响应并已恢复的记录。这种情况最常出现在把 intensity 和 worksize 同时拉高的场景。原因有两层一是显卡驱动对单次任务缓冲大小有限制worksize 设置过高会触发驱动超时保护二是老程序没有现代的降频机制负载上来后温度快速爬升供电跟不上的时候就会掉驱动。解决方法是回退到-I 8 -w 128 -g 1的保守组合先让程序连续跑 30 分钟不崩再按第 3 章的节奏逐步加参数。这一步没有捷径跳过直接拉高只会重复崩溃。5.2 界面看起来卡死但任务管理器里进程占用很高现象是窗口停在某个画面不动按键盘没反应看起来像死锁但任务管理器里 cgminer 进程仍然占用着 CPU网络连接也还在。原因往往是全屏字符界面在特定环境下刷新失败而不是挖矿线程卡死。远程桌面、低配显卡或无 GPU 加速的虚拟机里最容易出现。解决方法是先不要杀进程用第 6 章的 API 查询方式读取运行时数据确认计数器是否还在增长。如果 API 返回正常只是界面渲染停了不影响继续跑如果 API 也长时间无响应再考虑强制结束进程。5.3 连接不报错但 Rejected 计数一直涨现象是状态行显示连接正常Accepted 数字也有增长但 Rejected 计数同步上涨比例接近一半甚至更高。原因通常有三个方向系统时间与矿池服务端偏差过大导致提交的任务时间戳不被接受--scrypt开关与矿池算法不匹配驱动已经处于不稳定状态产生的计算结果大量无效。排查顺序就是按这三个方向来先校时再确认算法开关最后降线程数测试。不要在没确认前调高强度负载只会加剧无效提交。5.4 安全软件把主程序当恶意文件隔离现象是今天还能启动明天安全软件更新特征库后主程序被隔离或者解压时直接提示发现风险。原因是老程序数字签名过期加上其行为特征与某些风险工具相似误判难以避免。解决方法是把实验目录加进排除列表然后重新解压并做一次哈希校验确认文件内容没有发生变化。不要为了方便关闭系统的整体防护也不要信任从不可靠渠道散播的“免杀版”程序那个方向的水太深。5.5 启动秒退屏幕上什么都不留现象是双击窗口闪一下就没了命令行下执行也只看到短暂的黑框没有任何报错文本。原因常见于三类VC 运行库缺失、显卡枚举失败、参数里某个关键项写错。解决方法是先用cmd /k cgminer.exe --help确认程序能正常输出帮助文本这能排除运行库问题然后单独执行cgminer.exe -c cgminer.conf把 conf 里的 GPU 参数全部改成保守值排除参数解析问题最后看系统事件查看器里的应用程序日志找到崩溃模块名如果指向显卡相关的动态库再去设备管理器确认驱动状态。6. 进阶用 API 和看门狗把老矿机变成无人值守实验台6.1 打开 API 并用一分钟脚本读取运行数据在命令行参数里加入--api-listen程序会监听本机 4028 端口。注意不要加--api-network让这个端口只对本机开放避免实验环境里的其他设备直接扫描到运行状态。API 是文本 socket 协议不是 HTTP不能用访问网页的方式来读取。用 PowerShell 写一个最小读取脚本$client New-Object System.Net.Sockets.TcpClient(127.0.0.1, 4028) $stream $client.GetStream() $writer New-Object System.IO.StreamWriter($stream) $writer.WriteLine({command:summary}) $writer.Flush() $reader New-Object System.IO.StreamReader($stream) $response $reader.ReadLine() $client.Close() $response这段脚本向 API 发送一行 JSON 命令然后读取返回的第一行文本。返回内容里有几个字段值得关注运行秒数、Accepted 计数、Rejected 计数。判断程序是否真正在干活就看运行秒数是否增长、Accepted 是否同步变化如果运行秒数在涨但 Accepted 一直不动说明连接链路处于“假活”状态需要回到第 4 章的 mock 环境验证任务下发。6.2 用计划任务做进程看门狗实验台不可能一直有人盯着看门狗脚本解决的是“程序没了自动拉起来”这个基础问题。我把下面这段 PowerShell 存为watchdog.ps1放到 Windows 任务计划程序里每 5 分钟执行一次。$alive Get-Process cgminer -ErrorAction SilentlyContinue if (-not $alive) { Start-Process -FilePath D:\mine-lab\cgminer.exe -ArgumentList -c, D:\mine-lab\cgminer.conf Add-Content -Path D:\mine-lab\watchdog.log -Value (restarted at (Get-Date)) }这段逻辑很简单检查 cgminer 进程是否存在不存在就启动并把重启时间写入日志。它只能解决进程消失的问题解决不了进程活着但通信已经断掉的情况。想做得更完整可以把 6.1 的 API 查询放进判活条件连续两次查询不到运行秒数增长就杀掉进程再拉起。我自己的习惯是每次调完参数都往tuning.txt记一笔参数组合、环境温度、跑了多久、观察到了什么现象。老工具没有现代面板但它的日志和 API 够你把每个环节拆开验证。如果你找的是能干活的现役方案3.7.2 不该进入你的选型如果你想理解矿机在网络上到底怎么说话、怎么被管理它比很多新工具都透明。希望帮到你。本文还有配套的精品资源点击获取
