微軟做這個session隔離的原因我就不追查了，反正讓人有蛋蛋的憂傷。
在vista以前的系統，後臺服務和當前用戶進程都運行在同一個session中(本地系統登錄時的第一個session中)，只有從遠端登錄的時候會建立新的session。
在vista以後的系統，系統啓動後，後臺服務運行在session0中，第一個登錄的用戶運行在session1當中，後續登錄的有session1...sessionn等。session之間當然是有隔離措施的，是什麼樣的機制不去深究；目前需要突破的是，在不同的session程序之間不能按舊的方式進行通信，具體表現在：
1. 不同session之間不能通過窗口互發消息；
2. 一個session中不能直接使用另一個session的顯示資源，比如不能直接在session0中向session1中彈出窗口；
3. 一個session中不能直接使用另一個session的顯示資源，不能讀寫session1中的文件；
4. 不同session之間不能直接共享內核對象的訪問權；
這是實際中會遇到的問題，下面一一解答；
1. 對於session中不能互發消息，這沒什麼好說的，不能就是不能，在vista後在不同session中不要想着發窗口消息通信就對了；
2. 對於簡單的反饋消息窗口可以使用WTSSendMessage函數來向指定的session發送一個消息要求顯示窗口，而session是哪個可以用過WTSGetActiveConsoleSessionId函數來取得當前活動的sessionId；這些函數的用法在這裏可以搜索到http://msdn.microsoft.com/en-us/library/aa383842(v=vs.85).aspx ；對於一些功能比較複雜的窗口，或者說服務需要在session1中重新打開一個程序，則需要獲取session1的sessionId，拿到其訪問令牌，然後使用訪問令牌調用CreateProcessAdUser來在session1創建一個程序。在官網的例子中有這兩個內容，其中創建進程有複製句柄以及創建環境塊的步驟，而我在實踐中沒有加這兩個步驟，調用CreateProcessAdUser時使用空的環境塊，也沒有出什麼問題；目前未確認是否必須創建使用環境塊。
3. 對於在session0中不能讀寫session1用戶的配置文件以及用戶其他資源的情況，需要先用WTSGetActiveConsoleSessionId獲取session1用戶的sessionId，再通過WTSQueryUserToken函數使用sessionId取得這個用戶的token令牌，然後用ImpersonateLoggedOnUser函數使用這個用戶令牌來登錄到這個用戶session，再做一些需要這個用戶session才能做的事情，做完以後把token關閉然後調用RevertToSelf返回原來的session0。這個過程是比較繁雜容易出錯的。
這個內容在官網裏沒有提到，但在實際工作中是用到的，需要熟練掌握。
4. 不同的session中不能共享內核對象，是因爲不同的session中創建命名內核對象時如果名字前不加Global的話，會默認是Local形式創建命名對象，不在session中共享，導致不能被別的session訪問；如果使用了Global標記創建的話，是全局可見的；所以結論就是：如果想跨session使用命名內核對象（通常我們做進程通信都需要使用Event,FileMap這些內核對象），就應該在對象命名前加上Global。
以上內容，第2和第4項可以在微軟官網上找到對應的說明和例子：http://msdn.microsoft.com/zh-cn/library/ee663074.aspx 動手做完實驗，理解能更深刻。
更詳細的說明請參考微軟官方的白皮書：http://msdn.microsoft.com/zh-cn/library/ee663077.aspx
瞭解更多關於Session 0 隔離機制，閱讀Windows Vista 中的驅動和服務的Session 0 隔離機制的影響：http://www.microsoft.com/whdc/system/vista/services.mspx 這個文檔裏面羅列了vista中這些session隔離帶來的影響以及解決方法的理論，但是沒有實踐代碼。
