It has been a while since the last blog posting, Windows 7 RTM – Go Get It, and we have a lot of catching up to do.
The Windows 7 GA data is still October 22nd, less than a month away, which means your application should be almost ready for Windows 7. As you prepare your applications for Window 7, be sure to verify that you don’t have any issues with version checking and UAC Data Redirection. This post topic, Session 0 Isolation, is another application compatibility topic that requires our special attention, especially if your applications include services. If your services are working on Windows Vista, most likely they will continue to work on Windows 7 (still you need to test your application fully on Windows 7). However, if you didn’t run the proper compatibility testing on Windows Vista, you might want to take few moments to read this post.
Let’s start with a better understanding of what services are.
What are services?
A service is an integral mechanism built into Microsoft Windows operating systems. You can think of services as “special applications” that run with no regard to the current user context. Services are different from “regular” user applications because you can configure a service to run from the time a system starts up (boots) until it shuts down, without requiring an active user to be present – that is, services can run without having any users logged on.
We like to think about services as running “tasks” for us in the background without interfering with user operations. Services on Windows are responsible for all kinds of background activity that do not involve the user, ranging from the Remote Procedure Call (RPC) service, through Printer Spoolers, to the Network Location Awareness service.
What’s the problem?
Some services may attempt to display user interface dialogs or communicate with user applications. Such functionality is “typical” of Windows XP services, mainly because it is easy to do so. If you happen to own a service that attempts to display some user interface objects, like a dialog box, or tries to communicate with applications you might run into trouble running on Windows 7.
When running a service that is trying to display a dialog box on Windows 7, instead of the desired dialog box, you will see an annoying flashing icon on the taskbar. And, if you press on that flashing icon, you will see a dialog box. To be more specific, when running on Windows 7, your service may experiences one or more of the following symptoms. The service:
All the above symptoms point to the conclusion that your service is experiencing Session 0 Isolation of Windows 7 Services, that is, the “physical” separation between services and user applications, but more about that in just a bit. First, let’s define the two “buckets of issues” your services may experience when running on Windows 7:
Clearly, Session 0 Isolation has the potential of being a serious compatibility pain. Well, this post should provide you with enough information to identify if your service is at “risk” -- and how to solve the problem. However, I have to remind you that the main reason for isolating services from user application is making it harder for malicious software to run with elevated privileges, which enables them to do far more harm than running as standard user as explained in the following section, thus making Windows much more secure operating system.
The Reason: Session 0 Isolation of Windows 7 Services
In Windows XP, Windows Server 2003, and earlier versions of the Windows operating system, services and applications run in the same session as the one started by the first user who logs onto the console. This session is called Session 0, and as shown in the following image, prior to Windows Vista, Session 0 included both services and standard user applications.
Image source: http://www.microsoft.com/whdc/system/vista/services.mspx
Running services and user applications together in Session 0 poses a security risk because services run with elevated privileges, while user applications run with user privileges (most of which are not admin).This makes the services targets for malicious agents that are looking for mechanisms to elevate their own privilege levels by “hijacking” the services.
Starting with Windows Vista, only services are hosted in Session 0. User applications are isolated from services, and run in subsequent sessions created when users log onto the system: Session 1 for the first logged on user, Session 2 for the second, and so on, as shown in the following image.
Entities (applications or services) running in different sessions cannot send each other messages, share UI elements, or share kernel objects without explicitly qualifying them to the global namespace and providing the appropriate access control settings. The following image illustrates this:
You can find additional valuable information about this in Impact of Session 0 Isolation on Services and Drivers in Windows Vista (http://www.microsoft.com/whdc/system/vista/services.mspx), an article that is equally applicable to Windows 7.
How can you detect whether your service might experience some of the above-mentioned problems?
So far, we have presented the symptoms associated with Session 0 isolation of Windows services, explained what service isolation is, and how it may affect your services and applications. Below are tests and other actions you can take in order to pinpoint your real problem and start resolving it.
Test #1 – Verifying service (or any other process) session assignment
The left image shows the process properties for the csrss.exe instance that runs at the system integrity level - session 0, while the image on the right shows the process properties for the csrss.exe instance that runs also with System integrity level but in a different session - session 1:
If your service is running under Session 0 and under a System integrity level, it will be unable to display UI directly. It is also likely that you will experience problems when sharing kernel objects or files with the service.
Test #2 – Ensuring object accessibility
The following image shows an example of a shared object that everyone can access (for the “Synchronize” right) even though it is opened in a system service that runs in session 0
The following image displays an example of a shared object that only administrators and the SYSTEM group can access:
Now that you know what the problems could be, what about fixing them?
You've already done the hard part, knowing and understanding that you have a session 0 issue; solving these problems is easy.
Here are some ideas on how to solve the above mentioned problems:
You can find more-detailed information about this topic in the Windows 7 Training Kit for Developers, including a detailed whitepaper and hands-on-lab. If you want, you can download just the Session 0 Isolation hands-on-lab directly.
Here is some basic information about the tools used in this post:
Process Explorer – a monitoring tool for Windows processes that is able to display process integrity levels and object security information.
You can get much more information about this topic and others in Windows 7 topic page on channel 9.
For more Windows 7 Technical content and hands-on experience download the - Windows 7 Training Kit for Developers is also a great place to learn more about this topic
I have a problem with a program (writen with VB6) that in hebrew part of the printing (as document printing) is on the opposite direction.
How can I solve this problem.
Partner Software Dev