Session in Windows Programming

Session in Windows Programming

Two days ago, I had a problem with the Service Startup Process Under Vista. I had some experience and wrote it down, hoping to help my friends who encountered the same problems as me.

In Windows XP and Vista, the service programs run in session0, While 1st, 2 ,... and n users run in session1, session2 ,... and sessionn. Different sessions have different namespaces, but we do not feel these differences because Windows XP, a mainstream user, supports Fast User Switching.

In XP, the processes started with sevice are similar to those started with the current user in programming. But in Vista, the situation is different. Vista's new security mechanism strengthens the restrictions between different sessions. For example:

1.double-click dbgview( dbgview.exe runs in the current user's session Environment). Then, under session0, you use outputdebugstring to output a string of DEBUG strings. You will find that this message is not found in dbgview.

This problem has plagued me for a long time: I output some debug prompt information at the main () Entry of my process, but it is never seen in dbgview. At first, I thought it was because my service program failed to start the process, but I found that the process exists in the process list. I guess whether the main thread of the process created by my service fails. This is not the problem either. This problem was discovered only after all debug information was written to the file.

 

2. Some mutex volumes, such as mutex usage.

Like the normal detection method, in order to prevent my process B (in session1) from being started multiple times, I used named mutex and then process a (started by my service, so run in session0) to check the mutex and find that it is always unavailable. However, I wrote a small program to detect it (double-click it, so it is also running in session1), but it can always be detected. Later, I carefully read the "Kernel Object Name spaces" Information in msdn to understand:

Some named kernel objects, such as events, semaphores, mutexes, waitable timers, file-mapping objects, and job objects, all exist only in their own namespaces, different sessions are caused by different namespaces. For more information, see the description of the lpname parameter in the createmutex document in msdn.

For more information about the cross-session process in Vista, please refer to this article. It has helped me a lot and thanks to the author.

For convenience, the description of "Kernel Object Name spaces" in msdn is also attached:

Kernel Object Name Spaces
A terminal services server has multiple name spaces for the following named kernel objects: events, semaphores, mutexes, waitable timers, file-mapping objects, and job objects. there is a global name space used primarily by services such as client/server applications. in addition, each client session has a separate name space for these objects. note that this differs from the standard Windows environment in which all processes and services share a single name space for these objects.

The separate client session name spaces enable multiple clients to run the same applications without interfering with each other. for processes started under a Client Session, the system uses the session name space by default. however, these processes can use the global Name Space By prepending the "Global/" prefix to the object name. for example, the following code creates an event object named csapp in the global name space:

Createevent (null, false, false, "Global // csapp ");

Service applications on a terminal services server use the global name space by default. processes started under the server console session (Session zero) also use the global name space by default. the global name space enables processes on multiple client sessions to communicate with a service application or with the console session. for example, a client/server application might use a mutex object for synchronization. the server component running as a service can create the mutex object in the global name space. then the client component running as a process running under a client session can use the "Global/" prefix to open the mutex object.

Another use of the global Name Space is for applications that use named objects to detect that there is already an instance of the application running in the system running SS all sessions. this named object must be created or opened in the global name space instead of the per-session name space. note that the more common case of running the application once per session is supported by default since the named object is created in a per session name space.

Client processes can also use the "local/" prefix to explicitly create an object in their session name space.

The "local", "Global" and "session" prefixes are reserved for system use and shoshould not be used as names for kernel objects. these keywords are case sensitive. on Windows 2000 without terminal services, these keywords are ignored. on earlier versions of the system, the functions for creating or opening these objects fail if you specify a name containing the backslash character (/).

Windows XP: Fast User Switching is implemented using Terminal Services sessions. the first user to log on uses session 0, the next user to log on uses session 1, and so on. kernel Object names must follow the guidelines outlined for terminal services so that applications can support multiple users. for more information, see Fast User Switching.