[...]

No offense but this is a terribly bad idea. For 3 reasons:

1) nothing garantees that there will be an interactive user logged in when
the windows service will launch the display application. If nobody is
logged in, the application will be stuck in some invisible desktop with no
way for anybody to either see it or close it.

2) Launching an application from a Windows Service means that the
application will run under the user account of the Windows service (and not
under the user account of the user that might be logged in at the time).
This user acount is often Local System which is, in some ways, as powerfull
and even more powerfull than the Administrator account. Using your
application and some well known exploits, it's gonna be child play for
hackers to gain administrator priviledges on the machines. BANG, you're
dead.

3) AFAIK, interactive windows services won't be allowed anymore under
Windows Vista so this method won't work at all under Vista

The only way for a service to interact with an interactive user is to
develop a normal windows application for this purpose, set it to start
automatically when a user logs in and communicate with this application
from your windows service using some kind of IPC. This could be sockets,
shared memory, .NET remoting or any other way you see fit.

Note that if all you want is to display a message box, you could do that
using the MessageBox.Show method directly from your service using the
MessageBoxOptions.ServiceNotification parameter. You should be well aware
of what this method implies before using it though (in particular this will
block the caller until the user, which might not be there, dismisses it).
See the last part of this article for more details:
http://pluralsight.com/wiki/default.aspx/Keith.GuideBook/HowToDisplayAUserInterf
aceFromADaemon.html