[RESOLVED] Problem with getting line number on errors

Afternoon,

I have recently found i'm getting a few unhandled errors that I don't know the cause of so I set about trapping those and recording the information.

Using a few different websites I have put together the following code in my Program.cs file:

Code:

---

using System;
using System.Collections.Generic;
using System.Linq;
using System.Windows.Forms;
using System.Threading;
using System.Diagnostics;

namespace WindowsFormsApplication1
{
    static class Program
    {
        /// <summary>
        /// The main entry point for the application.
        /// </summary>
        [STAThread]
        static void Main()
        {
            Application.ThreadException += new ThreadExceptionEventHandler(Application_ThreadException);
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
            Application.Run(new Form1());
        }

        static void Application_ThreadException(object sender, ThreadExceptionEventArgs e)
        {
            DialogResult result = DialogResult.Abort;
            try
            {
                StackTrace trace = new StackTrace(true);

                StackFrame frame = trace.GetFrame(0);

                result = MessageBox.Show("Whoops! Please contact the developer with the following information:\n\n" +
                    "Message: " + e.Exception.Message + "\n\n" +
                    "Source: " + e.Exception.Source + "\n\n" +
                    "Method: " + frame.GetMethod().Name + "\n\n" +
                    "Filename: " + frame.GetFileName() + "\n\n" +
                    "Line: " + frame.GetFileLineNumber() + "\n\n" +
                    "Column:" + frame.GetFileColumnNumber() + "\n\n" +
                    "Data: " + e.Exception.Data + "\n\n" +
                    "Helplink: " + e.Exception.HelpLink + "\n\n" +
                    "InnerException: " + e.Exception.InnerException + "\n\n" +
                    "Targetsite: " + e.Exception.TargetSite + "\n\n" +
                    "Stack Trace:\n" + e.Exception.StackTrace, "Application Error",
                  MessageBoxButtons.AbortRetryIgnore, MessageBoxIcon.Stop);
            }
            finally
            {
                if (result == DialogResult.Abort)
                {
                    Application.Exit();
                }
            }

        }


    }
}

---

Whilst most of this works, i'm not getting anything back to tell me the line and column number, instead they are just reported as 0's.

All I need is it to tell me the error type, file it happened in, line and colum number so if someone can point me in the right direction or tell me what i've done wrong i'd greatly appreciate it.

I am using Visual C# 2010 Express.

Some general errors do not have specific line since they're not belong to certain line but they're more globally errors.

Try deploying the PDB file along with the EXE. It contains metadata that maps the compiled output back to the original source code. It is what provides the error location in the source code.

Quote:

---

Originally Posted by jmcilhinney

Try deploying the PDB file along with the EXE. It contains metadata that maps the compiled output back to the original source code. It is what provides the error location in the source code.

---

I didn't think that was available with the Express version?

Did you look in the output folder? Is there a PDB file there along with the EXE?

Quote:

---

Originally Posted by jmcilhinney

Did you look in the output folder? Is there a PDB file there along with the EXE?

---

Yes sorry, it is there. I'm sure I read it wasn't available with Express so didn't think to look.

I've tried to open the file but looks like i'm not getting the right conversions. I tried a program called iSilo but it's still mostly gibberish.

What information can be pulled from this file? Is this something each user will have who install the program? I should probably add that due to system restrictions, I have installed my app via ClickOnce, will this be an issue?

Regards,

You don't open the file. As I have already said, just deploy it with the EXE. If you open the Publish page of the project properties then you can configure things like what files get included in the publish. I don;t have Express but, in VS, I clicked the Application Files button and checked the Show All Files box and I could then include the PDB.

Quote:

---

Originally Posted by jmcilhinney

You don't open the file. As I have already said, just deploy it with the EXE. If you open the Publish page of the project properties then you can configure things like what files get included in the publish. I don;t have Express but, in VS, I clicked the Application Files button and checked the Show All Files box and I could then include the PDB.

---

Sorry for the late reply and thank you for your help so far.

Ok, I see where to include the pdb file within the publish and have now enabled that. From what I understand this will now provide me with stack trace info, correct? Does that mean that my original code will now work fully?

Going a couple of steps forward, what would be the easiest way to have these unhandled errors send to me in a full email report? Do you have any examples or links I can have a look through?

A PDB file is a "description" file that the .Net framework uses to "figure out" where in your debug code an error happened when an error occurs in the compiled file (the EXE).

It doesn't have the contents of the raw source code, but it has line numbers and function names, which can be given to the developer for their benefit in helping to trace problems.

Without the file, the error is thrown, but no stack trace or line numbers. With the pdb, you get the stack trace and line numbers.

That's it.

As for how to handle errors gracefully, there are many articles online about developing a robust error handling procedure. In my case, I use a myriad of try/catch functions, some custom "throw" statements and try to be as specific in my messages as I reasonably need them to be in order to know what the problem is. In fact, most of my programs follow this paradigm for my error messages:

Tell the user an error occurred.
Tell them what I was trying to do.
Tell them what I expected to happen.
Tell them what really happened.
Tell them what they might do to fix the problem, if I have any ideas.

An example of one of my errors:

Quote:

---

An error occurred while trying to open "testfile.dat".

The format of the file was not a format that this program can read.

Double check that you specified the correct file, that no other programs are accessing it, and that you have permissions to open the file, then try again. If you see this message again, contact support.

---