Shell, executes but no GUI is displayed .NET 2.0?

[Rob R. Ainscough]

Situation:
..NET 2.0 based Windows Service

Have a timer event in the service

Private WithEvents ServiceTimer As New System.Timers.Timer(30000)

Private Sub Check_Updates(ByVal sender As Object, _
ByVal e As System.Timers.ElapsedEventArgs)
Handles ServiceTimer.Elapsed

Shell("C:\WINDOWS\SYSTEM32\NOTEPAD.EXE", AppWinStyle.MaximizedFocus,
True, -1)

End Sub

Start the service, no errors are triggered and in 30 seconds NOTEPAD.EXE
appears in Task Manager Processes tab but not in Applications tab and there
is NOTHING displayed on my screen anywhere.

I've tried using Diagnostic.Process approach also, same results. Also tried
waitonexit, timeout values, and nothing will permit my shelled process
(NOTEPAD) to show it's interface yet it appears as a running process in Task
Manager?

Any suggestion as to this pretty serious flaw in .NET 2.0? Someone care to
duplicate this and confirm my results?

Rob

 

[Brendan Green]

It's not a flaw, and it has nothing to do with .NET.

Why are you trying to run a GUI application from a service? You can
probably get this to work by allowing the service to "interact with the
desktop" (check the properties of the service).

 

[Rob R. Ainscough]

Brendan,

It is an Automatic Update Service that I've created to update several of my
applications of client PCs. The service does some checking, downloads
updates, and if the user has enabled the interface it will shell the
application (GUI) that will interface with the user. To be clear, this is a
shelled process that shouldn't care what the source of the shell was, but
apparently a Windows Service seems to prevent any shell process from have
any interface/window.

This needs to be a service because making the app part of the Startup is too
easy for my clients/users to remove it. "What this, I don't know, lets
delete it" is all too common with my user base, services are a tad more
hidden and most of my users don't even know what they are nor how to even
identify them.

I believe Microsoft use the same approach? If not, I'd certainly appreciate
some insight on what the best approach is for this situation?

Regardless, thank you!! Your solution resolved it! I've spent all day
working on this and it didn't occur to me that a shelled process would be
restricted by the same rules that govern a service (IMHO they process should
be separate entity unto itself) -- I have coded services before and know how
to set the interact with desktop via the ServiceController in the project
installer -- I will do that

Thanks, Rob.

 

[Greg Young]

And you may open a security hole
....http://www.microsoft.com/technet/archive/security/news/htshat.mspx?mfr=true
I believe this functionality has also been removed in vista so your service
would not work there.Your service will only be able to interact with a
different desktop (not the one the user is on). MS has said for a long time
that this was a bad way of doing things.

The general way of doing this is to have a back end service and a front end
client app that talks to the back end service through a mechanism such as
remoting. The service then tells the client app to show something to the
user this way the client app runs in the same security context as the user
(as opposed to a service running under a higher priv level).

Cheers,

Greg Young
MVP - C#
http://codebetter.com/blogs/gregyoung

 

[Rob R. Ainscough]

So your suggesting I read up and learn remoting for the next several days
for what amounts to be a very basic GUI that basically permits the user to
Enable/Disable and Turn notifications on/off and view the progress of the
downloads/installs? I would find it unlikely that Vista will not permit
existing services that interact with the desktop to not work come the final
build -- a quick check for Services that interact with my desktop comes up
with a count of 12 (Symatec, hardware support services, and a few others) --
so M$ will have to come up with some solution.

I would disagree that "I'm opening a security hole" -- the hole exists due
to the poor implementation of the OS -- security isn't something that should
get in the way of a valid process installed by a user. MS can try to pass
the buck, but it ultimately stops on their door step in terms of public
perception -- when you hear about the next virus on the news, you don't hear
about the developer or IT person that "opened hole", no, you hear
"Microsoft". So Microsoft can continue to blindly point fingers, but it
doesn't change the public perception and fear of M$ operating systems and
viruses. The folks at Redmond either need to come up with a better plan or
seal their static fate with flat revenue and declining stock value.

Remoting -- yet another "new and improved approach to be obsolete within the
next 6 months as it's deemed unsecure, slow, buggy, etc. etc."

Rob.

 

[Guest]

Maybe you should port your program to Linux? Good luck rtfm'ing.

 

[Greg Young]

I won't harp on the interactive service I think you have been told "don't do
that" enough in the various posts you put up. I will leave you with one more
link though .. note the "it doesn't actually work" paragraph
http://blogs.msdn.com/larryosterman/archive/2005/09/14/466175.aspx

So your suggesting I read up and learn remoting for the next several days
for what amounts to be a very basic GUI that basically permits the user to
Enable/Disable and Turn notifications on/off and view the progress of the
downloads/installs? I would find it unlikely that Vista will not permit
existing services that interact with the desktop to not work come the
final build -- a quick check for Services that interact with my desktop
comes up with a count of 12 (Symatec, hardware support services, and a few
others) -- so M$ will have to come up with some solution.

I would disagree that "I'm opening a security hole" -- the hole exists due
to the poor implementation of the OS -- security isn't something that
should get in the way of a valid process installed by a user. MS can try
to pass the buck, but it ultimately stops on their door step in terms of
public perception -- when you hear about the next virus on the news, you
don't hear about the developer or IT person that "opened hole", no, you
hear "Microsoft". So Microsoft can continue to blindly point fingers, but
it doesn't change the public perception and fear of M$ operating systems
and viruses. The folks at Redmond either need to come up with a better
plan or seal their static fate with flat revenue and declining stock
value.

There is a really easy way to figure out if it is bad code/configuration or
an OS problem. If the system is secure, then you install your software and
it has a gaping hole it is not the OS that caused the problem.



Let's take these two quotestogether .. you rail on MS for having the problem
right after you rail them for trying to change it breaking backwards
compatibility (is there anything they can do right?) There is currently a
very strong security movement (see SDL).

As for it being an OS problem .. it is a configuration problem .. someone
who doesn't know what they are doing can make even the most secure OS
insecure if they have admin privileges. If default services came with
windows that ran in this method (and not as a reduced privilege user) I
could buy this argument but with MS having made this common knowledge years
ago I have a hard time blaming them for it. The moment MS says "this
configuration has problems" the problem falls to the feet of
developers/admins.

I hate to be the one to break it to you but if you write bad code on an os
you would consider to be secure like openbsd and you take that bad code and
give it escalated privs you have a vulnerability and it is not the fault of
the OS. It is the fault of the developer who didn't bother to care. Not
surprisingly an admin/developer with super user privs can easily make an
openbsd box not secure.

security isn't something that should get in the way of a valid process
installed by a user.

I guess that installing a ftp server with a buffer overflow attack is
something a user might want to install as well.

It is a constant trade off.between ease functionality and security .. look
at the people disabling security in vista because they are used to running
as admin on their machine. The fact of the matter is that not all machines
need to be secure, but the software should atleast support running in a
secure fashion.

Cheers,

Greg