C # application returns 0xE0434352 to Windows task manager, but this is not a failure

Question

I have written several C # applications that I run through the Windows Task Scheduler. They work successfully (as I see from the log files that they write), but the Windows task scheduler shows that they return the result of the last run 0xE0434352 . Is there something I need to do in my C # application so that it returns the success code to the Windows task scheduler?

Answer 1

Another option is to simply use the application log, available through the Windows Event Viewer. An .Net error will be written to the application log.

Answer 2

When setting up a task in new windows, you have two fields: program / script "and" Start (optional) . "Put the program name in the first place and the program location in the second. If you do not, and your program does not start in a directory with exe, it will not find the files that are in it.

Answer 3

Hans Passant was right, I added a handler for AppDomain.CurrentDomain.UnhandledException, as described here http://msdn.microsoft.com/en-us/library/system.appdomain.unhandledexception(v=vs.71).aspx I managed find the exception that occurred and corrected him.

Answer 4

I referenced the mapped drive , and I found that the mapped drives are not always available to the user account performing the scheduled task, so I used \\IPADDRESS instead of MAPDRIVELETTER: and I am working.

Answer 5

In case this helps others, I got this error when the service on which the task was running did not have the right to write to the executable location. He tried to write a log file there.

Answer 6

I had this problem and it was because of the .Net framework version. I upgraded the assembly to framework 4.0, but it seems to have affected some of the comms dll packages that the application used. I rolled back to 3.5 framework and it worked great.

Answer 7

I have the same error, but I fixed it by changing the path for reading files from "ConfigFile.xml" to AppDomain.CurrentDomain.BaseDirectory.ToString () + "ConfigFile.xml"

In my case, this error is due to a file path error, because the task manager starts the program from "System32" as the starting path, but in the folder that we thought.

Answer 8

If you use "My.MySettings.Default", you may need to change the user who runs this application