Stack trace

[Guest]

I managed to get error checking does in my application. In using the
Exception object I can get all the information I need about the error like
the line # where the exception occurred. IS there a way I can have it also
return my the physical line of code at that line number in the StackTrace as
well?????????? This would be helpful because some errors occur just b/c the
user didn’t login, thus a needed Session variable was not on that page.

I want to distinguish between errors b/c the user didn’t login (thus
redirecting to the login page) and those errors where "real" problem may
exist.

 

[erick]

System.Diagnostics.StackTrace trace = new System.Diagnostics.StackTrace(System.Threading.Thread.CurrentThread,
true);

for (int i = 0; i < trace.FrameCount; i++)
{
System.Diagnostics.Debug.WriteLine(trace.GetFrame(i).ToString());
}

HTH
Erick Sgarbi

 

[Guest]

Didnt work, at last not the way I would like it to I actually want to see
the specfic line of code at the line# that blew up. IE: if line #45 contained
Session["myName"].ToString(), then I would redirect to login page, if the
line contained something other then "Session", then I would know thait its
probably something I need to look into. Did I do something wrong:

You code return the stack trace of:

CODE: Application_Error at offset 147 in file:line:column
\\myDomain\testsites\myC#WebApp\site\global.asax.cs:52:4
Invoke at offset 0 in file:line:column <filename unknown>:0:0 RaiseOnError
at offset 158 in file:line:column <filename unknown>:0:0 RecordError at
offset 149 in file:line:column <filename unknown>:0:0 ResumeSteps at offset
100 in file:line:column <filename unknown>:0:0
System.Web.IHttpAsyncHandler.BeginProcessRequest at offset 227 in
file:line:column <filename unknown>:0:0 ProcessRequestInternal at offset 487
in file:line:column <filename unknown>:0:0 ProcessRequest at offset 176 in
file:line:column <filename unknown>:0:0 ProcessRequest at offset 101 in
file:line:column <filename unknown>:0:0

 

[Guest]

Oh, wait it just dawned on me. How can I get a line of code from a page when
what is being used is a compiled version of my code? At the point of runtime
my code is no longer lines of text. I bet I cant do this.

Oh well

 

[Guest]

Oh, wait it just dawned on me. How can I get a line of code from a page when

what is being used is a compiled version of my code? At the point of runtime
my code is no longer lines of text. I bet I cant do this.

I bet you can, and I wish I knew how to do it too. Part of the trick is
that you need availablility of your app's pdp file where the relevant info is
located. The other part of the trick is using
System.Diagnostics.SymbolStore, and I am left baffled by the documentation.
ildasm.exe, the il disassembler, knows how to do it. jit debuggers know how
to do it. Perhaps some learned soul will tell us both how to do it.

 

[notifications]

I am not sure how you want to be using this. I only use fine grained trace
under development and not production. What exacly are you trying to achieve?
If you are trying to instrument an application I strongly advise you to take
a look at enteprise library the http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/entlib.asp
and the guidelines for exception management. if you are trying to write something
more complex (like a debugger) you should post in the CLR or Sdk newsgroup.

Furthermore, there is a way to get debugging information during production
by using System.Diagnostics.Process.EnterDebugMode and LeaveDebugMode however
it is a more complex issue to retrieve info using this approach.


HTH
Erick Sgarbi

 

[Guest]

I think you are asking this of JP rather than me, but I'll answer anyway.

I am not sure how you want to be using this. I only use fine grained trace
under development and not production. What exacly are you trying to achieve?

My environment is several XP machines which will all have different debug
versions of projects, with pdb files and whatever else is needed. The
problem is that the end users are not experienced developers, and they won't
(can't?) learn about debuggers and the .net ide. So, when a problem (an
exception) happens, we want to report back lots of info to developers on the
same network without user intervention. The shop is 24/7, so a developer
will not necessarily be available when an exception occurs. I would like to
include some source code (as does JP) because the development environment is
fluid and line numbers go out of date quickly.

To summarize, the environment is entirely development/debug but with the end
users unable and unwilling to participate in the technical aspects. The site
is physically secure - we are not concerned about deploying pdb files.
Obfuscation is not in our game plan.

Now, we could deploy all the source code with each debug project. When an
exception occurs, with stacktrace we could get source file and source line
number and read the source file to find the line. But it seems to me that
that is what the pdb file is for. The problem is, I don't see how to do it.

Alternatively, we could launch into an industrial strength version-control
enterprise and keep book on what versions are deployed on what machines so
that line numbers are all we need to work on a problem. But deploying the
pdb file seems better in all ways. In the first place, it represents truth
about how the app was built. In the second place, if a developer is
available when an exception occurs, then jit to the rescue.

All of which leaves the open question: How do I do what ildasm does? FYI,
if the technology is with .net fw objects, I want to implement using the fw
objects. If the technology gets heavily into win apis, then we are
considering running ildasm to fetch source lines.

 

[notifications]

My environment is several XP machines which will all have different debug
versions of projects, with pdb files and whatever else is needed.

The problem is that the end users are not experienced developers, and they

won't (can't?) learn about debuggers and the .net ide.
Hold that thought for a second...

To summarize, the environment is entirely development/debug but with the

end users unable and unwilling to participate in the technical aspects.
Right, can you please clarify "end users"? IMHO, "end users" are those whom
we ship the product... did you mean testers?

To summarize, the environment is entirely development/debug but with the

end users unable and unwilling to participate in the technical aspects.
I will accept that you are refering to "end users" as testers... Testers
are supposed to be experienced on what they do but they dont need to know
about debuggers.

The site is physically secure - we are not concerned about deploying pdb

files.
I would be, running software in debug mode slow down the app. As far as I
know it will disable optmizations.

Now, we could deploy all the source code with each debug project. When

an exception occurs, with stacktrace we could get source file and

source line number and read the source file to find the line. But it seems

to me that that is what the pdb file is for. The problem is, I

don't see how to do it.

I am not familiar with the software development methodology (or life cycle)
you're using so I cant give you a honest opinion but i'll say this... if
you are worried about which line of code an exception was thrown your code
is not ready for QA tests. I never heard of anyone needing to consider shipping
code (which is not necessary anyway) for discovering bugs.

Review your SDLC...Make sure exceptions you are throwing have informative
info... use unit tests, they are your best friend for fixing and chasing
bugs...have some form of continuos integration (look at http://www.martinfowler.com/articles/continuousIntegration.html
and http://cruisecontrol.sourceforge.net/)...can not stress this enough,
try to review your testing/shipping iterations, have a look at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/mtf.asp.




HTH
Erick Sgarbi
www.blog.csharpbox.com