Scheduled Tasks and .NET console apps

[Tatter]

I have a simple .NET 1.1 console application, written with Visual Studio .NET 2003, that needs to be run on a Windows XP system as a scheduled task. When run on its own, the program executes with no errors. When run as a scheduled task on a computer with debugging tools installed, it runs with no errors.

When run as a scheduled task on a computer with no debugging tools installed, namely the Windows XP system it is supposed to be run on, it crashes with a .NET framework error. Since there are no debugging tools installed on that machine, the only thing I can get out of the error are the process and thread IDs, which of course are pretty much useless for a non-threaded console application.

The crash occurs regardless of whether the scheduled task is run as the current user, run as a user with admin privileges, or even run manually in the scheduled tasks window by right-clicking on the task and selecting "Run," while logged in as a system administrator. It also runs without error on the development system (also using Windows XP), under all those same circumstances.

All I can think of is that there is some kind of misconfiguration in the .NET installation on the target system, but I have no idea how to go about preventing it when re-installing Windows XP and .NET from scratch, which we've done several times already, let alone fixing it. Installing Visual Studio .NET 2003 on the target machine is not an option.

Has anyone else had this problem? If so, is there a way to fix it, and if so, how?

[Motoma]

I am sorry if you stated this, but does it run correctly on the target machine, if you are running it without the scheduler?

Does the Event Viewer give you any information regarding the crash?

Have you tried configuring the Security Policy in the .NET configuration (Control Panel > Administrative Tools >> .NET Configuration 1.1)?

I have a simple .NET 1.1 console application, written with Visual Studio .NET 2003, that needs to be run on a Windows XP system as a scheduled task. When run on its own, the program executes with no errors. When run as a scheduled task on a computer with debugging tools installed, it runs with no errors.

When run as a scheduled task on a computer with no debugging tools installed, namely the Windows XP system it is supposed to be run on, it crashes with a .NET framework error. Since there are no debugging tools installed on that machine, the only thing I can get out of the error are the process and thread IDs, which of course are pretty much useless for a non-threaded console application.

The crash occurs regardless of whether the scheduled task is run as the current user, run as a user with admin privileges, or even run manually in the scheduled tasks window by right-clicking on the task and selecting "Run," while logged in as a system administrator. It also runs without error on the development system (also using Windows XP), under all those same circumstances.

All I can think of is that there is some kind of misconfiguration in the .NET installation on the target system, but I have no idea how to go about preventing it when re-installing Windows XP and .NET from scratch, which we've done several times already, let alone fixing it. Installing Visual Studio .NET 2003 on the target machine is not an option.

Has anyone else had this problem? If so, is there a way to fix it, and if so, how?

[Tatter]

I am sorry if you stated this, but does it run correctly on the target machine, if you are running it without the scheduler?

Does the Event Viewer give you any information regarding the crash?

Have you tried configuring the Security Policy in the .NET configuration (Control Panel > Administrative Tools >> .NET Configuration 1.1)?

Sorry, yes, it runs fine on the target machine when running it without the scheduler.

No, the Event Viewer does not even record when the program is started by the task scheduler, let alone when it crashes.

I haven't tried checking the Security Policy for .NET yet. I'll have to check with our configuration management department before making any changes, but that may well be the problem. All we've tested so far are the directory permissions.