Psexec vs MFC application

[Ozo]

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.

 

[Herb Martin]

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.

 

[Drew Cooper [MSFT]]

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?