dotnet myservices: I have a service on a server that avails a DLL for client access as a
single-call SAO (using RegisterWellKnownServiceType). The service is
running under LOCAL.SYSTEM. The DLL writes a batch file to the host app
(local) directory and is supposed to then run the batch file. Strange thing
is it creates the batch file with no problem, but access is denied when it
tries to run it. The batch file is good, because if I double-click it from
Explore, it runs. The security properties for the batch file show that
LOCAL.SYSTEM has full rights.

Also, in trying to figure out what's going on, I created a separate batch
file with the same permissions, but that the DLL does not have to write, and
the DLL runs that batch file with no problem. The two batch files have
identical Access Control Entries (ACEs) and are located together. Any idea
why a serviced DLL might have trouble running a batch file that it creates
itself, but have no problem running one it did not create? Thanks.

[quoted text, click to view]

I believe this should work. I would look at basics, something like this...

Are you sure the DLL is closing the BAT file before attempting to
execute it?

When I do BAT files, I generally start "cmd.exe" as the start program
and have him run the BAT file for me.

Is the BAT file NOT created by the DLL invoked in precisely the same way
as the one invoked by the DLL? Are "CurrentDirectory" and SYSOUT and
SYSERR being dealt with in EXACTLY the same way? I would start
questioning the similarity of the two test scenarios to see what is
different. Are the calling EXE and the DLL both .NET ? Managed code is
restrained by security in different ways.

Do you have failure auditing turned on? What does the error event log
show for the object causing the failed reference. That is, are you
absolutely certain it is access to the BAT file itself that is the
problem, or could it be something else to do with the process you are
creating?

When the exception is thrown for something like this, I will report
ex.ToString rather than ex.Message. The routine names provided on the
multi-line stack dump may provide some clues as to what part of the
spawn call is failing.