首先了解一下程序要具备怎样的条件才能与界面交互。Windows提供了三类对象：用户界面对象（User Interface）、GDI对象和内核对象。内核对象有安全性，而前两者没有。为了对前两者提供安全性，通过工作站对象（Window station）和桌面对象（Desktop）来管理用户界面对象，因为工作站对象和桌面对象有安全特性。简单说来，，工作站是一个带有安全特性的对象，它与进程相关联，包含了一个或多个桌面对象。当工作站对象被创建时，它被关联到调用进程上，并且被赋给当前Session。交互式工作站WinSta0，是唯一一个可以显示用户界面，接受用户输入的工作站。它被赋给交互式用户的登录Session，包含了键盘、鼠标和显示设备。所有其他工作站都是非交互式的，这就意味着它们不能显示用户界面，不能接受用户的输入。当用户登录到一台启用了终端服务的计算机上时，每个用户都会启动一个Session。每个Session都会与自己的交互式工作站相联系。桌面是一个带有安全特性的对象，被包含在一个窗口工作站对象中。一个桌面对象有一个逻辑的显示区域，包含了诸如窗口、菜单、钩子等等这样的用户界面对象。
在Vista之前，之所以可以通过打开Winsta0和缺省桌面显示对话框，是因为不管是服务还是第一个登录的交互式用户，都是登录到Session 0中。因此，服务程序可以通过强制打开WinSta0和桌面来获得交互能力。
然而，在Vista和Windows2008中，Session 0专用于服务和其他不与用户交互的应用程序。第一个登录进来，可以进行交互式操作的用户被连到Session 1上。第二个登录进行的用户被分配给Session 2，以此类推。Session 0完全不支持要与用户交互的进程。如果采取在服务进程中启动子进程来显示对话框，子对话框将无法显示；如果采取用OpenWindowStation系统API打开WinSta0的方法，函数调用会失败。总之，Vista和Windows2008已经堵上了在Session 0中产生界面交互的路。这就是原因所在。
那么，是否真的没法在服务中弹出对话框了呢？对于服务进程自身来说，确实如此，操作系统已经把这条路堵上了。但是，我们想要的并不是“在服务进程中弹出对话框”，我们想要的不过是“当服务出现某些状况的时候，在桌面上弹出对话框”。既然在Session 0中无法弹出对话框，而我们看到的桌面是Session X，并非Session 0，很自然的一个想法是：能不能让Session 0通知其他的Session，让当前桌面正显示着的Session弹一个对话框呢？
幸运的是，还真可以这样做。