Что такое дескрипторы в диспетчере задач
Перейти к содержимому

Что такое дескрипторы в диспетчере задач

  • автор:

Что такое дескриптор в архитектуре ПК?

Author24 — интернет-сервис помощи студентам

Добрый вечер!
В Диспетчере задач отображается количество дескрипторов. Не напомните, что это такое?
Спасибо.

94731 / 64177 / 26122
Регистрация: 12.04.2006
Сообщений: 116,782
Ответы с готовыми решениями:

Что такое дескриптор ?
Подскажите пожалуйста что представляет из себя дескриптор . Не могу разобраться ? в понятии это.

Что такое дескриптор сокета?
Дескриптор сокета — это целочисленное значение. Например: client_socket = accept(listen_socket.

Что такое базовый дескриптор элемента управления?
базовый дескриптор управления, что это? уникальный ID контрола?или код экземпляра контрола? .

Что такое файловый буфер? Что такое режим (модификатор) доступа, при работе с файлами?
Что такое файловый буфер? Что такое режим (модификатор) доступа, при работе с файлами?

327 / 157 / 14
Регистрация: 30.12.2014
Сообщений: 804
Записей в блоге: 3

Windows одновременно выполняет много программ, в основном служебных самой Windows. Точнее, квазиодновременно, процессор поочередно, очень быстро для нас, переключается на решение каждой из них. Каждая программа в терминах операционной системы считается отдельным процессом. Отдельные части многих задач могут выполняться какое-то время независимо, поэтому процессы часто делятся на несколько потоков, именно между их выполнением переключается процессор, точнее, каждое процессорное ядро (современные процессоры многоядерные) . Операционная система создает каждому процессу и каждому потоку специальную структуру данных, в которой указывается область памяти, в которой лежат данные потока, его приоритет и так далее. Эта структура данных называется дескриптором потока или процесса, дескрипторы имеют числовые имена — идентификаторы.

Преодолевая ограничения Windows: дескрипторы https://blogs.technet.microsof. 0/windows/
87844 / 49110 / 22898
Регистрация: 17.06.2006
Сообщений: 92,604
Помогаю со студенческими работами здесь

Что такое IIS и что такое PWS? Почему одно без другого не работает?
вот уже второй день пытаюсь немного разобраться в АСП. накидал небольшую тестовую страничку. но с.

Что такое рекурсивный тип данных? Что такое конструкция рекурсивного типа?
Что такое рекурсивный тип данных? Что такое конструкция рекурсивного типа?

Что такое напряжение и что такое сила тока с позиции заряженных частиц
Объясните пожалуйста, что такое напряжение и что такое сила тока с позиции заряженных частиц.

Что такое монитор и что такое мьютекс? Это же разные вещи?
Здравствуйте. В разных айти-статьях по-разному используют эти термины, причём часто их путают друг.

Или воспользуйтесь поиском по форуму:

Общие сведения о дескрипторах

Дескрипторы создаются вызовами API и определяют ресурсы.

  • Дескрипторные данные
  • Дескриптор дескриптора
  • Дескрипторы NULL
  • Дескрипторы по умолчанию
  • Связанные статьи

Дескрипторные данные

Дескриптор является относительно небольшим блоком данных, который полностью описывает объект gpu в непрозрачном формате gpu. Существует несколько различных типов дескрипторов: представления целевых объектов отрисовки (RTV), представления элементов глубины (DSV), представления ресурсов шейдера (SRV), неупорядоченные представления доступа (UAV), представления буферов констант (CBV) и примеры.

srv, cbv, uav, and sampler

Дескрипторы создаются вызовами API и включают такие сведения, как ресурс и карты MIP, которые требуется содержать дескриптор.

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

Дескрипторы объектов не должны быть освобождены или освобождены. Драйверы не присоединяют выделения к созданию дескриптора. Дескриптор может кодировать ссылки на другие выделения, для которых приложение владеет временем существования. Например, дескриптор для SRV должен содержать виртуальный адрес ресурса D3D (например, текстуры), на который ссылается SRV. Это ответственность приложения, чтобы убедиться, что он не использует дескриптор SRV, когда базовый ресурс D3D он зависит от уничтожен или изменен (например, объявлен как нересидент).

Основным способом использования дескрипторов является размещение их в кучах дескриптора, которые создают резервную память для дескрипторов.

Дескриптор дескриптора

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

Дескриптора ЦП предназначены для немедленного использования, например копирования, в котором необходимо определить источник и назначение. Сразу после использования (например, вызов ID3D12GraphicsCommandList::OMSetRenderTargets), их можно повторно использовать или их базовую кучу можно удалить.

Дескриптора GPU не предназначены для немедленного использования— они определяют расположения из списка команд для использования во время выполнения GPU. Они должны сохраняться до тех пор, пока все списки команд, ссылающиеся на них, полностью не выполняются.

Чтобы создать дескриптор для начала кучи, после создания самой кучи дескриптора вызовите один из следующих методов:

  • ID3D12DescriptorHeap::GetCPUDescriptorHandleForHeapStart
  • ID3D12DescriptorHeap::GetGPUDescriptorHandleForHeapStart

Эти методы возвращают следующие структуры:

Так как размер дескрипторов зависит от оборудования, чтобы получить увеличение между каждым дескриптором в куче:

Это безопасно для смещения начального расположения с рядом добавок, копирования дескрипторов и передачи дескрипторов в вызовы API. Небезопасно разыменовывать дескриптор, как если бы он был допустимым указателем ЦП, а также анализировать биты в дескрипторе.

Добавлены некоторые вспомогательные структуры с элементами инициализации, чтобы упростить управление дескрипторами.

Дескрипторы NULL

При создании дескрипторов с помощью вызовов API приложения передают значение NULL для указателя ресурса в определении дескриптора, чтобы добиться эффекта ничего связанного при доступе к шейдеру.

Остальная часть дескриптора должна быть заполнена как можно больше. Например, в случае представлений ресурсов шейдера (SRV) дескриптор можно использовать для различения типа представления (Texture1D, Texture2D и т. д.). Числовые параметры в дескрипторе представления, например число mipmap, должны быть заданы значения, допустимые для ресурса.

Во многих случаях существует определенное поведение для доступа к несвязанным ресурсам, таким как SRVs, возвращающие значения по умолчанию. Они будут учитываться при доступе к дескриптору NULL, если тип доступа шейдера совместим с типом дескриптора. Например, если шейдер ожидает SRV Texture2D и обращается к SRV NULL, определенному как Texture1D, поведение не определено и может привести к сбросу устройства.

В сводке, чтобы создать дескриптор NULL, передайте для параметра pResource при создании представления с такими методами, как CreateShaderResourceView. null Для параметра описания представления pDesc задайте конфигурацию, которая будет работать, если ресурс не имеет значения NULL (в противном случае может произойти сбой на некотором оборудовании).

Однако корневые дескрипторы не должны иметь значение NULL.

На оборудовании уровня 1 (см . аппаратные уровни, все дескрипторы, привязанные (с помощью таблиц дескриптора) должны быть инициализированы как реальные дескрипторы или пустые дескрипторы, даже если доступ к оборудованию недоступен, в противном случае поведение не определено.

На оборудовании уровня 2 это относится к привязанным дескрипторам CBV и UAV, но не к дескрипторам SRV.

На оборудовании уровня 3 нет ограничений на это, если неинициализированные дескрипторы никогда не обращаются.

Дескрипторы по умолчанию

Чтобы создать дескриптор по умолчанию для определенного представления, передайте допустимый параметр pResource в метод создания представления (например, CreateShaderResourceView), но передайте значение NULL для параметра pDesc. Например, если ресурс содержал 14 mips, представление будет содержать 14 mips. По умолчанию используется наиболее очевидное сопоставление ресурса с представлением. Для этого требуется, чтобы ресурс был выделен с полным именем формата (например , DXGI_FORMAT_R8G8B8A8_UNORM_SRGB , а не DXGI_FORMAT_R8G8B8A8_TYPELESS).

Дескрипторы по умолчанию нельзя использовать с представлением структуры ускорения луча, так как предоставленный параметр pResource должен иметь значение NULL, а расположение должно передаваться через D3D12_RAYTRACING_ACCELERATION_STRUCTURE_SRV.

Зомби, которые съедают вашу память

Что бы вы там себе не думали, а зомби существуют. И они действительно едят мозги. Не человеческие, правда, а компьютерные. Я говорю сейчас о зомби-процессах и потребляемых ими ресурсах. Это будет душераздирающая история о потерянных и снова найденных 32 ГБ оперативной памяти. Возможно, лишь некоторые из вас столкнутся с точно такой же проблемой, но если вдруг это произойдёт — у вас хотя бы будет шанс понять, что происходит.

Начнём с того, что компьютеры под управлением ОС Windows склонны со временем терять память. Ну, по крайней мере, у меня, при моём способе ими пользоваться. После пары недель без перезагрузок (или, например, всего одного уикэнда за который я 300 раз пересобрал Хром) я стал замечать, что диспетчер задач начинает показывать мне очень маленькое количество свободной оперативной памяти, но в то же время в системе нет никаких процессов, которые эту самую память активно используют. В том примере выше (с 300 сборками Хрома) диспетчер задач сказал мне, что в системе занято 49.8 ГБ плюс ещё 4.4 ГБ памяти сжато — но при этом запущено всего несколько процессов, и все они в сумме даже и близко не используют столько памяти:

image

В моём компьютере 96 ГБ оперативной памяти (да, я счастливчик) и когда у меня нет вообще никаких запущенных процессов — я, знаете ли, хотел бы видеть ну хотя бы половину этой памяти свободной. Я правда рассчитываю на это. Но иногда этого достичь не удаётся и мне приходится перезагружать ОС. Ядро Windows написано качественно и надёжно (без шуток), так что память не должна бы пропадать бесследно. Но всё же она пропадает.

Первой же моей догадкой стало воспоминание о том, что один из моих коллег как-то жаловался на зомби-процессы, которые иногда остаются в ОС уже не активными, но всё же ещё не до конца удалёнными ядром. Он даже написал специальную утилиту, которая выводит список таких процессов — их имена и количество. Когда он запускал эту утилиту в своих тестах, то получал до нескольких сотен зомби-процессов на обычной Windows-машине. Я нашел его инструмент, запустил на своём компьютере и получил… 506 000 зомби-процессов. Да, 506 тысяч!

Я вспомнил, что одной из возможных причин перехода процесса в состояние «зомби» может быть то, что какой-то другой процесс держит открытым его дескриптор (handle). В моём случае большое количество зомби-процессов играло мне на руку — им было сложнее скрыться. Я просто открыл диспетчер задач и добавил на вкладку Details столбец с количеством открытых дескрипторов для каждого процесса. Затем отсортировал список по убыванию значений в этом столбце. Я сразу нашел героя данной истории — процесс CcmExec.exe (часть Microsoft System Management Server) имел 508 000 открытых дескрипторов. Это было во-первых, очень много, а во-вторых, подозрительно близко к найдненному мною выше числу в 506 000 зомби-процессов.

image

Я убил процесс CcmExec.exe и получил следующий результат:

image

Всё получилось ровно так, как я того и ожидал. Как я без иронии писал выше — ядро Windows написано очень хорошо и когда процесс уничтожается, то и все занятые им ресурсы освобождаются. Закрытие CcmExec.exe освободило 508 000 дескрипторов, что дало возможность окончательно закрыть 506 000 зомби-процессов. Количество свободной оперативной памяти мгновенно выросло на 32 ГБ. Тайна раскрыта!

Что такое зомби-процесс?

До этого момента мы ещё не выяснили, что же заставило все эти процессы зависнуть в неопределённости, а не быть удалёнными. Похоже на то, что мы имеем дело с тривиальным багом в приложении (а не в ядре ОС). Общее правило гласит, что когда вы создаёте процесс, то получаете его дескриптор и дескриптор его главного потока. Вы ОБЯЗАНЫ закрыть эти дескрипторы. Если вашей задачей было просто запустить процесс — их можно закрыть сразу же (это не убъёт запущенный процесс, а просто разорвёт связь вашего процесса с ним). Если новый процесс вам для чего-то нужен (например, вы ждёте окончания его работы или вам нужен код, который он вернёт) — то нужно воспользоваться соответствующими функциями (например, WaitForSingleObject(hProcess, INFINITE) для ожидания выхода или GetExitCodeProcess(hProcess, &exitCode) для получения кода возврата) и всё-равно закрыть дескрипторы после того, как вы получили от дочернего процесса всё, чего хотели. Аналогично следует и поступать и с дескрипторами процессов, которые вы для чего-нибудь открываете с помощью функции OpenProcess().

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

Куда же девается память?

Ещё одним инструментом, который я использовал в своём исследовании, была утилита RamMap. Она показывает использование каждой страницы памяти. На вкладке Process Memory мы видим сотни тысяч процессов, каждый из которых занимает 32 КБ оперативной памяти — очевидно, это и есть наши зомби. Но ~500 000 раз по 32 КБ будет равно примерно 16 ГБ — куда же делась остальная память? Сравнение состояния памяти до и после закрытия зомби-процессов даёт ответ на этот вопрос:

image

Мы можем чётко увидеть, что ~16 ГБ уходит на Process Private Memory. Также мы видит, что ещё 16 ГБ приходится на Page Table Memory. Очевидно, что каждый зомби-процесс занимает 32 КБ в таблице страниц памяти и еще 32 КБ использует для своей личной памяти. Я не знаю для чего зомби-процессу так много памяти, но, наверное, никто никогда не думал, что число таких процессов может измеряться сотнями тысяч.

Некоторые типы занятой памяти увеличились после закрытия процесса CcmExec.exe, в основном это касается Mapped File и Metafile. Я не знаю точно, почему так получилось. Одной из моих догадок является то, что ОС решила, что свободной памяти теперь достаточно и что-то себе закешировала. Это, в общем, не плохо. Мне не жаль памяти для нужд ОС, я просто не хочу, чтобы она пропадала совсем уж бесцельно.

Важное замечание: RamMap тоже открывает дескрипторы всех процессов, так что эту утилиту следует закрыть, если вы хотите добиться закрытия зомби-процессов.

Я написал твит о моей находке и исследование продолжил другой программист, который сумел воспроизвести данный баг и передать информацию о нём разработчику из Microsoft, который сказал, что это «известная проблема, которая иногда случается, когда очень много процессов запускаются и закрываются очень быстро».

Я надеюсь, что данная проблема будет скоро исправлена.

Почему у меня на компьютере возникают такие странные проблемы?

Я работаю над кодом Windows-версии Хрома и одной из моих задач является оптимизация его сборки на этой ОС, а это требует многократных запусков этой самой сборки. Каждая сборка Хрома запускает огромное множество процессов — от 28 000 до 37 000 в зависимости от выбранных настроек. При использовании нашей распределённой системы сборки (goma) эти процессы создаются и закрываются очень быстро. Мой лучший результат сборки Хрома — 200 секунд. Но столь агрессивная политика запуска процессов выявляет и проблемы в ядре Windows и её компонентах:

  • Быстрое удаление процессов ведёт к зависаниям пользовательского ввода
  • Драйвер тачпада выделяет, но не освобождает память при каждом создании процесса
  • App Verifier создаёт O(n^2) лог-файлов (и об этом стоит написать отдельный пост!)
  • Есть баг в ядре Windows, который касается буферизации файлов, и этот баг воспроизводится на всех Windows от Server 2008 R2 до Windows 10
  • Windows Defender задерживает запуск каждого процесса goma на 250 мс

Что дальше?

Если вы работаете не на компьютере, управляемом политиками компании, то процесс CmmExec.exe у вас не запущен и с конкретно данным багом вы не столкнётесь. Также он коснётся вас только если вы собираете Хром или делаете ещё что-то похожее, создавая и закрывая при этом десятки тысяч процессов в короткие промежутки времени.

CcmExec — не единственная в мире программа с багами. Я нашел много других, содержащих в себе конкретно этот же тип ошибок, приводящих к созданию зомби-процессов. И есть ещё огромное множество тех, которые я не нашел.

Как знают все опытные программисты, любая ошибка, которая не была явно исправлена или предупреждена — точно когда-то произойдёт. Просто написать в документации «Пожалуйста, закройте этот дескриптор» — не достаточно. Так что вот мой вклад в то, чтобы сделать нахождение подобного типа ошибок проще, а их исправление — реальнее. FindZombieHandles — это инструмент, основанный на NtApiDotNet и коде от @tiraniddo, который выводит список зомби-процессов и информацию о том, кто сделал их зомби. Вот пример вывода данной утилиты, запущенной на моём компьютере:

274 total zombie processes. 249 zombies held by IntelCpHeciSvc.exe(9428) 249 zombies of Video.UI.exe 14 zombies held by RuntimeBroker.exe(10784) 11 zombies of MicrosoftEdgeCP.exe 3 zombies of MicrosoftEdge.exe 8 zombies held by svchost.exe(8012) 4 zombies of ServiceHub.IdentityHost.exe 2 zombies of cmd.exe 2 zombies of vs_installerservice.exe 3 zombies held by explorer.exe(7908) 3 zombies of MicrosoftEdge.exe 1 zombie held by devenv.exe(24284) 1 zombie of MSBuild.exe 1 zombie held by SynTPEnh.exe(10220) 1 zombie of SynTPEnh.exe 1 zombie held by tphkload.exe(5068) 1 zombie of tpnumlkd.exe 1 zombie held by svchost.exe(1872) 1 zombie of userinit.exe

274 зомби — это ещё не так плохо. Но уже и это указывает на определённые проблемы, которые могут быть найденны и исправлены. Процесс IntelCpHeciSvc.exe в этом списке имеет самые большие проблемы — похоже на то, что он открывает (и забывает закрыть) дескриптор процесса каждый раз, когда я открываю видео в Windows Explorer.

Visual Studio забывает закрыть дескрипторы как минимум двух процессов, в одном случае это воспроизводится всегда. Просто запустите сборку проекта и подождите ~15 минут пока процесс MSBuild.exe закроется. Можно также выставить опцию “set MSBUILDDISABLENODEREUSE=1” и тогда MSBuild.exe закроется сразу по окончанию сборки и потерянный дескриптор будет виден сразу. К сожалению, какой-то негодяй в Microsoft исправил эту проблему и фикс должен выйти в обновлении VS 15.6, так что поторопитесь воспроизвести её, пока это ещё работает (надеюсь, не нужно объяснять, что это была шутка и никакой он на самом деле не негодяй).

Также вы можете использовать для просмотра забытых процессов программу Process Explorer, сконфигурировав её нижнюю панель так, как это показано ниже (заметьте, что в этом случае будут показаны забытые дескрипторы как для процессов, так и для потоков):

image

Вот пару примеров найденных багов (о некоторых сообщено разработчикам, но не о всех):

  • Утечка в CcmExec.exe (описанный выше случай с 500 000 зомби) — разработчики работают над исправлением
  • Утечка в Program Compatibility Assistant Service — проблема исследуется
  • Утечка в devenv.exe + MSBuild.exe (проблема уже исправлена)
  • Утечка в devenv.exe + ServiceHub.Host.Node.x86.exe (багрепорт отправлен)
  • Утечка в IntelCpHeciSvc.exe + Video.UI.exe для каждого открытого видеофайла (Intel приняла багрепорт и переслала его в Lenovo)
  • Утечка в RuntimeBroker.exe + MicrosoftEdge и Video.UI.exe (возможно, имеет отношение к некоторым другим багам в RuntimeBroker.exe)
  • Утечка в AudioSrv + Video.UI.exe
  • Утечка в одном внутреннем инструменте Google из-за использования старой версии psutil
  • Утечка в утилитах от Lenovo: tphkload.exe теряет один дескриптор, SUService.exe теряет три
  • Утечка в Synaptic’s SynTPEnh.exe

image

Используя Process Explorer, я заметил, что NVDisplay.Container.exe открывает ~5000 дескрипторов на событие \BaseNamedObjects\NvXDSyncStop-61F8EBFF-D414-46A7-90AE-98DD58E4BC99, создавая новый дескриптор каждые две минуты. Я так понимаю, они хотят быть супер-уверены в том, что могут остановить NvXDSync? Багрепорт Nvidia отправлен.

image

Corsair Link Service создаёт ~15 дескрипторов в секунду, не освобождает их совсем. Багрепорт отправлен.

Adobe’s Creative Cloud теряет тысячи дескрипторов (около 6500 в день, по моим подсчётам). Багрепорт отправлен.

Удивительно, что никто до этого особо не обращал внимание на подобные баги. Эй, Microsoft, возможно, стоит собирать статистику по таким случаям и что-то предпринимать по этому поводу? Эй, Intel и Nvidia, почистите немного ваш код. Помните, я наблюдаю за вами.

А теперь вы можете взять утилиту FindZombieHandles, запустить её на вашей машине и рассказать о своих находках. Также вы можете использовать в экспериментах диспетчер задач и Process Explorer.

  • Блог компании Инфопульс Украина
  • Системное программирование
  • Google Chrome
  • Отладка
  • Системы сборки

Что обозначают в диспетчере задач, счётчик потоков и дескрипторы?

это пищеварительный тракт винды. Потоки-это процедуры программ, дескрипторы-это числа или структуры для взаимодействия процессов.

Супер_ЭнималМастер (2462) 10 лет назад
потоки это файлы открытые для передачи, а дескрипторы это управляющие команды потоками?
GrayМыслитель (5748) 10 лет назад

поток-это исполняемый код в отдельной области памяти, они служат для того, чтобы процесс не ждал выполнения долгоиграющих функций и мог заниматься другими делами. А дескриптор-это грубо говоря случайное число, присвоенное устройствам ввода-вывода.

Остальные ответы

Windows одновременно выполняет много программ, в основном служебных самой Windows. Точнее, квазиодновременно, процессор поочередно, очень быстро для нас, переключается на решение каждой из них. Каждая программа в терминах операционной системы считается отдельным процессом. Отдельные части многих задач могут выполняться какое-то время независимо, поэтому процессы часто делятся на несколько потоков, именно между их выполнением переключается процессор, точнее, каждое процессорное ядро (современные процессоры многоядерные) . Операционная система создает каждому процессу и каждому потоку специальную структуру данных, в которой указывается область памяти, в которой лежат данные потока, его приоритет и так далее. Эта структура данных называется дескриптором потока или процесса, дескрипторы имеют числовые имена — идентификаторы.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *