VB.NET crashes when run from Windows scheduled tasks if user logged off

[whutto]

I have a VB.NET app that crashes when run from the Windows scheduled tasks, but runs fine when the run-as user is logged on. The app also runs fine from the scheduled jobs if the run as user is disconnected. The O/S is Windows Server 2003, the app is created with VB.NET 2003. The .NET framework is up todate with Windows releases. The APP opens connections to an SQL Server 2003 database and an ODBC sql connection to an iSeries database.

Unfortunatley the event viewer application message message is not very specific, please see below.

The scheduled task ending status is 0xc000013a, which implies "access denied". Apparently, the problem is due to not having permissions to access a needed object without the user being logged on.

But when I log on to attempt a debug, the app runs fine.

Is there a way to get a more specific message logged in the event view so that I have a clue as what the problem is?

We have tried running the task as an admin user, with the same results.
We added the specific user to Command.exe, still failed.
We added BATCH to the Command.exe object, still failed.

Thanks for your help
Weems


- - - Event View message
The description for Event ID ( 0 ) in Source ( .NET Runtime ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: .NET Runtime version 1.1.4322.2379- AutoImagePOI.ex e - Common Language Runtime Debugging Services: Application has generated an exception that could not be handled.

Process id=0x158c (5516), Thread id=0x924 (2340).

Click OK to terminate the application.
Click CANCEL to debug the application..

MyBox .net: (version 1.1.4322.573)

[Plater]

Can you make your program run with the worker-process user credentials? Like the IUSER or something? Although if it didn't work as admin I'm not sure.

One thing I do know is that if the program is located on say computerA and you tell computerB to run that program located on ComputerA, you get access denied messages a-plenty.
I always have to run local copies for them to function.

[whutto]

Plater:
The program runs standalone with the user credentials in a command window and from the scheduled tasks as long as the user is logged on. But it will not run from the scheduled tasks if the user is logged off, even though the run-as user is the same..

Logging on seems to change the permissions available to the scheduled task, which I do not understand.

My problem is how to find out what specific object is generating the access denied messages.

Thanks
Weems

[Plater]

Put in some try/catch blocks and have descriptive error messages, stacktrace and such?

[TRScheel]

My guess is that when it runs as system it is attempting to access something normally given a real user (my documents, etc) but not to the SYSTEM user. I would do as plater suggested above.

[whutto]

Thanks for the suggestions. I put in a subroutine that writes to a text file and used that at various points in the logic to pin down the problem.

The scheduled task cannot access the mapped network drive that has the image folders, but the program has permissions to do that when the user is logged on. I am working with SysAdmin to set the permissions to allow this to process.

Line 131 referenced in the message is
Dim finfo() As IO.DirectoryInf o = di.GetDirectori es()
which attempts to access the network drive to get the path information.

Thanks again
Weems

The actual error message text is:
System.IO.Direc toryNotFoundExc eption: Could not find a part of the path "L:\ImageArchiv e\ArchiveForms\ ".
at System.IO.__Err or.WinIOError(I nt32 errorCode, String str)
at System.IO.Direc tory.InternalGe tFileDirectoryN ames(String fullPath, String userPath, Boolean file)
at System.IO.Direc toryInfo.GetDir ectories(String searchPattern)
at System.IO.Direc toryInfo.GetDir ectories()
at AutoImagePOI.Mo dule1.Main(Stri ng[] sArgs) in C:\Documents and Settings\HP_Adm inistrator\My Documents\Visua l Studio Projects\AutoIm agePOI\AutoImag e.vb:line 131

[TRScheel]

Thanks for the suggestions. I put in a subroutine that writes to a text file and used that at various points in the logic to pin down the problem.

The scheduled task cannot access the mapped network drive that has the image folders, but the program has permissions to do that when the user is logged on. I am working with SysAdmin to set the permissions to allow this to process.

Line 131 referenced in the message is
Dim finfo() As IO.DirectoryInf o = di.GetDirectori es()
which attempts to access the network drive to get the path information.

Thanks again
Weems

The actual error message text is:
System.IO.Direc toryNotFoundExc eption: Could not find a part of the path "L:\ImageArchiv e\ArchiveForms\ ".
at System.IO.__Err or.WinIOError(I nt32 errorCode, String str)
at System.IO.Direc tory.InternalGe tFileDirectoryN ames(String fullPath, String userPath, Boolean file)
at System.IO.Direc toryInfo.GetDir ectories(String searchPattern)
at System.IO.Direc toryInfo.GetDir ectories()
at AutoImagePOI.Mo dule1.Main(Stri ng[] sArgs) in C:\Documents and Settings\HP_Adm inistrator\My Documents\Visua l Studio Projects\AutoIm agePOI\AutoImag e.vb:line 131

If probably doesnt exist for that user. I would do create a process object that ran 'net use L <location>' before trying to connect to it with a DirectoryInfo. There might be a way to do that in code though and not through the command line.

[whutto]

Worked with the sysadmin and we came up with a workaround. Rather than using a mapped network drive, ie
L:\ImageArchive \ArchiveForms\

we are using the network IP address to access the folders, ie:
\\192.168.1.22\ e\ImageArchive\ ArchiveForms\

I am surprised that there isn't a security issue with this, but it works without any problems.

The thing to remember in running a program from the Windows scheduled tasks is that the user's logon scripts have not executed and have not set up the mapped drives, desktop, etc for that specific user.

Thanks for everyone's input.
Weems