My C# application is returning 0xE0434352 to Windows Task Scheduler but it is not crashing

Question

I have written a few C# apps that I have running via windows task scheduler. They are running successfully (as I can see from the log files that they are writing ) but windows task scheduler shows them returning a last run result of 0xE0434352. Is there something I need to do in my C# application so that it returns a success code to the windows task scheduler?

Maleeny

What does your task do? – Zygophyllaceous

#6245439 – Enterostomy

The Task executes my C# application with the argument -a. The application is executing as normal and it isn't crashing so I'm not sure why it looks like windows scheduler is receiving an error code. – Maleeny

Your assumption that it is not crashing is not correct. 0xe0434352 is a low-level CLR exception code. Get ahead by writing an event handler for AppDomain.CurrentDomain.UnhandledException and log the value of e.ExceptionObject.ToString() – Oeildeboeuf

Thanks Hans, you were correct. this article helped me to setup the even handler as you suggested msdn.microsoft.com/en-us/library/… – Maleeny

Answer 1

Another option is to simply use the Application log accessible via the Windows Event Viewer. The .Net error will be recorded to the Application log.

You can see these events here:

Event Viewer (Local) > Windows Logs > Application

Blew

+1: This is way more easier to detect the error. In my case, my application was suppose to send out an email during an exception and smtp was not configured correctly within the config file. Even the program did never go to the catch block, the error was happening. Fixing the config fixed the problem. – Individuate

Event log in my case included stack trace, very useful indeed. – Stretto

Just to be totally pedantic, note that there may be two errors in the event log. Don't focus only on the latest one; the first one may contain more interesting information. – Rift

In Win10 (maybe others too) the path in Event Viewer is: EventViewer/Windows Logs/Application – Searchlight

The stacktrace of the .NET exception is logged under the source .NET Runtime – Wagram

@BazGuvenkaya A duplicate key of the config file was specified twice, just deleted one of the instances, and resolved the issue. Thanks for your valuable input! that pointed me in the right direction. – Panhellenism

Answer 2

When setup a job in new windows you have two fields "program/script" and "Start in(Optional)". Put program name in first and program location in second. If you will not do that and your program start not in directory with exe, it will not find files that are located in it.

Outlandish

Exactly. If you are using relative paths in your code, you need to specify the program location. It is usually the path to the exe file. – Katmandu

I just want to point out this is very counter intuitive from MS. – Edmon

Before providing the "Start in" my application was failing to locate a configuration file that it uses from the same directory. – Unpremeditated

Answer 3

Hans Passant was correct, 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 was able to find the exception that was occurring and corrected it.

Maleeny

I added a handler as described and the exception went away. Guess I'll never know... – Garin

Answer 4

I was referencing a mapped drive and I found that the mapped drives are not always available to the user account that is running the scheduled task so I used \\IPADDRESS instead of MAPDRIVELETTER: and I am up and running.

Sethrida

I had a similar issue where the UNC network path could not be accessed (different users), and I tried using the credential manager to add the required account information. – Reverberator

Answer 5

In case it helps others, I got this error when the service the task was running at didn't have write permission to the executable location. It was attempting to write a log file there.

Hames

This was the one. My application wat writing to a folder other than the folder it was running from. – Montpelier

Answer 6

I had this issue and it was due to the .Net framework version. I had upgraded the build to framework 4.0 but this seemed to affect some comms dlls the application was using. I rolled back to framework 3.5 and it worked fine.

Thulium

I need to down grade my version but then I'm getting the error of re-installing many DLLs and also my website is not able to run. – Soliz

Answer 7

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

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

Dike

Answer 8

I was getting the same message message within dotNet Core 2.2 using MVC 5, however nothing was being logged to the Windows Event Viewer.

I found that I had changed the Project sdk from Microsoft.NET.Sdk.Web to Microsoft.NET.Sdk.Razor (seen within the projects.csproj file). I changed this back and it worked fine :)

Futures

Answer 9

In my case it was because I had message boxes. Once I commented that code out, it started working. I remembered that could be a problem when I looked at the event log as suggested in this thread. Thank you everyone!

Cointreau

Answer 10

I encountered this problem when working with COM objects. Under certain circumstances (my fault), I destroyed an external .EXE process, in a parallel thread, a variable tried to access the com interface app.method and a COM-level crash occurred. Task Scheduler noticed this and shut down the app. But if you run the app in the console and don't handle the exception, the app will continue to work ...

Please note that if you use unmanaged code or external objects (AD, Socket, COM ...), you need to monitor them!

Ensemble

Answer 11

Also message box in PowerShell. I converted PowerShell script to exe. When running as admin it's worked but in task schedule I received this error also. There was an line in PowerShell script with write-output. After commented this line and compile new exe Task Schedule was completed successfully.

Misestimate

Answer 12

It is permission issue in my case the task scheduler has a user which doesn't have permission on the server in which the database is present.

Aurangzeb