How to Enable Hibernate in Windows 7 through Power Options? It's a simply way to do.

Click the Start button --> the Control Panel by All Items View --> the Power Options icon --> expand Sleep and Hibernate after in the Power Options window --> Under Hibernate after, set the Setting (Minutes) to how many minutes the computer is inactive for before hibernating --> click OK to apply.

• [ Kill the Process, Use Killbox if your Access Denied ]

[ In Windows Vista Run As Administrator, After Execution System Will Restart ]

• %Documents and Settings\Default User\Local Settings\Temp\uret463.exe
• %Windows\System32\dllcache\cdaudio.sys
• %Documents and Settings\Default User\Local Settings\Temp\lhgjyit0.dll
• %Root of Windows Installed drive\s6.bat
• %Root of Windows Installed drive\autorun.inf
  
  [ No Exact Information about Files, search above related files in Program files Folder ]
  If you have any of these files in running process from task manger, end the process before removal.
  Note: if task manager is disabled, Download the following file, Click to Download - Enable Registry.reg[ Right Click - Save Target As/Linked Content As ]
  Open it with Regedit.exe [%system32\regedit.exe], then it Confirms Add to registry Yes or No, Confirm Yes, then click Ok.
  

Did our VRT wrap-up post wet your appetite for more? Looking to learn about virtualization as a application compatibility tool? No need to worry if you missed the live event as the is now available to stream or download here.

Windows 7 Application Compatibility Part 2: Virtualization

In part two of this Springboard Series Virtual Roundtable on Windows 7 Application Compatibility, you'll hear from Microsoft Technical Fellow Mark Russinovich and a panel of experts on how virtualization tools can help you with application compatibility concerns whether you're migrating from Windows Vista or Windows XP.

 
Here’s your chance to get powerful insight into how presentation virtualization, desktop virtualization and application virtualization can reduce testing times, expedite deployment, and ultimately help you streamline PC management. Also covered are the latest desktop virtualization technologies from Microsoft including Microsoft Application Virtualization (App-V), Microsoft Enterprise Desktop Virtualization (MED-V), and Windows XP Mode for Windows 7.

To see part one of this Virtual Roundtable or to view any of our previous roundtables, click here.

As always, visit the Springboard Series for the latest tools, walkthroughs, FAQs and information for IT pros around Windows 7 and visit our Talking About Windows Event Portal to see all the latest IT pro events worldwide on Windows 7 and Server 2008 R2 in your area. More events are being added every day!

Hi, it’s Mark Relph again from the Windows Ecosystem Team here at Microsoft. Over the summer, our team posted a series of updates on our progress overall and with hardware and software vendors. In advance of the launch of Windows 7, I wanted to provide an update on our progress to ready the ecosystem of hardware and software products that work with Windows. While Windows 7 is designed to be compatible with the most popular hardware and software products you use every day. Compatibility is critical and we’ve continued our focus on making sure our hardware and software partners have all the resources they need to test and build on Windows 7. We have spent a lot of time with these partners in the last few months, including hosting more than 60 application compatibility labs, 6 logo fests, and outreach to partners in more than 93 different countries. In the Windows Ecosystem Readiness Program alone we now have over 50,000 developers from 17,000 companies using our technical resources to ready their products for Windows 7. This is translating into great momentum and real results:

• We have been hard at work partnering with vendors to confirm the compatibility of thousands of products to work with Windows 7. 
• As seen in our Windows 7 Logo Program update, while many products just work, we have thousands of partners meeting a higher quality bar by receiving the Compatible with Windows 7 Logo more than 6,000 hardware and software products. For example, we have more applications with the Windows 7 software logo today than we had at launch for any previous release of Windows.
• On the hardware side, 9 out of 10 beta testers and early adopters of Windows 7 have the drivers available for all hardware devices in and connected to their PCs.
• Here are examples of two partners, Sansa and Roxio who are ready for Windows 7 as part of the Ready.Set.7 program:

 

 

 All of this activity by partners and Microsoft goes to ensuring that customers continue to have a breadth of choice of great products available on Windows 7. To help customers find compatible products, we will unveil a new Windows Compatibility Center Website for the launch of Windows 7. We will have more on this as we get closer to launch, but thousands of products are being populated into the Compatibility Center right now based on confirmed statements of support from partners. If you are a customer, you can be confident that we are working with our partners to ensure you find the compatibility status, downloads, and helpful resources for the products you use every day.

If you are a hardware or software partner, please help Microsoft to tell our customers about your products. If you have not yet submitted your status - now is the time. Ensuring your product status is listed on the Compatibility Center so customers know your Windows 7 readiness status. You can visit the Product submission page to get started. If you are an ISV, there are some additional resources as a part of our Green Light program at www.isvappcompat.com.

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 22^nd, 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 security dialog box. To be more specific, when running on Windows 7, your service may experiences one or more of the following symptoms. The service:

