locked
Winforms - error logging RRS feed

  • Question

  • Hello, I am wanting to know how to best handle the logging of exceptions within a 2.0 winforms application.  I am currently using the Exception Handling Application Blocks and writing all requried information to the local machine's event log which is fine but unless it is combined with another means to inform support centrally (eg email), it will be a drag on time manually monitoring individual user's machines event log.

    I am considering using all of the options below :-

    - send an email to centralised (support) email address

    - write to the local machine's event log and view remotely

    - rollback any core system updates then log error information to a database table

     

    Thanks

    Travis

    Friday, June 8, 2007 9:49 AM

Answers

  • I would suggest logging errors to a database table.

     

    We have done just about everything for logging. Our oldest applications send emails to a distribution list, and our Help Desk staff maintains the users who are on that list. But because those older applications send out success and failure messages (they are automated systems), we now get a large volume of email from the list. So it is largely ignored, and fills up our mailboxes needlessly.

     

    We spent quite a bit of time trying to set up our services and automated jobs to write to the event log. We abandoned this approach, however, because it is a huge pain in the $$$ to get an account the priviledges it needs to write to the event log, especially in Win2k and 2k3 server.

     

    For client applications, writing to each PC's event log is also a pain...but the pain comes in trying to access the messages. If you want to see what messages different users are getting, you have to connect to each PC.

     

    And so now we've moved to logging all errors to a common database, so we have a single place to look for all (or at least our newer!) applications. I'm a big fan of providing lots of information for debugging purposes, so we log the application name, user name, error message, stack trace and a few other odds and ends. We also have a Name/Value table that we use to store things like parameter values or local variables, where appropriate, to help in the debugging process. And our logging routine also can scan through and report row errors for all tables an a given dataset, if the error is a database error. I usually cap that off at up to 10 row errors per table...sometimes our record sets are rather large and if i can't tell what the problem is with 10 rows more isn't likely to help.

     

    I can't emphasize enough the importance of really thorough error logging. I've wasted countless hours in countless systems because of prior developers who put off error handling until later...from way back in VB3 and the infamous "on error resume next", to the current try/catch where the only code in the catch block is to write the error out to the console or the debug window.

    Friday, June 8, 2007 9:38 PM

All replies

  • Friday, June 8, 2007 7:16 PM
  • I would suggest logging errors to a database table.

     

    We have done just about everything for logging. Our oldest applications send emails to a distribution list, and our Help Desk staff maintains the users who are on that list. But because those older applications send out success and failure messages (they are automated systems), we now get a large volume of email from the list. So it is largely ignored, and fills up our mailboxes needlessly.

     

    We spent quite a bit of time trying to set up our services and automated jobs to write to the event log. We abandoned this approach, however, because it is a huge pain in the $$$ to get an account the priviledges it needs to write to the event log, especially in Win2k and 2k3 server.

     

    For client applications, writing to each PC's event log is also a pain...but the pain comes in trying to access the messages. If you want to see what messages different users are getting, you have to connect to each PC.

     

    And so now we've moved to logging all errors to a common database, so we have a single place to look for all (or at least our newer!) applications. I'm a big fan of providing lots of information for debugging purposes, so we log the application name, user name, error message, stack trace and a few other odds and ends. We also have a Name/Value table that we use to store things like parameter values or local variables, where appropriate, to help in the debugging process. And our logging routine also can scan through and report row errors for all tables an a given dataset, if the error is a database error. I usually cap that off at up to 10 row errors per table...sometimes our record sets are rather large and if i can't tell what the problem is with 10 rows more isn't likely to help.

     

    I can't emphasize enough the importance of really thorough error logging. I've wasted countless hours in countless systems because of prior developers who put off error handling until later...from way back in VB3 and the infamous "on error resume next", to the current try/catch where the only code in the catch block is to write the error out to the console or the debug window.

    Friday, June 8, 2007 9:38 PM
  • Gents, thanks for the suggestions - nobugz, the link you provided contains some useful information on implementing a Winforms exception handling per se, which is kinda related to another thread I have outstanding :-

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1672270&SiteID=1

    ...but as far as outputting exception information for support resources to monitor,
    I was looking for advice more on strategy.

    Thanks Christopher for giving a very descriptive account on how you have gone about handling errors for support to pick up - I agree, a database solution is probably the best way to go, but I think I'll also log to the local machines event log as well just to make sure I have coverage for those occasions when for one reason or another it all goes pear-shaped and doesn't reach the database (eg db connection or corruption)

    Thanks for both responses...

    Many thanks
    Travis

    Wednesday, June 13, 2007 10:02 PM
  • Hi,

    I would suggest two things.

    If the application is a two tier application containing a server and a client app. Then it is always advisable to store a user friendly message in a client log file. In case of Server application, in case there is a exception , we can record it in the Db.

    Thanks,

    Sangram

    • Proposed as answer by SangramMCP Thursday, October 23, 2014 9:49 AM
    Thursday, October 23, 2014 9:41 AM