Re: Psexec vs MFC application

From: Drew Cooper [MSFT] (dcoop_at_online.microsoft.com)
Date: 03/04/04 

Date: Thu, 4 Mar 2004 13:19:05 -0800

Knowing what the exception was and what threw it would be useful. I'm not
sure why MFC is the immediate suspect without knowing more about the app and
why it's failing. I suspect that Herb is right about this one, though.

Psexec has a switch to run the app interactively with the desktop. I don't
know how Mark (Russinovich, the psexec author) decides which desktop that is
or what he does when there's nobody logged on interactively - his
documentation is kinda skimpy.

A couple of security concerns with the psexec-like approach:
1. Services that interact with user desktops can be dangerous - google for
"shatter attack" if you're interested.
2. Psexec sends passwords over the wire in plaintext. I don't know if your
in-house app does that or not.

If this app needs to be run on an interactively-logged on user's desktop,
have you considered terminal services? 

-- 
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.
"Herb Martin" <news@LearnQuick.com> wrote in message
news:%23z6HgibAEHA.132@TK2MSFTNGP10.phx.gbl...
> You might try on of the programming groups as more hard
> core programmers will likely view -- and answer -- your
> post.
>
> My guesses:  psexec is going to run under the system account
> and perhaps under a service that has no access to the desktop.
> Most MFC apps will default to using the GUI, so that will cause
> an error.
>
> That notepad works, argues against my idea though.
>
> Another possibility:  Just the act of loading it different is
> accidently cause it to reference memory or make a call
> incorrectly that just doesn't get exposed otherwise.
>
> -- 
> Herb Martin
> "Ozo" <Ozo@whoever.com> wrote in message
> news:841e93f3.0403031603.145bb615@posting.google.com...
> > I am having problems starting an MFC application in remote using
> > psexec (from http://www.sysinternals.com/).  It works well with most
> > applications (ex: notepad.exe), but it creates problems with MFC
> > applications.  The application starts, but it aborts with an
> > "Application Error" saying "Windows cannot continue from this
> > exception".
> >
> > We then wrote our own psexec-like tool to spawn remote applications,
> > but we have the same problem.  The way psexec (and our tool) works, is
> > by starting a service on the remote computer, which then waits for a
> > request to start a process locally.  When the psexec service is
> > started (like ours), it runs as a child process of the services.exe
> > Windows process.
> >
> > We found this suspicious and so we modified our own tool; Instead of
> > starting a service on the remote machine that waits for remote-spawn
> > requests, we changed it to simply start a regular user-mode process
> > that does the same thing (i.e. wait for requests to spawn a process).
> > Now, because it is a regular user-mode process, and because we start
> > it locally on the computer, it is no more a child of the services.exe
> > process.  With this new scheme, all our MFC application can be
> > remotely spawn without any problem.  So a quick conclusion seems to be
> > that a process that is a child of services.exe can not spawn an MFC
> > process.
> >
> > Now, the question is why?  What is going on with MFC that stops psexec
> > from spawning it?  Is there something special I should know about
> > security attributes and all that stuff?
> >
> > Thanks,
> >
> > Ozo.
>
>
Quantcast