Как исправить ERROR_TOO_MANY_DESCRIPTORS в Windows

Что такое дескриптор файла

Дескриптор файла — целое значение, которое операционная система использует для обозначения открытых файлов, сокетов, каналов и других I/O-ресурсов. Проще: это «ручки» на ресурсы, которые процессы открывают и должны закрывать после использования.

Ключевой момент: когда процесс открывает слишком много дескрипторов и не закрывает их, система или приложение перестаёт открывать новые ресурсы, что и вызывает ошибку ERROR_TOO_MANY_DESCRIPTORS.

Почему это происходит на Windows 10 и 11

• Серверные приложения или службы, обрабатывающие множество одновременных соединений, могут исчерпать доступные дескрипторы.
• Некоторые приложения некорректно закрывают дескрипторы после использования — это называется утечкой дескрипторов.
• Низкие значения параметров сети в реестре могут ограничивать количество одновременно доступных портов или время ожидания закрытых соединений.

Важно: Windows не имеет жёсткого глобального лимита, аналогичного POSIX, но системные настройки и поведение приложений могут приводить к эффектам, похожим на исчерпание дескрипторов.

Пошаговое решение

Убедитесь в резервной копии реестра

Важно создать резервную копию перед правками реестра. В редакторе реестра (Regedit) используйте Файл > Экспорт, чтобы сохранить текущую ветку.

1. Увеличьте параметры сети в реестре

1. Нажмите Win + R, введите regedit и нажмите Enter, чтобы открыть Редактор реестра.
2. Перейдите в ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.
3. Правый клик по свободному месту → Новое → DWORD (32-бит) → назовите MaxUserPort.
4. Дважды кликните по MaxUserPort и задайте значение 65534 в десятичной системе.
5. Создайте ещё DWORD со именем TcpTimedWaitDelay и задайте значение 30 в десятичной системе.
6. Закройте редактор реестра и перезагрузите компьютер.

Пояснение: MaxUserPort увеличивает верхний предел портов для исходящих соединений, TcpTimedWaitDelay уменьшает время, в течение которого закрытые соединения остаются в состоянии TIME_WAIT. Эти параметры помогают уменьшить исчерпание сетевых ресурсов при большом количестве короткоживущих соединений.

Важно: изменять реестр рекомендуется только если вы понимаете влияние на сеть и имеете резервную копию.

2. Отслеживайте и управляйте открытыми файлами и дескрипторами

1. Нажмите Win + R, введите resmon и нажмите Enter, чтобы открыть Resource Monitor.
2. Перейдите на вкладку CPU и разверните секцию Associated Handles.
3. Введите имя процесса или часть пути и посмотрите, какие хэндлы открыты.
4. Выявите процессы с большим количеством открытых дескрипторов и перезапустите или остановите проблемные службы.

Альтернативные инструменты:

• Process Explorer от Sysinternals — позволяет смотреть количество хендлов и открытые объекты процесса.
• handle.exe (Sysinternals) — консольный инструмент для поиска открытых файлов/дескрипторов.
• netstat -ano — показывает список активных сетевых соединений и PID процессов.

3. Исправление со стороны приложения

• Попросите разработчиков проверить код на утечки дескрипторов: всегда закрывать файлы, потоки и сокеты в блоке finally или использовать конструкции с автоматическим освобождением (например, using в C#).
• Для сервисов и демонов настройте ротацию логов, пул соединений и лимиты одновременных клиентов.

4. Обновите драйверы и операционную систему

Если ошибка появилась после установки нового оборудования, обновите драйверы устройства. Также убедитесь, что установлены последние обновления Windows и самого приложения — разработчики часто исправляют утечки ресурсов.

Проверочный план и критерии приёмки

Критерии приёмки

• Ошибка ERROR_TOO_MANY_DESCRIPTORS больше не воспроизводится при корректных сценариях использования.
• Количество открытых дескрипторов у ключевых процессов стабилизируется и не растёт бесконечно.
• Нагрузка сервера соответствует ожидаемым метрикам (количество соединений, CPU, память).

Тестовые шаги

1. Выполнить нагрузочное тестирование, имитируя целевое число соединений.
2. Наблюдать за числом открытых дескрипторов через Process Explorer и Resource Monitor.
3. Проверить, что после завершения сессий число дескрипторов возвращается к исходному уровню.

При успешном прохождении всех шагов можно считать проблему решённой.

Руководство по инциденту для администратора

1. Зафиксировать время и логи ошибки.
2. Идентифицировать процесс с наибольшим количеством дескрипторов.
3. Перезапустить проблемный сервис.
4. Применить временное решение: рестарт службы или выделение больше ресурсов.
5. Применить постоянное решение: правки конфигурации, код, реестр, обновления.
6. Оповестить владельца приложения и разработчиков, прикрепив логи и снимки Resource Monitor.

Чеклист ролей

Администратор

• Сделать бэкап реестра.
• Изменить MaxUserPort и TcpTimedWaitDelay при необходимости.
• Перезапустить службу и систему.

Разработчик

• Проверить код на утечки дескрипторов.
• Использовать конструкции автоматического освобождения ресурсов.
• Провести нагрузочные тесты.

Служба поддержки

• Собрать логи и описать шаги воспроизведения.
• Предоставить временные обходные пути пользователю.

Когда это решение не помогает и альтернативы

• Если проблема вызвана архитектурной ошибкой приложения, правки реестра не помогут — нужно фиксить утечку в коде.
• Если это аппаратная несовместимость, потребуется обновление драйверов или замена оборудования.
• В высоконагруженных сценариях рассмотрите горизонтальное масштабирование приложения или использование балансировщиков нагрузки.

Альтернативные подходы

• Ограничивать число одновременно обрабатываемых соединений на уровне приложения.
• Использовать пул соединений вместо создания/закрытия для каждого запроса.
• Внедрить очередь запросов и бэпрешал (backpressure) для управления притоком.

Полезные команды и сниппеты

• Открыть Resource Monitor: Win + R → resmon
• Просмотр сетевых соединений с PID: netstat -ano
• Process Explorer: используйте поиск по PID и колонку Handles для оценки числа дескрипторов
• Комментарий для разработчиков C#:

// Используйте using для автоматического закрытия ресурсов
using (var stream = File.OpenRead(path))
{
    // обработка
}

Часто задаваемые вопросы

Вопрос: Почему Windows сообщает об этой ошибке, если у неё нет жёсткого лимита? Ответ: Хотя глобального POSIX-подобного лимита нет, системные параметры, поведение приложений и сетевые состояния приводят к исчерпанию доступных ресурсов для конкретного процесса.

Вопрос: Опасны ли изменения MaxUserPort и TcpTimedWaitDelay? Ответ: Это стандартные настройки сети; они влияют на поведение исходящих портов и время ожидания. Вносите изменения аккуратно и с резервной копией реестра.

Итоги

• Основные шаги: сделать бэкап реестра, увеличить MaxUserPort и уменьшить TcpTimedWaitDelay, найти и исправить утечки дескрипторов в приложениях, мониторить через Resource Monitor и Sysinternals.
• Если проблема систематическая, работайте с разработчиками и рассматривайте масштабирование или архитектурные изменения.

Если нужно, могу подготовить шаблон записи инцидента с полями для логов и снимков Resource Monitor или помочь составить запрос в службу поддержки разработчика приложения.