一直就在纳闷，为什么Windbg不能转储完整的WinSta0窗口站的安全描述符?为什么会少了登录SID和登录帐户的对应ACE?
盆盆很快发现，原来是我自己搞错了。为了方便，我用远程桌面连接到另外一台实验用Windows Vista机器，这时候由于是远程桌面登录的，拿到的是会话2。但是我在Windbg里检查的却是\sessions\1\Windows\WindowStation\WinSta0。
也就是说，盆盆实际上是检查的会话1里的WinSta0窗口站，而不是远程桌面里的WinSta0窗口站(会话2)!!
难怪检查出来的结果，发现WinSta0窗口站里居然没有登录SID和Admin的对应ACE!!
1. 完整的WinSta0安全描述符
为了验证这个结果，盆盆重新做实验，这次直接控制台登录(会话1)，再查看WinSta0的安全描述符，果然发现完整了，有附图为证!
图中棕色加粗的部分，就是登录会话SID和登录帐户Admin所拥有的ACE，这里可以看到登录会话SID拥有所有可能的权限，而Admin则几乎没有任何访问权限。
问题到这里并没有结束。
为什么会出现先前那篇文章里的错误?从中可以猜测到哪些结论?
2. 为什么只允许一个交互用户登录?
这里盆盆大胆假设Windows Vista(XP)为什么只能允许一个交互用户登录到系统(包括远程桌面)。原来是和WinSta0窗口站的权限有关!
当新的用户登录进来后，原来用户会话里的WinSta0的安全权限会发生变化，登录SID和登录帐户的ACE(访问控制项)会被删除。难怪我们看不到先前登录用户的桌面!
可以在远程桌面的环境里打开PRocess Explorer，查看一个在先前用户环境里打开的进程(例如Explorer)，可以发现其句柄列表里没有WinSta0窗口站，如附图所示。
从图中可以看出，当前的用户桌面，会话2里的Explorer进程句柄表里包含WinSta0窗口站，所以可以和用户进行交互;而先前的登录用户，会话1里的Explorer进程句柄表里，没有WinSta0窗口站，所以虽然这些进程还在运行，但是无法和用户进行交互。
为什么先前的用户会话里的进程没有WinSta0的句柄，现在应该很明白了，因为该会话里的WinSta窗口站对象的ACL定义发生了变化，现在不再授予登录会话SID访问。
这一切看来和WinSta0窗口站的安全权限有关。可见，登录会话、窗口站的概念有多重要了。
知道了这个原因，从理论上，我们可以通过修改先前会话里的WinSta0窗口站的安全权限，来突破同一时刻只能允许一个用户交互登录的限制。但是实际上没有那么简单，盆盆能够想到的，微软肯定早就已经想到了。
网上貌似有通过替换一个文件(termsrv.dll)的方法，让Windows Vista支持多个用户交互登录。如果这个方法能够成功，其原理必然还是和WinSta0窗口站的权限有关。
