locked
Does Shell command work with a VB Windows Service?

    Question

  • Hello All,

     

    Dim ProcID As Integer
    ProcID = Shell("C:\Windows\system32\calc.exe", AppWinStyle.MaximizedFocus)

     

       The simple code above executes normally as part of a VS 2005 VB Windows Application.  It launches the calculator program.  If I take the same code and place it in a VS 2005 VB Windows Service it does not launch the calculator.  It builds fine and my service program is otherwise running normally with no errors.  It just doesn't seem to be executing the "Shell" command. ProcID returns an ID number, but I can never find a corresponding entry in taskmanager.

     

    Any ideas?  Is the "Shell" command allowed when running a Windows Service?  I am trying to figure out a way to have a Windows Service launch another program when certain conditions are met.

     

    Thanks for any and all help!

     

    Friday, November 30, 2007 11:18 PM

Answers

  •  

    Have you checked processes to see if it's running?  It could be that it's launching fine.  The service will have to be flagged to allow interaction with the desktop (and running a a local system account) to get an application that you can see.  Normally a service will have a "virtual" desktop that's invisible to any users.  So GUI applications usually just sort of "sit there" unless you have it flagged to interact with the desktop.
    Tuesday, December 4, 2007 7:54 PM
  • Under Windows Vista, a service cannot interact with the desktop, therefore anything that throws up a visible UI will not work.

     

    Under XP this is also the default behavior, but you can set your service to allow it to interact with the desktop.  This is not recommended, however.

     

    A Windows service should not show a UI.  If you need a UI to configure the service or otherwise interact with it, then you should create a separate Windows forms application that can communicate with the service process.  That app would be launched by a user who is logged onto the system.

     

    The reason a service should not show a UI is that the service will start before anyone has logged onto the machine.  There will be no desktop available upon which to display the service.

     

    Chris.

     

    Tuesday, December 4, 2007 10:13 PM

All replies

  •  

    A couple of things

     

    What OS are you using  ?

     

    Why are you using the Shell command instead of the System.Diagnostics.Process class which is much more flexible.

     

    If its Vista, then your problem is to do with a security feature which prevents you interacting with the UI via a windows service.   Its a real pain and somethings which used to work in older OS just dont work but it doesnt actually produce an error.    

     

    Have you tried remote debugging the windows service to actually see this line is executing.

    Saturday, December 1, 2007 4:15 AM
  • This thread seems to pertain to a problem I'm having with Vista.

     

    I have a legacy application, FormFlow 2.22, that uses its Shell command to unzip some files and put them in a certain directory.  It works fine in XP, but fails in Vista.

     

    It seems to fail because parameters are being passed to the called program.  If the called program contains all the needed parameters, then FormFlow's Shell works fine in Vista.  Even if I create a Console App in VB and call that with FormFlow's Shell command, it works fine if no parameters are passed and fails if parameters are passed.

     

    Yet, if I open a command window in Vista and enter the program and parameters at the prompt, it does work!

     

    What is there in Vista that is preventing this from working as it did in XP?

     

     

    Monday, December 3, 2007 2:18 AM
  • I am using Windows XP Pro SP2.  Sorry for not including that in my original question. 

     

    I have tried using System.Diagnostics.Process class as well, with the same results. I listed this question with "Shell" because the example code was only two lines. If I can get it to work with Shell, I figure it will work with System.Diagnostics.Process as well.

     

    I ran the remote debugger on the windows service and it is processing the line, it assigns and returns a PID for the program that is executing.  It is almost like it runs the program for a split second but then kills it.  I do not see anything on the display or in taskmanager, but the disk access and slight pause in the code, suggests that it is doing something when it encounters the instruction to launch an external program.

     

    Both methods work perfectly for me when I use them in a Windows Application.  Honestly, I was expecting to be told that these commands don't work with a Windows Service.

     

    Thanks for the help!

     

    -Dave 

    Tuesday, December 4, 2007 5:51 PM
  •  

    Have you checked processes to see if it's running?  It could be that it's launching fine.  The service will have to be flagged to allow interaction with the desktop (and running a a local system account) to get an application that you can see.  Normally a service will have a "virtual" desktop that's invisible to any users.  So GUI applications usually just sort of "sit there" unless you have it flagged to interact with the desktop.
    Tuesday, December 4, 2007 7:54 PM
  • Under Windows Vista, a service cannot interact with the desktop, therefore anything that throws up a visible UI will not work.

     

    Under XP this is also the default behavior, but you can set your service to allow it to interact with the desktop.  This is not recommended, however.

     

    A Windows service should not show a UI.  If you need a UI to configure the service or otherwise interact with it, then you should create a separate Windows forms application that can communicate with the service process.  That app would be launched by a user who is logged onto the system.

     

    The reason a service should not show a UI is that the service will start before anyone has logged onto the machine.  There will be no desktop available upon which to display the service.

     

    Chris.

     

    Tuesday, December 4, 2007 10:13 PM