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

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Rob R. Ainscough - 07 Jul 2006 05:50 GMT

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

Reply to this Message

Brendan Green - 07 Jul 2006 06:36 GMT

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).

> Situation:
> .NET 2.0 based Windows Service
[quoted text clipped - 25 lines]
>
> Rob

Reply to this Message

Rob R. Ainscough - 07 Jul 2006 08:29 GMT

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.

> It's not a flaw, and it has nothing to do with .NET.
>
[quoted text clipped - 31 lines]
>>
>> Rob

Reply to this Message

Greg Young - 07 Jul 2006 10:57 GMT

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

> Brendan,
>
[quoted text clipped - 59 lines]
>>>
>>> Rob

Reply to this Message

Rob R. Ainscough - 07 Jul 2006 19:17 GMT

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.

> And you may open a security hole
> ...http://www.microsoft.com/technet/archive/security/news/htshat.mspx?mfr=true
[quoted text clipped - 78 lines]
>>>>
>>>> Rob

Reply to this Message

William Sullivan - 07 Jul 2006 20:44 GMT

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

> 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
[quoted text clipped - 103 lines]
> >>>>
> >>>> Rob

Reply to this Message

Greg Young - 07 Jul 2006 22:20 GMT

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
[quoted text clipped - 4 lines]
> 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
[quoted text clipped - 7 lines]
> 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

> 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
[quoted text clipped - 104 lines]
>>>>>
>>>>> Rob

Reply to this Message

Rate this thread:

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

Free Magazines