企业官网建设流程全解析

简介：这份压缩包是 cgminer 3.7.2 的 Windows 平台版本，定位为加密货币挖矿与区块链技术学习工具，适合矿工、矿场运维人员以及想研究挖矿软件原理的开发者。它提供了在 Windows 系统中驱动 GPU、ASIC、FPGA 等设备并执行 Sha256、Scrypt 等算法的完整方案，可帮助用户快速搭建可运行的挖矿环境。包内共有 36 个文件，压缩后体积约 3.12 兆字节，主要包含说明文档、动态链接库、内核文件、配置文件四大类：文档用于解读各模块功能与启动参数；链接库保障程序运行时的依赖；内核文件负责算法在显卡或矿机上的执行；配置文件用于设定矿池、矿工名、频率等参数。此外还提供可执行程序以及 PHP、C、Python 多语言接口示例，方便做远程监控或脚本管理。目前已有 170 人学习下载。通过这份资源，读者既能直接运行主程序体验挖矿流程，也能对照说明文档理解常见配置项与底层机制，参考接口示例编写自己的管理工具，从整体架构到局部实现都能获得较为完整的认知，是一份兼具实用性与学习价值的经典资源包。

1. 一个十年前的 Windows 挖矿客户端，为什么到现在还有人找它

cgminer-3.7.2-windows.rar 这个压缩包，是 cgminer 3.7.2 在 Windows 下的预编译版本。cgminer 是开源挖矿软件里生命周期最长的名字之一，而 3.7.x 恰好卡在一个特殊位置：它既保留了完整的 GPU 挖矿能力，又能驱动当年的 USB 与串口矿板，是“显卡还能挖、ASIC 刚起步”那个交叉时代的典型产物。如果你手里有一张吃灰多年的老 A 卡，或者从某个角落淘到一块 USB 矿板，这款老软件反而是比任何新工具都顺手的配套方案。

这个打包版本对三类人最有用。一是想复现当年矿机配置的硬件玩家，3.7.2 的参数模型朴素直接，比现在封装了一层又一层的新矿工好理解；二是想研究挖矿客户端内部逻辑的开发者，它的日志、API、调度队列都是裸的，方便拆；三是还在维护老教学设备或旧矿场的运维，需要一套不依赖新框架、解压就能跑的 Windows 方案。它解决的场景很窄，但在这条窄路上，它至今仍然是最可靠的答案。

下面所有操作都基于这份 rar 解压后的 32 位程序。我只讲自己验证过的路径：解压、装依赖、写配置、调参数、排错。具体版本差异以你手头实际文件为准，但思路不会变。

2. 解压与首次启动：从 rar 到矿机界面只有三步

2.1 从 cgminer-3.7.2-windows.rar 里拿到的是哪些文件

以我见过的主流 3.7.2 Windows 打包为例，rar 解开后通常就是这么几个文件：cgminer.exe、cgminer-api.exe、libusb-1.0.dll、pthreadGC2.dll，外加一份 README 或示例配置。整个包体积很小，因为它本身只是一个命令行程序加运行库，界面是经典的字符终端风格。

有几个容易误判的点先说清楚。第一，cgminer.exe 是 32 位程序，在 64 位 Windows 上通过 WOW64 机制运行，这本身不是问题，但后面排错时所有依赖路径都要按 32 位来查。第二，包里没有 OpenCL.dll，这是最常被冤枉的一处——OpenCL 运行库由显卡驱动提供，解压目录里找不到它完全正常。第三，cgminer-api.exe 不是多余的，它是 Windows 下访问程序内置 API 的小工具，后面章节会专门用它。

3.7.2 之后，cgminer 在更高版本里逐步把 GPU 支持砍掉，所以如果你想用 GPU 挖矿，只能守在这批 3.x 版本上。这也是这个 rar 至今还有人找的核心原因：它不只是“老”，它是某个功能分水岭之前的最后一批完整实现。

2.2 装依赖：三个 DLL 缺失里有两个是假缺失

解压用 7-Zip 最省事，Windows 自带解压对老 rar 分卷和压缩参数支持不全。命令就一行：

7z x cgminer-3.7.2-windows.rar -oD:\oldrig

解压后进入目录确认文件齐全：

cd /d D:\oldrig\cgminer-3.7.2-windows dir