• Is running, but cannot do what it is supposed to do, and just eats CPU cycles and memory
• Is running, but other processes can't communicate with it and it cannot communicate with the user, or other applications / services
• Is trying to communicate with user applications through window messages, but the window messages are not reaching their destination
• Displays a flashing icon on the taskbar indicating the service wants to interact with the desktop

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:

• The service fails to display a UI or it displays a mitigation UI (or annoying flashing dialog box): When a service attempts to show any user interface element (even if it is allowed to interact with the desktop), a mitigation layer prompts the user with the Interactive services dialog detection dialog box, as shown in the next image. The user may opt in to see the service UI on the session 0 secure desktop, but the interruption in workflow makes this a serious application compatibility issue. Furthermore, some users may not react very well to a dialog that blocks your services / application from getting the user input and breaking the flow of the application.

• Objects shared by services and applications become invisible or inaccessible: When an object created by a service is accessed by a standard application (running with standard user privileges), the object cannot be found in the global namespace (that is, it is private to session 0). This means that other applications will not be able to access the so-called “shared object” from the global namespace, and most certainly, not directly from session 0. Additionally, security changes might warrant a situation where even if the object is visible, it is not accessible. This may affect other processes (such as standard user applications) from interacting with your service, again breaking the application flow.

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.

Image source: http://www.microsoft.com/whdc/system/vista/services.mspx

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

1. Launch Process Explorer.
   1. To download or learn more about Process Explorer, see the Process Explorer Web site on Microsoft TechNet.
2. Ensure that Process Explorer displays all processes:
   1. Click File.
   2. Choose Show processes from all users.
3. Locate the first csrss.exe process, which is a service found under the System Idle Process (see next image), and inspect its properties:
   1. Right-click the process.
   2. Select Properties.
   3. Navigate to the Security tab.
   4. Note the session in which the service runs (typically Session 0) and its integrity level.
4. Locate the second csrss.exe process, found under the Wininit.exe (see next image), and inspect its properties as you did in step #3:

The following images show the process properties of both csrss.exe files - one runs under the medium integrity level (in Session 1) and the other runs under the system integrity level (in Session 0) – can you tell which one?:

The left image shows the process properties for the csrss.exe instance that runs at the high system integrity level (session 0), while the image on the right shows the process properties for the csrss.exe instance that runs with medium integrity level (session 1) of the current logged-in user (which is me).

If your service is running under Session 0 and under a high 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

1. Launch Process Explorer.
2. Ensure that Process Explorer displays all processes:
   1. Click File.
   2. Choose Show processes from all users.
3. Locate the suspected service.
4. If the service contains objects that you know are shared with user applications, inspect their handles in the Handles lower pane (press CTRL+H to see it, or access it from the View menu).
   1. Right-click each suspected handle and select Properties.
   2. Switch to the Security tab to see the users and groups that are allowed to access the object referenced by this handle.

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:

• If a service needs to interact with the user by sending a message, use the WTSSendMessage function. It is almost identical in functionality to a MessageBox. This will provide an adequate and simple solution to services that do not require an elaborate UI, and is secure because the displayed message box cannot be used to take control of the underlying service.
• If your service requires a more elaborate UI, use the CreateProcessAsUser function to create a process in the requesting user’s desktop Note that you will still need to communicate between the newly created process and the original services, which is where the next bullet point kicks in.
• If two-way interaction is required, use Windows Communication Foundation (WCF), .NET remoting, named pipes, or any other interprocess communication (IPC) mechanism (excluding window messages) to communicate across sessions. The assumption is that because these technologies (most of them) integrate better security policies than the one used by basic Windows Messaging, they will provide the required elevation (if needed).
• Secure communication and other shared objects (for example, named pipe, file mapping), by using a Discretionary Access Control List (DACL) to tighten the set of users granted access to the mechanism. Use a System Access Control List (SACL) to ensure that medium- or low-integrity processes can access the mechanism even though a system- or high-integrity service created it.
• Ensure that kernel objects meant to be shared across sessions have names prefixed with the Global\ string, indicating that they belong in a session-global namespace.

Additional Resources

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.

• More information: http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
• Download: http://download.sysinternals.com/Files/ProcessExplorer.zip

 

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

Thanks to everyone’s feedback, we’re happy to announce that Windows XP Mode has RTM’d today. We expect to make the final release of Windows XP Mode available via the Microsoft Download Center on October 22nd. OEMs will be able to offer Windows XP Mode on their PCs based on their manufacturing schedules.

For more information on Windows XP Mode, including feature highlights and quotes from some of our partners, I recommend reading this blog post.

Windows XP Mode is designed to provide small business and mid-sized businesses running Windows 7 Professional (or higher) the ability to run Windows XP productivity applications that may not be natively compatible with Windows 7. We expect many Windows XP applications to be compatible Windows 7 however Windows XP Mode is meant to serve as an added safety net so small and mid-sized businesses can migrate and run Windows 7 without any road blocks. Windows 7 Professional is designed to meet the needs of small and mid-sized businesses.