出现 0x000001B4 COREMSG_OUT_OF_HANDLES 时，通常意味着某个核心消息组件在调用 Windows API 创建句柄时被系统拒绝。0x000001B4 是十六进制错误码，十进制为 436。它不是标准的 Win32 错误代码，而是组件或驱动自定义的状态映射，其实际含义与句柄耗尽直接相关。句柄可以理解为操作系统为进程持有的对象分配的一个索引，文件、事件、线程、进程、互斥体、信号量、窗口、GDI 绘图对象等都会占用句柄或类似的对象配额。一旦长期运行的服务持续创建对象却没有释放，错误就会以 COREMSG_OUT_OF_HANDLES 的形式暴露出来。
处理这类问题不能只看进程的 CPU 和内存占用。很多服务在句柄泄漏初期内存增长并不明显，但句柄数量会稳步上升。Windows 对进程句柄数没有公开的固定硬上限，进程句柄表可以动态扩展，但它仍受制于非分页内存池、系统范围内的对象数量以及注册表中对 GDI 和 USER 对象的配额。尤其是涉及窗口、菜单、位图、设备上下文等图形对象时，默认配额可能只有一万个，达到后就会创建失败。因此看到 COREMSG_OUT_OF_HANDLES 时，应同时检查内核句柄数和 GDI/USER 对象数。
0x000001B4 错误码背后的句柄机制
句柄是 Windows 内核对象管理机制的核心概念。调用 CreateFile、CreateEvent、CreateThread 等函数成功后，内核会在对应的句柄表中安插一条记录，并把索引返回给调用者。应用通过该句柄访问对象；使用完毕后必须调用 CloseHandle 关闭。如果创建后没有关闭，句柄表就会保留这条记录，即使对象本身已经不再使用，系统也无法回收相关内核内存和非分页池分配。对于核心消息组件来说，每一条待处理消息或每个连接对象都可能至少对应一个事件句柄或线程句柄，一旦出现泄漏，数量会非常迅速地扩大。
错误码 0x000001B4 在该场景下并不是指某个具体对象创建失败，而是表示创建动作已达到资源上限。除了进程句柄表满，常见原因是非分页池不足。非分页池是内核始终驻留物理内存的一块区域，进程无法换出，如果驱动或内核组件大量申请却不释放，系统会首先出现池内存告警，随后各种资源创建开始失败。部分服务在创建句柄失败后会把错误码转换成 COREMSG_OUT_OF_HANDLES 写入事件日志，因此这一提示经常与系统事件 ID 2019 同时出现。
下面是一段典型的句柄泄漏代码：
HANDLE hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);
if (hEvent != NULL) {
// 业务处理，这里忘记 CloseHandle(hEvent)
SetEvent(hEvent);
}
每次调用这段代码都会泄漏一个事件句柄。若这段逻辑处于高频循环、定时回调或网络请求处理中，运行几小时后句柄数量就可能到达万级，最终返回 0x000001B4。
如何快速定位句柄泄漏来源
定位句柄泄漏的第一步是找出哪个进程的句柄数在持续增加。任务管理器默认不显示句柄列，可以在详细信息页签的表头右键选择“选择列”，勾选“句柄数”。打开后按照句柄数降序排列，观察长时间运行的服务进程是否每几分钟就增加几个或几十个句柄。对于短生命周期的进程，句柄数偏低是正常的；需要重点关注那些启动后很少退出、句柄数却线性上涨的进程。
如果服务器上不方便使用图形界面，可以用 PowerShell 直接获取句柄数最高的进程。下面命令会列出当前句柄数最多的十个进程：
Get-Process | Sort-Object HandleCount -Descending | Select-Object -First 10 Name, Id, HandleCount
得到可疑进程 ID 后，可以进一步使用 Sysinternals 工具集中的 handle.exe 查看该进程到底打开了哪些句柄。例如进程 ID 为 4321，执行以下命令：
handle.exe -p 4321
输出中会按类型列出句柄，例如 File、Event、Thread、Semaphore、Process。如果发现某个类型数量异常多，比如 Event 句柄高达数千个，就说明核心消息组件可能在重复创建事件。也可以在 Process Explorer 中打开目标进程的属性，切换到句柄面板，按类型或名称排序，直接观察哪些对象没有释放。重点关注名称中带有 Temp、pipe、message、queue 等字样的对象，它们往往是业务模块泄漏的关键。
常见触发场景与修复方法
COREMSG_OUT_OF_HANDLES 常见于消息处理服务、文件监控服务、网络代理、中间件和数据库连接池。典型触发条件是每次收到请求时创建一个或多个事件对象，任务结束后只释放业务对象但没有关闭事件；或者在异步回调中创建线程句柄，线程退出后没有调用 CloseHandle。某些 .NET 程序在调用带有 WaitHandle 的 API 时没有使用 CancellationTokenSource 进行释放，也会导致内核事件句柄不断增长。数据库连接层如果每次操作都打开连接却不关闭，虽然表现为数据库连接池耗尽，但底层也可能对应文件句柄和网络句柄的堆积。
修复时优先从业务代码中消除句柄泄漏。对于无法立即改代码的场景，可以先尝试限制队列上限，避免消息堆积进一步扩大句柄需求。比如创建信号量时设置较小的最大计数，或者把无界队列改为有界队列，上游降级或拒绝请求。还可以减少不必要的句柄缓存，不要在内存中保留大量临时文件句柄或事件对象，尽量缩短对象生命周期。
如果确认程序本身管理良好，但系统对象配额过低，可以检查注册表项 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows 下的 GDIProcessHandleQuota 和 USERProcessHandleQuota。某些终端服务或 Session 0 服务环境中为了限制用户资源可能会调低这些值。默认一般是一万，适当调高到一万八千可以缓解 GDI/USER 对象耗尽，但修改后需要重启生效。需要注意的是，这个操作不能根治内核句柄泄漏，只能为图形对象提供更多余量。
代码层面如何避免重复出现
修复句柄泄漏最可靠的方式是使用 RAII 机制管理资源。C++ 程序应尽量避免直接暴露裸 HANDLE，而是在对象析构时自动关闭句柄。下面的封装让事件句柄在离开作用域时自动调用 CloseHandle：
struct HandleDeleter {
void operator()(HANDLE h) const {
if (h != NULL) {
CloseHandle(h);
}
}
};
using UniqueHandle = std::unique_ptr<void, HandleDeleter>;
UniqueHandle CreateAutoEvent() {
return UniqueHandle(CreateEvent(NULL, FALSE, FALSE, NULL));
}
这种写法将句柄的生命周期与对象绑定，不会因为异常路径或提前 return 而忘记释放。对于 C# 程序，可以使用 SafeHandle 或 using 声明来管理文件、互斥体和等待句柄。例如 File.Open 配合 using var 会自动释放底层文件句柄；对于 WaitHandle 派生类，应在 using 块中创建，或通过 CancellationTokenSource 统一释放等待资源。异步编程中特别注意事件回调里的 CancellationTokenRegistration 和 ManualResetEventSlim，使用完后需要 Dispose。
除了局部资源管理，还应在模块设计上设置资源池上限和监控告警。消息处理组件可以在创建资源前检查当前活跃句柄数，如果超过阈值则延迟处理或主动失败，而不是继续向系统索要资源。上线后接入性能计数器，监控进程的 Handle Count、GDI Objects 和 USER Objects，当这些指标连续增长且不回落时触发告警。这样可以在错误码 0x000001B4 出现之前介入，避免服务长时间中断。
最后，如果事件日志中频繁出现 0x000001B4，并且已经排除了应用代码问题，还应升级或更换相关驱动及核心消息组件版本。一些旧版组件在调用系统 API 时错误处理不完善，可能将普通的资源分配失败统一包装成 COREMSG_OUT_OF_HANDLES。更新补丁和驱动后，错误定位会更准确，也能减少因为兼容性引起的非分页池异常消耗。
0x000001B4COREMSG_OUT_OF_HANDLESWindows句柄修改时间：2026-10-06 17:18:39