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

I can't remember where I read it but csrss.exe does handle the task of rendering the mouse pointer. It's probably makes the most sense for csrss.exe to handle it because it's well positioned to deliver messages to any win32 application, since all win32 applications run "under" it.

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