如果运行时报缺 dll，按这个顺序排查。libusb-1.0.dll 和 pthreadGC2.dll 应该在解压目录里，缺了就从包里重新解压，别去系统目录翻。OpenCL.dll 要查两个位置：C:\Windows\System32 和 C:\Windows\SysWOW64。32 位程序加载的是 SysWOW64 里那份，很多人只装了 64 位驱动组件，结果 System32 里有、SysWOW64 里没有，程序照样起不来。缺的话去显卡厂商官网装完整版驱动，这是最稳的路径。

还有一类是 VC++ 运行库缺失，报错会指向 msvcr100.dll 之类。3.7.2 年代的预编译包不少依赖微软 VC++ 2010 运行库，装一个 2010 的 x86 版本就能覆盖。判断依据很简单：报错弹窗里出现的 dll 名字是 msvcr 开头还是 OpenCL 开头，直接决定你去装驱动还是装运行库。

2.3 最小命令跑起来：先看帮助，再谈挖矿

不要一上来就填矿池参数。先确认程序能在当前系统里正常启动：

cgminer.exe --help

这一步看似多余，实际上能滤掉一半环境问题。如果 --help 能打印出整屏参数说明，说明 dll 依赖基本没问题；如果它直接闪退或者报 dll 缺失，那就是上一节的问题，先解决再继续。

帮助信息能正常输出后，用一个最小命令验证挖矿链路：

cgminer.exe --scrypt --url stratum+tcp://scrypt.example.com:3333 --user myname.worker01 --pass x

这里 --scrypt 表示切换成 scrypt 算法内核，不带这个参数默认走 SHA-256。--url 指定矿池的 stratum 地址，--user 和 --pass 是矿池账号和工人密码，这三个参数也可以写成 -o、-u、-p。程序启动后进入字符界面，能看到实时算力、已提交份额、拒绝份额、显卡温度和风扇转速。

第一次运行建议只做一件事：盯着界面看两分钟，确认 GPU 温度在正常范围、份额计数在往上走。不要急着改参数，基线先立住。

提示：如果矿池要求特定端口或备用地址，先翻矿池文档确认，stratum 端口和普通网页端口不是一回事。

3. 算法选型与矿池配置：sha256 和 scrypt 的参数不能混着用

3.1 两种算法分支的边界在哪

3.7.2 支持两类内核，默认是 SHA-256，加 --scrypt 切到 scrypt。这两个分支的调参逻辑几乎完全相反，混着用是新手最容易翻车的地方。SHA-256 是计算密集型，GPU 核心频率和整数运算能力决定算力，显存不是瓶颈；scrypt 是内存带宽敏感型，它的内核会为每个线程分配约 128KB 的显存，线程并发数直接决定显存占用。

我用一张表总结两边的差异，后面调参都基于这张表：

为什么不能混着用？因为内核在启动时按算法编译，scrypt 内核默认会为每个线程预分配足量显存，如果你把 sha256 的参数直接套到 scrypt 上，最常见的结果是启动时 OpenCL 申请显存失败，或者跑几分钟后显存溢出、驱动重置。反过来，把 scrypt 的大线程并发带到 sha256 上，除了白白占资源，没有任何收益。

3.2 多矿池与 cgminer.conf 的正确写法

3.7.2 支持同时配置多个矿池自动切换。主池掉线后会按顺序尝试备用池，这个行为的细节由参数控制。第一次配置建议把全部参数写进 cgminer.conf，而不是堆在命令行里——命令行一长，改动一个数字就要重敲整条，非常容易出错。

配置文件是 JSON 格式，示例：

{ "scrypt": true, "intensity": "13", "worksize": "256", "thread-concurrency": "8192", "gpu-engine": "1000-1050", "gpu-memclock": "1400", "gpu-fan": "75", "auto-fan": true, "api-listen": true, "api-port": "4028", "api-network": false, "retries": "3", "retry-pause": "10", "queue": "2", "expiry": "120", "pools": [ { "url": "stratum+tcp://scrypt.example.com:3333", "user": "myname.worker01", "pass": "x" }, { "url": "stratum+tcp://scrypt-backup.example.com:3333", "user": "myname.worker01", "pass": "x" } ] }

pools 数组里的顺序就是切换优先级，第一个为主池。没写 --failover-only 时，程序默认会在多个池之间做负载分担；如果只想“主池死了才用备用池”，在配置里加一行 "failover-only": true。

运行方式就干净了：

cgminer.exe -c cgminer.conf

几个关键网络参数的含义和我的习惯初值：

