Por que o 'csrss.exe' é chamado toda vez que eu movo o mouse?

Question

Após minhas botas windows xp sp3 e todas as atividades de cpu, observei o que acontece quando eu apenas movo o mouse em círculos em um local vazio na área de trabalho: Primeiro exporer.exe é chamado e, em seguida, csrss.exe .

No artigo da wikipedia para csrss.exe , diz algo como

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]

O que me faz acreditar que os movimentos do mouse também são tratados por win32k.sys - mas talvez eu não entenda isso.

Alguém pode juntar as peças? Estou curioso sobre o motivo exato da ligação. Obrigado.

    

Answer 1

Não me lembro onde o li, mas o csrss.exe lida com a tarefa de renderizar o ponteiro do mouse. É provavelmente faz mais sentido para csrss.exe para lidar com isso porque está bem posicionado para entregar mensagens para qualquer aplicativo win32, uma vez que todos os aplicativos win32 executam "sob".

    

Answer 2

O csrss em csrss.exe significa subsistema cliente / servidor. É a parte que fala com win32k.sys que - depois que essa parte foi movida para o modo kernel (usada no modo de usuário para NT 3.51) - é responsável (como o nome indica) por grande parte da funcionalidade "GUI" do subsistema Win32 (incluindo mensagens de janela).

No Windows, existe vários subsistemas e, por padrão, quando você trabalha na área de trabalho ou executa um serviço do Windows, você estará usando um programa vinculado ao subsistema Win32. Entre outras coisas, isso implica que kernel32.dll será carregado (como primeira ou segunda DLL, dependendo da versão exata do Windows) no programa na inicialização.

A maioria das chamadas kernel32.dll acaba no próprio kernel (via ntdll.dll no modo de usuário para ntoskrnl.exe no modo kernel), enquanto as chamadas de user32.dll terminam com mais frequência em win32k.sys . Funcionalidade diferente, lugar diferente onde eles acabam. Essa também é a explicação final sobre o motivo pelo qual o movimento do mouse leva a uma chamada para o subsistema cliente-servidor. csrss.exe é o subsistema Win32 e, portanto, responsável por todos os detalhes cruciais específicos do subsistema Win32, como mensagens de janela. Fontes, janelas, etc não são cidadãos de primeira classe no kernel, enquanto mutexes, eventos, arquivos são. Mas o tratamento para o primeiro ainda foi movido para o kernel por sua extensão win32k.sys que até obtém sua própria tabela de descritor de serviço do sistema (SDT ou SSDT) que é usada para chamar os serviços do kernel do modo de usuário de maneira segura. p>

Btw: se você tiver um desassemblador ou alguma ferramenta como dumpbin (vem com o Visual Studio), você mesmo pode verificar:

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

Será dado um Windows 7 x64 (quando executado de dentro de 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)

Subsistema "Nativo" na verdade significa não subsistema no Windows. Ou seja Ele fala diretamente com a API nativa (que não tem muitas limitações das APIs do Win32). Drivers de modo kernel não possuem subsistema, ou seja, "subsistema nativo". Além disso, alguns dos programas executados antes de winlogon.exe , como smss.exe , que na verdade geram winlogon.exe , são "programas nativos". Um bom exemplo aqui é autochk.exe , que é responsável por verificar o sinalizador "dirty" nos sistemas de arquivos e executar uma verificação do sistema de arquivos se estiver definido.

Um exemplo de uma API nativa seria NtCreateFile versus Win32 CreateFile . É preciso um livro para explicar os detalhes, no entanto. Consulte "Internos do Windows" de Russinovich para obter uma visão geral e a "Referência da API nativa do Windows NT / 2000" de Nebbett para alguns dos detalhes. Veja também undocumented.ntinternals.net e Segredos não documentados do Windows 2000 ...