Почему `csrss.exe` вызывается при каждом перемещении мыши?
После загрузки Windows XP SP3 и снижения активности всех процессоров я заметил, что происходит, когда я просто перемещаю мышь по кругу в пустом месте на рабочем столе. Сначала exporer.exe
называется, а затем csrss.exe
,
В статье в Википедии csrss.exe
это говорит что-то вроде
Когда процесс пользовательского режима вызывает функцию, включающую консольные окна, создание процесса / потока или поддержку Side-by-Side, вместо системного вызова библиотеки Win32 (kernel32.dll, user32.dll, gdi32.dll) отправляют межпроцессный вызов к процессу CSRSS, который выполняет большую часть реальной работы без ущерба для ядра.[1] Менеджер окон и сервисы GDI обрабатываются драйвером режима ядра (win32k.sys).[2]
Что заставляет меня верить, что движения мыши тоже обрабатываются win32k.sys
- но, возможно, я неправильно понимаю это.
Может кто-нибудь собрать кусочки вместе? Мне интересно узнать точную причину звонка. Благодарю.
2 ответа
Я не могу вспомнить, где я это читал, но csrss.exe выполняет задачу рендеринга указателя мыши. Вероятно, наиболее целесообразно для csrss.exe справиться с этим, поскольку он способен доставлять сообщения в любое приложение win32, поскольку все приложения win32 выполняются "под" ним.
csrss
в csrss.exe
обозначает клиент / серверную подсистему. Это та часть, которая говорит с win32k.sys
который - после того, как эта часть была переведена в режим ядра (раньше она была в пользовательском режиме для NT 3.51) - отвечает (как следует из названия) за большую часть функциональности GUI подсистемы Win32 (включая оконные сообщения).
В Windows существует несколько подсистем, и по умолчанию, когда вы работаете на рабочем столе или запускаете службу Windows, вы будете использовать программу, привязанную к подсистеме Win32. Среди прочего это означает, что kernel32.dll
будет загружен (как первая или вторая DLL, в зависимости от точной версии Windows) в программу при запуске.
Большинство из kernel32.dll
вызовы заканчиваются в самом ядре (через ntdll.dll
в режиме пользователя для ntoskrnl.exe
в режиме ядра), тогда как звонки из user32.dll
в конечном итоге чаще всего в win32k.sys
, Разная функциональность, другое место, где они в конечном итоге. Это также окончательное объяснение того, почему ваше движение мыши приводит к вызову подсистемы клиент-сервер. csrss.exe
является подсистемой Win32 и, следовательно, отвечает за все подробности, относящиеся к подсистеме Win32, такие как оконные сообщения. Шрифты, окна и т. Д. Не являются первоклассными гражданами в ядре, а мьютексы, события, файлы -. Но обработка для первого все еще была перенесена в ядро его расширением win32k.sys
которая даже получает свою собственную таблицу дескрипторов системных служб (SDT или SSDT), которая используется для безопасного вызова служб ядра из пользовательского режима.
Кстати, если у вас есть дизассемблер или какой-то инструмент, как dumpbin
(поставляется с Visual Studio) вы можете проверить это сами:
for %i in (user32.dll ntdll.dll kernel32.dll ntoskrnl.exe win32k.sys) do @(echo %i & dumpbin /headers %i|findstr subsystem)
Даст на винду 7 х64 (при запуске изнутри C:\Windows\System32
):
user32.dll
6.01 subsystem version
2 subsystem (Windows GUI)
ntdll.dll
6.01 subsystem version
3 subsystem (Windows CUI)
kernel32.dll
6.01 subsystem version
3 subsystem (Windows CUI)
ntoskrnl.exe
6.01 subsystem version
1 subsystem (Native)
win32k.sys
6.01 subsystem version
1 subsystem (Native)
"Собственная" подсистема фактически означает отсутствие подсистемы в Windows. Т.е. он напрямую взаимодействует с нативным API (который не имеет многих ограничений API Win32). Драйверы режима ядра не имеют подсистемы, то есть "собственной подсистемы". Также некоторые из программ, которые запускаются до winlogon.exe
такие как smss.exe
который на самом деле порождает winlogon.exe
являются "родными программами". Один хороший пример здесь autochk.exe
который отвечает за проверку флага "грязный" в файловых системах и запуска проверки файловой системы, если он установлен.
Примером нативного API будет NtCreateFile
против Win32 CreateFile
, Однако для объяснения деталей нужна книга. Обратитесь к "Внутренним компонентам Windows" Руссиновича за обзором и "Справочнику по Windows API для Windows NT/2000" Неббетта для некоторых подробностей. Также см. Undocumented.ntinternals.net и Недокументированные секреты Windows 2000...