Microsoft has finally done it. Session 0 is officially off limits.
The Interactive Services Detection Service — necessary to switch to Session 0 — has been removed in Windows 10 Version 1803 (released in April 2018). While applications running in Session 0 will happily create windows and prompts, no one will be able to see them.
But this is no big surprise. The geeks in Redmond have been marching in this direction for many years.
A brief history of Session 0 and Interactive Windows Services
Windows NT (1993)
The concept of multiple login sessions in solidified in this foundational release of Windows. Session 0 is created at boot, interactive Windows Services are supported and the first user to log in is placed in Session 0.
Windows Vista (2007)
To avoid shatter attacks, Vista prohibits users from logging in to Session 0. That new world order is dubbed “Session 0 Isolation”. The Interactive Services Detection service is introduced to allow users to temporarily access Session 0 — a band-aid for interactive Windows Services that show windows and prompts.
Windows 8 & Windows Server 2012
Microsoft continues to discourage interactive services. The NoInteractiveServices registry value, which enables the Interactive Detection Service and switching to Session 0, is set to 1 by default. This prevents anyone from switching to Session 0 (unless the registry is updated).
Windows 10 & Windows Server 2016
The keyboard and mouse no longer function in Session 0. This unwelcome behavior was widely thought to be a bug that Microsoft would eventually resolve, but it now looks like a deliberate action intended to cripple interaction with Session 0.
Windows 10, version 1703 (2017)
Microsoft promises to remove the Interactive Services Detection service in this Spring Creators Update but for some reason the service remains.
Windows 10, version 1803 (2018)
The Interactive Services Detection service is officially removed. Switching to Session 0 is forbidden.
So what exactly are the ramifications of losing the Interactive Services Detection service?
Consequence #1: You won’t be able to switch to Session 0 from AlwaysUp on Windows 10
While your application will continue to run as normal in Session 0, attempting to switch to Session 0 will result in an error (reported on the Status Bar):
Consequence #2: Our Switch to Session 0 utility won’t work on Windows 10
Switch to Session 0 will run happily in your taskbar but you will encounter an error when you try to switch. Not surprisingly, the message says that the Interactive Services Detection service “does not exist as an installed service”:
Sayonara Session 0!
SO if this service is banned in Windows 10, version 1803 (2018), Is there any other way I can start this service. I will need this to run my UI test cases as UI test cases require interaction with Application so those failed if this service is not enabled.
Unfortunately there is no way to start the service in recent versions of Windows.
However Windows applications can still have UI interaction in Session 0 — they just can’t interact with you, the operator.
What application are you running in Session 0?
Would it be technically possible to bring the files that run the service to a newer version of Windows or has it been completely ripped out at the kernel side?
Yes, it is technically possible to restore the UI0Detect service in Windows 10 and Server 2019 by installing the components collected from another computer. However:
This information isn”t correct. Just use FireDaemon Zero and ZeroInput in conjunction with AlwaysUp … then everything works as normal and you can switch desktop to Session 0. You can’t just reinstall the UI0Detect service and Interactive Services Detection Service. There are also plenty of RDP limitations though so you will need to use alternate remote control products such as TSPlus or TeamViewer.
Unfortunately using the tools you mention involve tampering with the low-level Windows system kernel driver. Such consequential changes may be suitable for home usage, but our customers have let us know that replacing key OS components is frowned upon in managed corporate environments that expect technical support (and monthly security patching) from Microsoft.
So while it is technically possible to restore some access to Session 0, all the solutions we are aware of come with significant risk — and can be easily thwarted by Microsoft in their next OS update. Best not to rely on them.
Hi Core Technologies Consulting,
I am using TestComplete and the tests starting to fail when I disconnect from the RDP. I am using Windows 10 in Azure. What is the workaround you suggest for this?
Are you running TestComplete with AlwaysUp?
If not, are you running TestComplete as a Windows Service with another tool?