Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

After my windows xp sp3 boots and all cpu activity dimms, I observed what happens when I just move the mouse in circles on an empty spot on the desktop: First exporer.exe is called and then csrss.exe.

In the wikipedia article to csrss.exe it says something like

When a user-mode process calls a function involving console windows, process/thread creation, or Side-by-Side support, instead of issuing a system call, the Win32 libraries (kernel32.dll, user32.dll, gdi32.dll) send an inter-process call to the CSRSS process which does most of the actual work without compromising the kernel.[1] Window manager and GDI services are handled by a kernel mode driver (win32k.sys) instead.[2]

Which makes me believe mouse movements as well are handled by win32k.sys - but maybe I misunderstand that.

Can someone put the pieces together? I'm curious about the exact reason for the call. Thanks.

share|improve this question
add comment

2 Answers

up vote 2 down vote accepted

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.

share|improve this answer
    
thanks for this information! –  panny Feb 22 '13 at 3:09
add comment

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

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.