Getting VB.NET line numbers in stack trace

Question

I have a VB.NET 2010 Winforms application where I'd like to include line numbers in the stack trace. I've read the following question and answers:

how to print out line number during application run in VB.net

Which mentions "you always need to include the PDB file with your code, which contains debugging information that is used in situations like this". Under advanced compiler settings I've tried "Generate debug info" as "pdb-only" and "full" for my release build and confirmed that a fresh PDB file is generated in the same directory as my EXE. However the following test code generates a line number of zero for each stack frame and doesn't return a filename:

    Dim st As StackTrace = New StackTrace(ex)
    For Each sf As StackFrame In st.GetFrames
        MsgBox("Line " & sf.GetFileLineNumber() & sf.GetFileName)
    Next

However the following code straight after it generates an otherwise good looking stack trace so it doesn't seem to be a problem with the exception handler in general:

ExceptionDetails.Text = ex.GetType.ToString & "(0x" & hr.ToString("X8") & "): " & ex.Message & vbCrLf & ex.StackTrace

I can't seem to find any other likely settings under the project configuration and wondered if anyone had ideas on other things that may cause this problem. All the solutions I've found searching here and elsewhere just seem to suggest making sure the PDB is in the same path as the executable.

Solution 1

From the documentation of the constructor you're calling:

The StackTrace is created with the caller's current thread, and does not contain file name, line number, or column information.

Try using:

Dim st As StackTrace = New StackTrace(ex, True)

instead, which uses this constructor. The second constructor parameter is described as:

true to capture the file name, line number, and column number; otherwise, false.

Solution 2

This question was solved some time back but I thought I'd share the final working function that I've been including in my projects recently. It returns the initial exception information and full stack trace at that point followed by the line numbers and filenames leading up to the exception from the stack trace.

Public Function GetExceptionInfo(ex As Exception) As String
    Dim Result As String
    Dim hr As Integer = Runtime.InteropServices.Marshal.GetHRForException(ex)
    Result = ex.GetType.ToString & "(0x" & hr.ToString("X8") & "): " & ex.Message & Environment.NewLine & ex.StackTrace & Environment.NewLine
    Dim st As StackTrace = New StackTrace(ex, True)
    For Each sf As StackFrame In st.GetFrames
        If sf.GetFileLineNumber() > 0 Then
            Result &= "Line:" & sf.GetFileLineNumber() & " Filename: " & IO.Path.GetFileName(sf.GetFileName) & Environment.NewLine
        End If
    Next
    Return Result
End Function

Solution 3

Try using the

public StackTrace(Exception e, bool fNeedFileInfo);

Constructor and setting fNeedFileInfo to true

Comments

[CrazyTim]

This is fantastic. Thanks for posting :)

[Oliver]

For me this is only working if PDB files are distributed too. Am I missing something? If PDB is not distributed no "Line" or "Filename" info is shown.

[PeterJ]

@Oliver that's right the PDB contains the line numbers and filenames (I believe they don't contain much else actually) so you do need to distribute them for that to work.

[Oliver]

@PeterJ sure I am missing something here...If PDB is distributed ex.ToString is giving all information needed including line number and file, at least in scenarios I have worked. Is there any scenario where line/file is not in the information of exception?

[PeterJ]

@Oliver at the time I asked the question I didn't know ex.ToString gave all the information so I think I went down this path to try and get the line numbers, but other than giving the Win32 exception code which is sometimes handy and allowing some custom formatting this method doesn't have an advantage over using that. Either way you need the PDB file so if you're happy with the output of ex.ToString you might as well stick with that.

[Oliver]

@PeterJ thanks for clarifying. It can be useful to have exception code in some situations.