A few notes about how Windows handles session creation/switch when I was writing an app to track user logon time. Maybe useful for somebody.
Content:
1. Observation
2. How to handle properly
=========================================
= Observations
=========================================
disconnect from a remote session: remotedisconnect
logoff from console: logoff(user), consoledisconnect(user), consoleconnect(system)
(a system logon screen session can be identified by its "logonUI.exe" process, a subsequent logon will take over this session - meaning same session nuber. In this case, it will be only one event: sessionLogon)
lock a session: sessionLock
switch to an existing session: consoledisconnect(1st user) -> consoleconnect(system) -> consoledisconnect(system) -> consoleconnect(2nd user) -> unlock(2nd user)
unlock directly from orignal screen: consoleUnlock
if "switch user" clicked, then unlock: consoledisconnect(user)->consoleconnect(sytem takes over) -> consoledisconnect(disconnect system)-> consoleconnect(original user) -> sessionunlock(original user).
switch then a new logon: lock old user(sessionlock) -> disconnect old user(DisconnectConsole) -> System takes over(ConsoleConnect) -> new user takes over (sessionLogon)
remote disconnect: RemoteDisconnect
remote New connect:
-> remoteConnect(?)
-> sessionLogon
remote REconnect (existing logon sesseion somewhere):
-> remoteconnect(system)
-> if(existing was on console and open)
-> existingSessionDisconnect(user)
-> then system has to spawn a new session to take over (sessionConnect)
-> remoteDisconnect(system)
-> remoteconnect(user)
=========================================
= How to handle properly
=========================================
There are many session switch that are very confusing at the first sight. For example, for a simple user switch, their may be up to 5 session switch events. The key thing to remember is whethre user has an existing session already.
- once a user obtained session #, he/she keeps that same session # unles she/he logs off. None other session switch events will change this owning relationship;
- Logically, user gets a new session # only when she/he logon
- If a user connects back on a same session or unlock a same session that he obtained prior, then only one switch envent, sessionUnlock or session logon will be fired;
- if a user takes a brand new session, or take session from others, then ConsoleDisconnect/connect will happen multiple times. Basically, TS has to break existing session from another user, connect under System, disconnect System session, then finally users takes the session