Warum wird `csrss.exe 'jedes Mal aufgerufen, wenn ich die Maus bewege?

Ich kann mich nicht erinnern, wo ich es gelesen habe, aber csrss.exe erledigt die Aufgabe, den Mauszeiger zu rendern. Es ist wahrscheinlich am sinnvollsten, wenn csrss.exe damit umgeht, da es gut positioniert ist, um Nachrichten an jede Win32-Anwendung zu übermitteln, da alle Win32-Anwendungen "darunter" laufen.

The csrss in csrss.exe stands for client/server subsystem. It is the part that talks to win32k.sys which - after this part got moved into kernel mode (used to be in user mode for NT 3.51) - is responsible (as the name implies) for much of the Win32 subsystem's "GUI" functionality (including window messages).

In Windows several subsystem exists and by default when you work on the desktop or run a Windows service you'll be using a program tied to the Win32 subsystem. Among other things this implies that kernel32.dll will be loaded (as first or second DLL, depending on the exact Windows version) into the program at startup.

Most of the kernel32.dll calls end up in the kernel itself (via ntdll.dll in user mode to ntoskrnl.exe in kernel mode), whereas calls from user32.dll end up most often in win32k.sys. Different functionality, different place where they end up. This is also the ultimate explanation as to why your mouse movement leads to a call to the client-server subsystem. csrss.exe is the Win32 subsystem and hence responsible for all the gory details that are specific to the Win32 subsystem, such as window messages. Fonts, windows etc are not first class citizens in the kernel, whereas mutexes, events, files are. But the handling for the former has still been moved to the kernel by its extension win32k.sys which even gets its own system service descriptor table (SDT or SSDT) which is used to call kernel services from user mode in a safe manner.

Btw: if you happen to have a disassembler or some tool like dumpbin (comes with Visual Studio) you can check it yourself:

for %i in (user32.dll ntdll.dll kernel32.dll ntoskrnl.exe win32k.sys) do @(echo %i & dumpbin /headers %i|findstr subsystem) 

Will give on a Windows 7 x64 (when run from inside 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) 

"Native" subsystem actually means no subsystem in Windows. I.e. it talks directly to the native API (which doesn't have many limitations of the Win32 APIs). Kernel mode drivers have no subsystem, i.e. "native subsystem". Also some of the programs that run before winlogon.exe such as smss.exe which actually spawns winlogon.exe are "native programs". One good example here is autochk.exe which is responsible for checking the "dirty" flag on the file systems and run a file system check if it's set.

An example of a native API would be NtCreateFile versus Win32 CreateFile. It takes a book to explain the details, however. Refer to Russinovich's "Windows Internals" for an overview and to Nebbett's "Windows NT/2000 Native API Reference" for some of the gory details. Also see undocumented.ntinternals.net and Undocumented Windows 2000 Secrets ...