简介：这是加密货币挖矿软件 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 stratum+tcp://127.0.0.1:3333 -u test.worker1 -p 123456 -I 9 -w 256解释一下每个参数的作用：--scrypt把算法切换到 scrypt 路径，不指定时默认走 SHA256；-o指定矿池地址，这里用stratum+tcp://前缀表明走长连接协议，而不是 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 算法路径 | 不指定时走默认 SHA256 |
| GPU | -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": "stratum+tcp://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 后需要重启程序才生效，程序不会热加载配置文件。另一个常见误用是矿池前缀写错：把stratum+tcp://写成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 stratum+tcp://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(target=push_jobs, args=(conn,), daemon=True).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(target=handle, args=(conn, addr), daemon=True).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 写法也是一个隐含边界。stratum+tcp://走长连接协议，http://走 getwork 轮询。老版本对两种方式都支持，但同一份配置里混用前缀会让日志里的状态行变得难以解读。建议实验环境全部统一用stratum+tcp://，把变量控制在一处。
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 不该进入你的选型；如果你想理解矿机在网络上到底怎么说话、怎么被管理，它比很多新工具都透明。希望帮到你。
本文还有配套的精品资源，点击获取