queue 调大能减少网络抖动带来的停顿，但 scrypt 模式下每个排队任务都占显存，别盲目调大。expiry 太小会导致任务频繁作废，太大又会让矿池端的反馈变迟钝，120 秒是我用过最稳的起点。保存配置也可以直接在运行界面按 W（部分小版本是 S，看底部按键提示），程序会把当前实时的全部参数原样写进 cgminer.conf，比手写 JSON 省事，但记得先关掉不想保存的实验参数。

4. 把性能压出来：intensity、线程并发和 GPU 频率怎么配合

4.1 三个核心参数的“手感”，不是越大越好

GPU 调参有三个绕不开的参数：intensity、worksize、thread-concurrency。网上各种“神参数”满天飞，但同一个参数在不同驱动、不同分辨率、不同温度下表现都不一样。我的建议是把它们当成三个旋钮，先理解各自控制什么，再一起拧。

intensity 控制每个 GPU 线程塞进去的工作量，范围 0～20，从本质上说它决定内核展开的规模。开得太低，GPU 计算单元喂不饱；开得过高，结果就是丢时间片、拒绝率飙升，算力数字看着高但有效份额反而跌。worksize 是 OpenCL 内核的局部工作规模，常见值 64、256、512，对性能影响不像另外两个那么敏感，一般固定 256 或 512 就好。thread-concurrency 是 scrypt 模式下的关键参数，它决定内核创建多少并发线程，内存占用约等于“线程数 × 128KB”。一张 2GB 显存的显卡，TC 开 8192 就要吃掉约 1GB 显存，剩下得留给系统和其他进程。

调参的顺序我一般固定为：先把 TC 按显存算好一个确定值，再去调 intensity 从低往高加，每次加 1，跑 10 分钟看平均值和拒绝率。拒绝率超过 2% 就回头降一档。最后才动 gpu-engine 和 gpu-memclock 做频率微调。实测中最常见的错误是上来就把 intensity 开到 18、TC 拉满，然后花半小时排查显卡驱动崩溃。

一个相对稳妥的 scrypt 起步命令：

cgminer.exe -c cgminer.conf --intensity 13 --worksize 256 --thread-concurrency 8192 --gpu-engine 1000,1050 --gpu-memclock 1400 --gpu-fan 80

--gpu-engine 的 "1000,1050" 是“最低-最高”区间写法，程序会在区间内自动变频；如果只想固定频率，就写一个值。--gpu-fan 直接指定风扇转速百分比，老显卡的温控逻辑很粗糙，我一般直接锁在 70～80，省得温度过山车。

4.2 打开 API，把黑匣子变成白盒

cgminer 自带一个轻量 API 服务，默认监听 4028 端口。3.7.2 的 Windows 包配套的 cgminer-api.exe 就是干这个的。开启方式在上一节的配置里已经写了：api-listen 设为 true，api-network 保持 false，这样只允许本机访问，不往局域网暴露。

查询命令：

cgminer-api.exe summary cgminer-api.exe gpu cgminer-api.exe pools

summary 返回的是全局概况，重点看 KHS av（平均算力）、KHS 5s（最近 5 秒瞬时算力）、ACC（已接受份额）、REJ（拒绝份额）、HW（硬件错误数）。gpu 返回每张卡的细节，包括温度、风扇转速、核心频率和当前强度。

怎么判断状态是否健康？ACC 稳定增长说明提交链路正常；REJ 占比持续高于 2%，优先怀疑参数过激或网络延迟；HW 数值应该长期不变，只要它在涨，说明 GPU 频率超出稳定点了，降频而不是降 intensity。温度超过 85 摄氏度就不要再加频率，老显卡的散热规模扛不住持续满负荷，我见过不止一块卡因为矿刚温度过高直接花屏报废。

注意：改完参数不要只盯前 10 秒的峰值算力，那通常是假象。至少跑 20 分钟看 KHS av 的平均趋势，曲线平稳才是真的稳。

5. 老程序活在新系统上的五个坑，逐个拆给你看

5.1 启动就报找不到 OpenCL.dll

现象：双击 cgminer.exe，弹窗提示找不到 OpenCL.dll，或者程序窗口一闪即退。 原因：这个 rar 包本身不带 OpenCL 运行库，它属于显卡驱动。32 位程序加载的是 C:\Windows\SysWOW64\OpenCL.dll，如果你的显卡驱动只装了精简版，或者系统里只有 64 位 OpenCL 组件，就会缺失。 解决：先同时检查 System32 和 SysWOW64 两个目录有没有 OpenCL.dll；没有就去显卡官网装完整版驱动，装完重启再试。不建议从网上单独下载 dll 塞进系统目录，来源不明的东西不值得为它赌一台机器。

5.2 显卡明明在，却显示 0 devices

