2

I am writing a task scheduler to manage a large number of distributed jobs. The jobs themselves are C# console applications running on .Net 4.6, and controlled by a local agent. Many of these jobs crash, throwing a .Net exception, which launches the annoying window to attach a debugger or close. I have written the agent to attach as a debugger in order to prevent this popup, and to also kill all running jobs in case the agent is closed (they act like child processes in this way), using the example from Kill child process when parent process is killed

My next goal is to be able to read the exception and stack trace in case of a job crashing. How can I read out the exception information as a managed debugger?

Community
  • 1
  • 1
Superman
  • 3,686
  • 6
  • 34
  • 46
  • Did you try looking at the [MDbg](http://www.microsoft.com/en-us/download/details.aspx?id=2282) example? – Thomas Weller Sep 22 '15 at 14:19
  • 2
    So you're letting exceptions bubble up to the console unhandled? Why not handle the exceptions at as high a level as you can, and exit the process gracefully (logging any exception detail, of course). – D Stanley Sep 22 '15 at 14:30
  • Well behaved jobs catch all their exceptions and exit gracefully. But every so often an uncapturable out of memory or poorly written job gets into the environment, and I'd like to provide that feedback. – Superman Sep 22 '15 at 15:38
  • As @DStanley said, you should catch the exception in the application. If you are running 'unknown' console applications, you can load the `.exe` file using reflection, find the entry point and execute the method in your wrapper app. – exyi Oct 14 '15 at 15:55

0 Answers0