Managed Exceptions - 06
- Posted: May 01, 2012 at 3:57 PM
- 43,312 Views
- 6 Comments
Download PPTX slide here: Part 6
Some exceptions don't cause your application to crash. Some do. Either way, developers should work to rid their applications of exceptions for both stability and performance reasons. Special guest Mario Hewardt joins us as we discuss how to detect the presence of these exceptions, how to gather vital data on them in a relatively non-intrusive fashion, and how to find root cause. And since this is all done in the production environment, we won't have Visual Studio available.
Comments Closed
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums,
or
Contact Us and let us know.
More posts in this series
-
High CPU Hangs - 05
-
Managed Exceptions - 06
-
Preparing to troubleshoot memory pressure issues:…
Follow the Discussion
Oops, something didn't work.
What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in. You need to be signed in to Channel 9 to use this feature.What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in and view them all on your notifications page.sign up for email notifications?
Good demos.
Would like to have slides available for download.
I have an application with an issue that only happens in prod. It's an intermittent problem occurring anywhere from once/twice a day to once a week or every other week. When it happens the server will pick a seemingly random .css or .js file to give 302 redirects back to the forms auth. login page. Restarting the app pool fixes the issue but I'm at a loss with how to debug it. It's not an error, not a performance issue, no CPU or memory spikes, it just stops serving that .css or .js file! Using the standard forms auth. provider. Any idea what I can look for or how to debug this issue?? Please!
- Jim
@Jim:The hardest issues to start troubleshooting are the ones that A) don't repro reliably, and B) repro infrequently.
There are many variables that could come into play with your issue (OS, load balancer configuration, etc., etc.) You may consider starting with IIS logs, event logs... maybe set up a default DebugDiag Crash Rule on the target process. You're not looking for a crash, but DD will keep a log of your target exe that includes things like exceptions thrown. When the problem repros, look at this log to see if you see a signature that precludes the issue.
Ultimately, ETW & PerfView may be what helps the most.
Awesome series!
Could you please show "live debugging" using windbg and more details about common performance issues in asp.net? (e.g. bottlenecks, threads vs io completion ports, proper load testing, etc).
Many thanks and keep up the good work!
@JorgeF:Great minds think alike? One of the sessions I'm preparing for next time is directly related to proper load testing for ASP.NET. One of the other sessions, if I can complete it in time, may involve some live debugging. Because this series focuses on the production environment, and you'd never ideally want to do a live debug in prod, I don't plan to cover too much of this (unless, of course, folks keep asking for it).
@BradL: great!!! Many thanks!
Remove this comment
Remove this thread
close