现象：启动日志打印 CL platform 0，后面跟着 devices: 0，或者只枚举到 CPU 设备，GPU 就是不出现。 原因：显卡驱动太新，老 cgminer 的 OpenCL 调用方式和新驱动实现之间存在兼容裂痕；笔记本双显卡环境下，程序默认枚举到的可能是核显而不是独显。 解决：先在桌面右键把程序指定给独立显卡运行；如果还不行，换回显卡厂商当年配套的老版本驱动。我的经验是 Windows 7 加对应年代的驱动最稳，实在不行就在设备管理器里暂时禁用核显再跑一次，确认是不是枚举顺序问题。

5.3 USB 矿板插上没反应，扫描永远是 0

现象：设备管理器里能看到一个未知设备或带感叹号的设备，cgminer 启动显示 0 serial devices，怎么刷新都扫不到。 原因：这类 USB 矿板通常需要 libusb/WinUSB 驱动，rar 包里的 libusb-1.0.dll 是程序运行库，不是设备驱动，两者不是一回事。系统默认分配给的驱动不匹配，程序自然枚举不到。 解决：用开源驱动加载工具 Zadig，把该 USB 设备的驱动替换为 WinUSB，替换后设备管理器里会显示 WinUSB Device。然后给 --scan-time 留足枚举时间，默认单位是毫秒，我习惯调到 20000，确保慢速设备有时间完成握手。扫描时间调大不影响性能，只是启动时多等几秒。

5.4 拒绝率越来越高，算力看着猛但有效份额在跌

现象：界面 REJ 计数涨得比 ACC 还快，矿池后台显示大量无效提交，但 GPU 占用率看着是满的。 原因：多半是参数过激。intensity 太高导致内核丢时间片，或者核心频率超得太多产生计算错误，HW 计数会同步上涨；还有一种可能是矿池网络延迟太高，share 提交超过了矿池的接受窗口。 解决：先降 --gpu-engine 20～30MHz，再降两档 intensity，跑 20 分钟看 HW 是否停止增长。网络问题用 ping 看延迟和丢包，如果确认是网络，调大 queue 和 expiry 让本地有更多缓存任务缓冲抖动。

5.5 Win10 或 Win11 下双击秒退

现象：在 Windows 10/11 上运行，有的版本滚一屏日志就消失，有的直接闪退；极端情况下初始化 OpenCL 时弄到蓝屏。 原因：这是十年前的控制台程序，新版系统的控制台渲染、驱动调用路径和它存在兼容问题。程序本体没坏，是环境变了。 解决：右键 cgminer.exe，属性，兼容性，勾选“以兼容模式运行”，选 Windows 7，再勾选“禁用全屏优化”。如果还不行，我的建议是不要在这个坑上耗太久，直接上 Win7 虚拟机或另找一台老机器跑实机实验，时间成本更低，结果也更接近当年的真实表现。

6. 用一个看门狗脚本，把它变成无人值守的后台矿机

前面所有参数都稳定之后，剩下的事就是让它长时间跑。字符界面程序最麻烦的是崩溃后没人管，解决方案是一个循环检测的批处理脚本，进程没了就自动拉起，同时把日志落盘。

@echo off cd /d D:\oldrig\cgminer-3.7.2-windows :loop tasklist /FI "IMAGENAME eq cgminer.exe" 2>nul | find /I "cgminer.exe" >nul if errorlevel 1 ( echo [%date% %time%] restart >> watch.log start "" /min cmd /c "cgminer.exe -c cgminer.conf >> run.log 2>&1" ) timeout /t 30 /nobreak >nul goto loop

tasklist 加过滤条件只查 cgminer 进程，find 判断结果为空说明进程挂了，进入重启分支。每次重启把时间戳写进 watch.log，矿机程序自身的输出重定向到 run.log，保留现场。timeout 30 秒循环一次，既不会漏掉长时间停机，也不会因为检测太频繁干扰系统。

配套的监控循环用 cgminer-api.exe 定时抓一次摘要：

:api cgminer-api.exe summary >> api.log timeout /t 60 /nobreak >nul goto api

这两个循环可以用两个最小化窗口分别跑，api.log 里的 KHS、温度、份额数据积累一段时间后，直接拉进表格就能看到算力曲线。我现在折腾任何老矿卡，第一件事就是把 watch.log 和 api.log 挂好，先跑一夜再看曲线，而不是守着字符界面等瞬时数据。这条习惯帮我少走了很多弯路，希望帮到你。

本文还有配套的精品资源，点击获取