Windows环境子系统进程(CSRSS.EXE，简称CSRSS）是ＷＩＮＤＯＷＳ子系统的服务器进程。尽管从ＮＴ４开始，窗口管理（包括屏幕输出、用户输入和消息传递）和ＧＤＩ的主体实现移入到内核(win32k.sys)中，但ＣＳＲＳＳ仍然是ＷＩＮＤＯＷＳ子系统的灵魂，它监管着系统内运行着的所有ＷＩＮＤＯＷＳ进程和线程，每个进程在创建后都要到它这里注册登记后方能运行，退出时也要到这此报告注销。除了掌管着各个进程的“生死存亡”，ＣＳＲＳＳ在桌面管理、终端登录、控制台管理、ＨＡＮＤＥＲＲＯＲ报告和ＤＯＳ虚拟机等方面也起着重要作用。总之，把ＣＳＲＳＳ称为ＷＩＮＤＯＷＳ系统的“大内总管”不算为过。ＣＳＲＳＳ身担如此多的重任，所以ＷＩＮＤＯＷＳ系统真的离不开它，如果尝试强行杀死ＣＳＲＳＳ进程（使用ＫＩＬＬ或其他工具），那么系统便会以蓝屏(BSOD,BLUE SCREEN OF DEATH)结束。


尽管ＣＳＲＳＳ在ＷＩＮＤＯＷＳ系统中地位重要，但关于它的介绍却如凤毛麟角。就连著名的ＷＩＮＤＯＷＳ内幕一书对它的介绍也如蜻蜓点水。微软的文档也从未见过关于ＣＳＲＳＳ原理和设计的正式介绍，在ＭＳＤＮ中搜索一下，找到的大多都是ＣＳＲＳＳ有关的系统故障信息。因此，可以说ＣＳＲＳＳ是ＷＩＮＤＯＷＳ世界中被“保密”的最好的模块之一。这种神秘性使得很多ＷＩＮＤＯＷＳ领域的老将也不大熟悉ＣＳＲＳＳ这个名字，更不知道它长什么样。有时竟还以为它是病毒呢。不过不管你是否熟悉它，ＣＳＲＳＳ始终在每一个ＷＩＮＤＯＷＳ系统（不包括３.X或更早的ＷＩＮＤＯＷＳ）中运行着，而且起着不可土地替代的作用。


那么是不是真的没有必要了解ＣＳＲＳＳ呢？ＮＯ，因为其地位的重要性，要了解某些ＷＩＮＤＯＷＳ机制（如进程管理，控制台窗口，用户态调试，Ｈarderror等），探索它又变的无法回避。


没有文档，没有代码，如何了解ＣＳＲＳＳ呢？对于这样的难题，调试跟踪无疑是最佳利刃，然而这也不是件容易的事。


首先，因为ＣＳＲＳＳ是ＷＩＮＤＯＷＳ的关键进程，关乎系统安全之大计，所以缺省状态下，系统是禁止ＣＳＲＳＳ的调试的。别外对于ＷＩＮＤＯＷＳ２０００或之前的版本，ＣＳＲＳＳ是调试子系统的一部分，所以如要不启动特别选项，调试对话也是无法建立和工作的。

其次，不要以为这个大内总管很悠闲，在一个典型的ＷＩＮＤＯＷＳ　ＸＰ系统中，ＣＳＲＳＳ通常有十几个工作纯种在打理着系统的日常工作，虽然它们总共占用的ＣＰＵ资源也就在１~２%左右，使用ＰＳＴＡＴ观察一下，你会发现它们大多数是忙碌着的，模式切换次数很高，说明它们频繁奔走在内核态和用户态之间。更严重的是，当我们在调试器调试ＣＳＲＳＳ时，那么中断到调试器必然导致ＣＳＲＳＳ进程被挂起（ＷＩＮＤＯＷＳ系统还不充许以线程为单位建立调试会话），那么他的所有线程也就被挂起了，于是整个ＷＩＮＤＯＷＳ便如凝固了一样，我们也就无法继续在其上作任何事了。

tid 线程ＩＤ;pri　线程的优先级;　Ｃtx Switch 模式切换;StrtAddr 起始地址;User Time　在用户态运行的时间;Kernel Time 在内核态运行的时间;State 线程状态


Pid (进程ＩＤ)：4cc;pri(优先级):13;Hnd(句柄):895;pF(Page Fault,内存页交换次数):104959;Ws(工作集):10980k csrss.exe.


解决第一个问题的方法是通过修改ＷＩＮＤＯＷＳ的全局标志来启用对ＣＳＲＳＳ的调试。全局标志是一个３２位的整数，每一位对应一个选项。控制ＣＳＲＳＳ调试的标志位叫FLG_ENABLE_CSRDEBUG,其所在位对应的16进制数是0X20000.通过以下两种方法之一可以设置FLG_ENABLE_CSRDEBUG标志（你应该有管理员权限）;

直接修改注册表，将如下表键中的GlobaFlag（ＲＥＧ_ＤＷＯＲＤ）值，将其当前值与0X20000作或运算。
HKLM\system\CurrentControlSet\Control\Session?Manager

使用Gflags工具，直接执行gflags/r+20000或者通过图形界面选中“Enable debugging of Wind32 Subsystem”

需要重新启动系统以上改动才能生效。但由于我们后面的操作还要重新启动系统，所以大家可以统筹安排合适进行重新启动。

解决第二个问题的方法是使用两个ＷＩＮＤＯＷＳ系统，即使用一个ＷＩＮＤＯＷＳ系统来调试另一个ＷＩＮＤＯＷＳ系统中的ＣＳＲＳＳ。这需要分两步来做：

第一步，使用ＷinDbg工具在两个ＷＩＮＤＯＷＳ系统间建立内核调试对话。WinDbg是微软公司的免费调试工具，可以从微软网站免费下载，链接如下：
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
两个Windows系统可以是物理上的两个ＰＣ上的ＷＩＮＤＯＷＳ;或者使用一台电脑利用Virtual Pc来安装第二个windows系统。如果使用两台ＰC,那么可以使用串口线(Null Modem)或1394(firewire)线建立连接;如果使用Virtual Pc,那么可以利用管道模拟串口连接。

对于前一种方法，ＷinDbg的帮助文件有非常详细的说明，不再赘述。对于如何使用Ｖirtual Pc和ＶＭＷare进行内核调试，请参考以下链接中的文章：

http://advdbg.org/blogs/advdbg_system/articles/130.aspx

第二步，在被调试的windows系统(debuggee)中，使用ＮＴＳＤ调试ＣＳＲＳＳ。ＮＴＳＤ是ＷinDbg软件包中包含的另一个调试工具，它支持命令行下工作，还支持通过内核调试会话将输入和输出定向到另一台机器上，我们正是利用这一功能来在第二台Windows（debugger）中控制ＮＴＳＤ实现对ＣＳＲＳＳ的调试。ＮＴＳＤ支持复杂的命令行选项，对于我们的用途，其命令行应该为:

nstd -d -g -G -o -pd <CSRSS 进程ＩＤ>

-d表示将输入和输出（通过DbgPrint）定向到另一个ＷＩＮＤＯＷＳ中的WinDbg中;-g表示忽略被调试进程的初始断点，如果不加此开关，那么将ＮＴＳＤ附加到ＣＳＲＳＳ进程的第一个breakin断点会导致被调试系统僵死;-Ｇg表示忽略进程终止时的最后一个断点;-o表示调试被调试进程启动的子进程;-pd表示调试器应该自动与被调试的进程分离;-p用来指定被调试进程的进程ＩＤ。注意WinDbg的帮助文件说ＣＳＲＳＳ的进程ＩＤ总为-1，这对于windows２０００和其后的windows都不再成立。不过因为NTSD提供了一个简洁的方法，只要使用一项就是调试CSRSS。所以在成功建立内核调试后，只要在被调试机上切换到WinDbg目录，然后输入NTSD--.


如果一切顺利，输入NTSD--后，在调试机上应该收到类似如下的信息，笔者使用的环境是两台机器安装的都是windows xp(sp1),WinDbg的版本为6.6.


***wait with pending attach

...

Executable search path is:
ModLoad:4a680000 4a684000 cwindows\system32\csrss.exe
ModLoad:77f500000 77f57000 cwindows\system32\ntdll.dll
ModLoad:75b400000 75b4a0000 cwindows\system32\csrsrv.dll
ModLoad:75b50000 75b5e000 c:\windows\system32\basesrv.dll
ModLoad:75b60000 75ba6000 c:\windows\system32\winsrv.dll
ModLoad:.......c:\windows\system32\user32.dll
ModLoad:.......c:\windows\system32\kernel32.dll
ModLoad:.......c:\windows\system32\gdi32.dll
ModLoad:........c:\windows\system32\advapi32.dll
ModLoad:.........c:\windows\system32\rpcrt4.dll
ModLoad:.........c:\windows\system32\sxs.dll