What is Interactive Services Detection and Why is it Blinking at Me?

UPDATE: If you're a Windows user trying to figure out what's wrong with your PC, please check out my other post:
Troubleshooting Interactive Services Detection.
If you are a developer (or want nerdy details), please read on.

Have seen this button flashing on the taskbar?





When you click on the button, you get this dialog.





If you click “View the message”, your screen blinks and you are taken to a blank desktop with a couple of dialog boxes.

Why is this Happening?

Services and system processes run in session 0. Prior to Vista, the console (first logged on user’s desktop) ran in session 0 as well. Vista introduced
session 0 isolation to protect services from
elevation of privilege exploits from the console desktop. Now, the first user’s desktop runs in session 1.

Interactive Services Detection (the blinking button on the taskbar) is a mitigation for legacy applications that detects if a service is trying to interact with the desktop. This is handled by the Interactive Services Detection (UI0Detect) service.

When you choose “View the message”, you are taken to session 0’s desktop and you can only interact with the dialog or message that services have tried to display on the desktop.

Behavior Depends on Your Bits

The Interactive Services Detection service is set to start “manually”. This means that it won’t start automatically when the system boots.





On a 32-bit version of Windows, the OS will detect desktop interaction and start the UI0Detect service and you will see the flashing taskbar button.

On a 64-bit version of Windows, if the service is a native 64-bit application, the OS will not start the UI0Detect service. Therefore, the service that is trying to interact with the desktop will appear to hang. If you need the mitigation for a 64-bit service,
you will need to be sure the service is running in order to get the mitigation.

Here’s the really weird part… If you have a 32-bit service on a 64-bit Windows, WOW64 will start the UI0Detect service and you will see the mitigation. The reason for this is that the WOW64 environment will behave as close to native 32-bit as possible –
including mitigations. ( Special thanks to
Maarten for his assistance on figuring this out. :-) )

A way to play around with Interactive Services Detection is to use
PsExec tool.

For example, if we try this:

> psexec \\localhost -i 0 calc.exe

This will launch the calculator application in session 0. This is a quick way to simulate a service interacting with the desktop. I find this example interesting. PsExec is a 32 bit application. Therefore, UI0Detect will always get started even though calc.exe
is 64-bit. Here’s a snip from
Process Explorer.





We can see that UI0Detect service is started in session 0 which creates a new process in session 1. The UI0Detect process in session 1 is the Interactive Service Detection dialog. PSEXESVC.exe is the PsExec command service and note that it is a 32-bit app
in session 0. Calc.exe is started in session 0 because we specified session 0 as an argument to PsExec.

Fixing Multiple Issues with One Solution

If a service has this issue, it probably also has an issue with
remote desktop services and/or
fast user switching. Session 0 isolation, remote desktop services and fast user switching all use the same session isolation plumbing. So, if you fix this issue, you are probably fixing several issues you may have not know you had.

The
Services in Windows Vista whitepaper that talks about all the changes to services including Session 0 isolation. Also, check out

this classic post on Session 0 Isolation with developer guidance.