Почему `csrss.exe` вызывается при каждом перемещении мыши?

Question

После загрузки Windows XP SP3 и снижения активности всех процессоров я заметил, что происходит, когда я просто перемещаю мышь по кругу в пустом месте на рабочем столе: сначала exporer.exe а затем csrss.exe .

В статье в википедии csrss.exe говорится что-то вроде

Когда процесс пользовательского режима вызывает функцию, включающую консольные окна, создание процесса / потока или параллельную поддержку, вместо системного вызова библиотеки Win32 (kernel32.dll, user32.dll, gdi32.dll) отправляют межпроцессный вызов к процессу CSRSS, который выполняет большую часть реальной работы без ущерба для ядра. [1] Менеджер окон и сервисы GDI обрабатываются драйвером режима ядра (win32k.sys). [2]

Что заставляет меня верить, что движения мыши также обрабатываются win32k.sys - но, возможно, я неправильно понимаю это.

Может кто-нибудь собрать кусочки вместе? Мне интересно узнать точную причину звонка. Благодарю.

Answer 1

Я не могу вспомнить, где я это читал, но csrss.exe выполняет задачу рендеринга указателя мыши. Вероятно, наиболее целесообразно для csrss.exe справиться с этим, поскольку он способен доставлять сообщения в любое приложение win32, поскольку все приложения win32 выполняются "под" ним.

Answer 2

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)

Даст на Windows 7 x64 (при запуске изнутри 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" от Nebbett для некоторых подробностей. Также см undocumented.ntinternals.net и Недокументированные секреты Windows 2000 ...