I have a .NET app I wrote myself that I'm trying to get set up to run as a scheduled task on Windows Server 2008 R2. When I run the app myself from the command line, it works just fine. However, when I set up the task, it completes the task within 1 second of when it starts and says it completed successfully, though of course the app did NOT run. Because of this, I don't get any errors logged either by the scheduler or by the app. If I take out the argument ("auto") then it "runs" the task, but never opens the console to display the menu.

This is what I've tried so far:

  1. Telling the task to run the app directly.
  2. Telling the task to run a batch script that runs the app.
  3. Telling the task to open cmd.exe with /C "applocation\appname auto" as the argument.
  4. Changing ownership of the task to the user account created specifically for running tasks (note that that user account works fine for running other tasks).
  5. Explicitly giving that user account full control over the directories involved.
  6. Changing ownership of the directories involved to the same user.
  7. Changing the security permissions on the app to always Run as Administrator.
  8. Staring at my screen and shaking my head in frustration.

I'm still pretty green with server administration, so it's possible I've overlooked something, but I don't know what that is if I did. I found one question on here that seemed like it was related (GUI doesn't load for a scheduled task) but it's a little different because at least that one actually ran part of the task.


After some more digging, I discovered that the application actually has been running, but due to something I guess I didn't know about the default settings namespace in .NET, the location in the config file where the app stores/reads the web service credentials varies based on whether you're sitting there running the app or the app is being run through TS. Still trying to figure out a way around that...

Regardless, this is where I'm at now: the app spits out SSL/TLS errors whenever the task scheduler attempts to run the app. I have a certificate stored in a subdirectory of the app's home directory (E:\Appname), and as was the case with the credentials, running the app manually causes no problems with the connection. I've ensured that the cert and its folder have the task owner listed with full control.

Am I missing anything else here?

2 Answers 2


If you're trying to debug a failed task that's running in the SYSTEM security context (which is the default for a scheduled task) you should grab a copy of psexec.exe and run psexec -s cmd.exe. This will get you an interactive cmd session as SYSTEM. You can verify this by running whoami from this new command prompt.

Try running your application from here. You'll be able to see any output that it might be writing to the console. Since this is a custom app, I think you'll be hard pressed to find a definitive answer, since we don't know what your code is actually doing. Getting an interactive session as SYSTEM will at least show you if it's a permission problem, or a problem with the settings that you're using in the Task Scheduler.

  • Well, using psexec didn't really show me much of anything. Not sure why. I did find this out after some more digging: the client actually is running, but due to some oddball stuff with C# configuration settings, it was trying to read the web service credentials from someplace different than it does during non-scheduled operation. That's something I'm going to figure out separately.
    – Ant
    Feb 15, 2013 at 19:44
  • What it's doing now, though, is equally confusing. As part of the process of connecting to the web service, the client grabs a certificate located in a subdirectory to start the session. With the credentials fixed, I am now getting SSL errors ("Could not create SSL/TLS channel..."), which, in testing, were always linked to problems locating the certificate. I've ensured that the task user has "Full Control" permissions for the cert and its directory; are there any other permissions I must consider in order for it to find the cert? If you can't think of anything, I'll try posting in Overflow.
    – Ant
    Feb 15, 2013 at 19:50

As it turns out, the problem was that the config file was stored in the AppData\Local directory for the user which was running the app when the config settings were changed (a capability I'd put into the program when running it without the "auto" arg). Since I'd been logging myself on to do the configuration and not the user to which the task was assigned, there was no user.config file for the task user, hence the lack of useable config data. Aligning the task user and the presence of the user.config file fixed it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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