Why is `csrss.exe` called every time I move the mouse?

Solution 1:

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.

Solution 2:

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 ...