Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I am trying to run an application on a Windows Server 2008 R2 machine from a Windows Server 2003 R2 machine using a batch file with the following line of code in a batch file:

psexec \\nightmachine -u DOMAIN\User -p Password -i "C:\FilePath\Application.exe" argument1 argument2

The application fails to run correctly when started using psexec, but the application will run correctly if I have logged into the nightmachine with the same user and started it from its file path via cmd. I have been able to get hold of the error returned in the application from its log and the exception returned is the following:

System.DllNotFoundException: Unable to load DLL 'rasapi32.dll': A dynamic link library (DLL) initialization routine failed. (Exception from HRESULT: 0x8007045A)

After searching for that error code on the net, there are a lot of posts saying that this is caused by file corruption, but I cant see why that would be the case as the application will run normally when not being run from psexec. (the user is an administrator on both machines)

Can anyone please help me on this? If any more information is needed to help solve this issue then please ask and I will do my best to post it.

share|improve this question
add comment

2 Answers

I assume your UNC in the question has only one slash due is due to needing to type it this way here for formatting "\\\", but if not, fix that. I think the problem is that psexec is looking at your arguments outside of the quotes, and not knowing what to do with them. The easiest way may just be to put that command you can run on the server into a batch file and psexec that batch file, or you can try moving the second quote to after the arguments. Of course you can't have any spaces in the path then.

psexec \\nightmachine -u DOMAIN\User -p Password -i "C:\FilePath\Application.exe" argument1 argument2"
share|improve this answer
Thanks for your reply, but I have tried both solutions that you have suggested, and unfortunately, neither of them have solved the issue. I tried adding the arguments inside the quotes which meant that psexec couldn't find the specified file path (no spaces in the file path) and I have also tried using psexec to run a batch file on the night machine which then runs the application. same problem as before –  Vermin Jun 27 '11 at 14:12
@Vermin If you could put what the real command is, I may be able to help you more. –  KCotreau Jun 27 '11 at 14:15
The application is a purpose build deployment app which does various things (don't know what, i didnt write it, just need to get it to run remotely). the command is: psexec \\nightmachine -u DOMAIN\User -p Password -i "C:\Deployment\DeploymentAspplication\DeploySnapshot.exe" /latest /noninteractive The arguments are there so the app gets the latest files needed and so that it run without user interaction (even though psexex is running with the argument -i, but running without the -i means the app just hangs and does nothing). –  Vermin Jun 27 '11 at 14:25
Ive been able to identifiy the line of code where the exception is thrown out and its just running a function held in another class within the app's project which runs fine when not running with psexec –  Vermin Jun 27 '11 at 14:30
@Vermin I might try copying the app locally and running it with the -c, also is the remote application and all the components in the system path? –  KCotreau Jun 27 '11 at 14:37
add comment
up vote 0 down vote accepted

Issue solved! I found that the application running on the remote pc by psexec was losing its user details when the application was calling processes outside itself which meant any permissions that were required were being lost.

To get around this issue, i ended up setting up a scheduled task on the remote pc where the application lives to run the application using the required user's credentials. The task was set up to run once, but also set up so that it can be triggered manually. This meant that when the application was run by the task, no permissions were lost. I kicked off the task using Psexec:

psexec \\remotemachine schtasks /run /tn "Task name"

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.