關於windows的session機制，我們先來看下官方文檔中的描述：
In Windows® XP, Windows Server® 2003, and earlier versions of Windows, all services run in Session 0 along with applications. This situation poses a security risk. In Windows Vista®, Windows Server 2008, and later versions of Windows, the operating system isolates services in Session 0 and runs applications in other sessions, so services are protected from attacks that originate in application code.
從windows xp以及server 2003開始，在以後的windows版本中，session 0不再是一個用戶session，系統中所有的系統進程和服務都運行在session 0上，同時session 0在系統中是沒有UI的，session 0 不接收任何UI的輸入輸出。相對應登錄用戶啓動的應用都運行在相對應登錄用戶的session ID上，用戶登錄所啓用UI的session ID和啓用應用的session ID是相同的。這樣設計帶來的好處官方文檔中對此的描述是能夠使應用的代碼攻擊不了系統的服務。但在實際應用中，卻對遠程操作系統帶來了一定的麻煩。
由於在實際環境中，遠程控制軟件是以服務的形式安裝在操作系統上的，因此該服務所啓的進程一定是運行在session 0上的。但實際需要部署的應用卻需要接受用戶session所發來的消息隊列。我們看下官方文檔對此的描述：
A service tries to use window message functions such as SendMessage and PostMessage to communicate with an application. This does not work because the application is running in a different session and therefore has a different message queue.The messages
never arrive at their destination. The same is true for applications that try to communicate with services through window messages.
也就是說用戶程序調用SendMessage和服務進程進行通訊時，由於不同的session有不通的消息隊列，因此消息是無法發送到服務進程的。同時，系統也不支持讓用戶在session 0上進行UI的操作。因此，必須把服務應用部署在非session 0上才能保證服務應用正常工作。那就意味着遠程控制軟件必定不能以服務的形式而必須以用戶登錄啓動的形式安裝在系統上。這樣才能保證遠程啓動的應用的進程和用戶發送的消息在同一個session中被消息隊列進行處理。