How many can relate do this?
Server Error in / Application
Object reference not set to an object
Description: Object reference not set to an object.
Exception Details: System.NullReferenceException: Object reference not set to an object.
Source Error:
Line 56: posts.Add(post);
On a more serious note, what are the first things you look for when you see the
yellow screen of death? Half the time the debug trace isn't actually telling you what the problem is (understandable I guess).
I must admit, I still use Response.Write more than I should. I just get lazy going through the debugger. What techniques do you use to debug the problem?
If I'm unable to identify/resolve the issue using the error message that the page presents to me, I will typically try to use the Windows Event Viewer to help me identify what is causing the issue.
For example, SharePoint errors are sometimes far less than descriptive. So, I'll combine what I'm seeing on the Y.S.O.D. with error messages from the Event Viewer to help me narrow down the cause.
I will do my best to ask a co-worker or other associate that I think might have some experience that might help. If I'm still unable to identify the cause, I will resort to Google armed with all the information.
Here's how I try to reduce the number of YSODs. One of the first things I do when starting work on an app is to create a custom exception class.
Add properties such as the SQL
statement being run. Two display
message text fields, one for display
to users, one for display to
developers (in debug mode) Who is
the logged-in user. Get all the form
variables so you know what they were
trying to enter.
Log the errors somewhere (event log
is good, if you can access the web
server; logging to the database is
less successful when so many
exceptions are inability to access
the database).
Create code in the MasterPage or web page base class Page Error events and Application Error events to do the logging.
Create a custom error page. When in
debug mode, the custom error page
displays everything. When not in
debug mode (production), display
only selected properties of the
custom exception.
Investing the time up front to do this will save you many hours of anguish later.
I usually do my debugging on my local machine with the Cassini web server (comes with VS 2005/2008). If I see an exception on my QA or, heaven forbid, my production box it's usually because I forgot to update my connection strings so that they point to the QA/production database instead of my local machine.
In other cases, I've found the stack traces to be very helpful in determining where to provide breakpoints so I step through it in the debugger and examine the data at runtime. The only time I've written any debugging information on the page was when trying to find some performance issues that I couldn't replicate on my developer instance. In this case I wrote some hidden fields that contained timing information about various parts of the render process.
the error info provided, assuming you are in debug mode, will give you information as to what line the error actually occurred on, along with the lines of code leading up to the error. This info should give you a good start on defining where to set your break points for debugging.
I was once in your shoes many moons ago, using response.write for debugging. Once you start using the IDE and debugger as it's intended you'll find yourself pulling out less hair and getting to the solutions much faster.
Also, opening up the immediate window while debugging is gonna make your life even more happy.
Use a decent logging framework such as log4net, and be liberal in your use of DEBUG-level logging.
It's essentially a neater version of your Response.Write approach, which can be left in your production code and "switched on" when required.
Related
In a BizTalk mapping, I use a scripting functoid from an external assembly. The assembly reference is added. When the mapping is used, however, it causes the following error:
'ScriptNS0:DoSomething()' has failed.
Now, this could mean any number of things that's wrong about this scripting functoid. However, even when a try-catch block is placed around the entirety of the C# code and the catch throws a custom exception, a proper new deploy yields the very same error and not the newly added custom one.
This would suggest that the mapping has been started and that something causes an error as soon as it hits the scripting functoid, but without actually performing even the slightest action within the function. When looking at the XSLT of the map, it seemed perfectly fine. The reference to the external assembly has been checked over and over again (and references of this external assembly as well). Everything looks fine and very much like many other mappings I've seen, yet still the outcome is the error above.
I realise this is a rather vague question, but does anyone have a clue what's going on here?
You'll have to test this out in Visual Studio. A few things to keep in mind:
It's very possible that your actual data is causing an exception (it's an edge or corner case that you're not testing for in your console application).
Throwing exceptions in external assemblies doesn't always translate well in an XSLT map, particularly when you do it on a Port. IIRC it's handled slightly more gracefully in an orchestration.
If you can't reproduce this in Visual Studio testing or a unit test, you should be able to attach the Visual Studio debugger to the appropriate BtsNtSvc.exe or BtsNtSvc64.exe (or w3wp.exe if it's running in IIS/isolated host). Set a breakpoint on the entrance to your custom function, step through, see what's going on. If you're only able to reproduce it in a non-dev environment, see if you can set up remote debugging - but you may be better off enhancing the logging on the functoid in that case and redeploying if possible.
In general, I always try to do the following in custom functoid scripts:
Avoid throwing exceptions - use methods like TryParse rather than Parse, and on failure to parse return an error string or an empty string or the original string (depending on requirements/tolerance of destination system) rather than throwing an exception. If you do throw an exception, it's unlikely to be handled gracefully and unlikely that the exception type or text will make it back to a user/administrator.
Do error logging in these scenarios instead - generally using the Windows Event Log (System.Diagnostics.EventLog.WriteEntry). Make sure to use a properly registered event source, ideally one that matches your application name and is registered by your installation process, but at least one that exists on the computer to avoid throwing another nonsensical exception! This will allow developers/admins faster insight into what's going on next time.
Relatively new to working with .net but learning a lot while working with a developer at work who at times can be stubborn. Recently the asp.net web form we are developing has periodically started crashing such that every time a link is clicked that retrieves an object (an in process form that the user had previously filled out) the user gets the following application error: "Sequence contains more than one element."
All the sources I looked at online suggested that this was an InvalidOperationException thrown by the Single method and could be avoided by (a) eliminating the source of duplicate elements or (b) using the First method instead of the Single method.
The developer told me that I had no idea what I was talking about and that this was a caching error that could only be solved via an IIS reset.
Since this has been happening periodically I'm a bit concerned that doing the IIS reset doesn't address the underlying issue that creates the exception. Any one have any ideas? Is my developer right to say that an IIS reset is the best way to address this?
Thanks!
According to me your developer might have used LINQ. If he used single() or SingleOrDefault() or First() , tell him to replace those method with FirstorDefault() method.
A lot of time can pass between the moment a stack trace is generated and the moment the stack trace is thoroughly investigated. During that time, a lot can happen to the file in question, sometimes obscuring the original error. The error might have been fixed in the meantime (overlapping bugs).
Is it possible to get Stacktraces that show the offending file at the time of the error?
Not elegantly, and you normally don't want the user browsing through code that's throwing unexpected exceptions anyway (open door to an attacker).
Usually, what happens in a dev shop is that the user reports an error, stack trace, and the build it occurred on. As a tester, you can grab that build from your archives (you ARE keeping an archive of all supported releases somewhere handy, RIGHT?), install, run, and try to reproduce the error, working with the user to provide additional info as necessary. I've seen very few bugs that couldn't be reproduced EVENTUALLY, even if it required running the program against a backup of the user's production database to do it.
As a developer, you can download that build's source code from your version control repository (you ARE using version control, RIGHT?), and examine the lines in the stack trace to try to discover the problem by inspection, and/or build and run it to reproduce the error. Then, you go back to the latest source version, build, and run the same steps (a UI automation system can help out here), and if you don't get the error, someone else already found and fixed it. If you still get the error, you also got an updated stack trace with lines that match the current build, allowing you to set your breakpoints and step through.
What KeithS said, plus there are ways to capture more helpful state information at the time of the Exception using the Exception.Data property. See http://blog.abodit.com/2010/03/using-exception-data-to-add-additional-information-to-an-exception/
While KeithS' answer as pretty much correct, it can be easier and more elegant than you think. If you can collect a dumpfile (instead of just a stack trace), you can use a Symbol Server and Source Server in combination with your debugger to automatically pull your correct-version code from source control.
For example: if you enable PDB output and source-server integration in MSBuild, and upload the resulting PDBs to a symbol server, Visual Studio can automatically load the correct source control from a TFS or SourceSafe repository based on the information in a minidump.
we are getting a stack overflow in production ~ 2-4 times / day
We cannot reproduce this is in dev environment, nad given this is a web app with probably ~100 concurrent users at any one time, I'm struggling to work out how best to track this down.
Is there anyway to get any more info from event viewer - happy to install some form of listener tool - even if i can just get teh thread identity (set to the current user) that'll help - although the dll + class / function woudl be great!
Or is it just a matter of digging, trying to reproduce or adding some tracing in??
There is an IISDiag tool that you can run on production IIS to analyze crashes. Some information here:
http://support.microsoft.com/kb/919790
It's not just for leaks -- it dumps something like a CORE file that you can analyze later.
Slap on Elmah for exception logging. Adding logging of unhandled exceptions using Elmah only require you to drop in the assembly into the application bin folder and to add Elmah section in the web config for a basic logging scenario.
If the logs is not enough to determine the error source you can create memory dumps of the state of the failing application using DebugDiag. There is a guide on how to use it here.
You can put a global exception handler in the global.asax file. Put an exception handler in and then write the stack trace to the event log. This article has a pretty good summary of how to do it though I'm sure there are a lot of others too. Once you know where the error is occurring you can put in some additional logging in the function that the error is occurring in and hopefully narrow it down until you find the specific problem.
I'm having a simple ASP.NET application hosted on my local IIS6, under Vista.
It contains a button that when I click I execute a piece of code for recognizing the text in a WAV file (using the System.Speach.Recognition.SpeechRecognition class) and display the text in a label.
The code works great on a desktop application, and it almost works on the web one... I say almost, because if I debug, I can see that the recognizer returns the correct text from the WAV, I can see that I am finishing the handler for the button click with no error, but nothing gets displayed in my page, and the page appears like loading... it's hanging, or something... No errors, no timeout, nothing. Just loading...
I don't know if this detail helps, but in order to make the piece of code that was already working on the desktop application work on the web application, I had to set the identity of the ApplicationPool of my application to LocalSystem (security breach, I know). Otherwise, I would have received a Access Denied error (0x80070005(E_ACCESSDENIED)).
Do you have any ideea why the call hangs like that? I'm fighting with this for more than two days, time pressures me, and I have no clue... Any help is really welcomed!
Thanks!
After another one week of stuglles, I found an overcome to the problem. I'm posting this just so other that might have this problem find the solution faster.
The solution was to call the method for making the speech recognition on a different thread. I think this forced the release of all resources in that thread after the recognition ended.
I cannot make any sense why this even happened on the first place (I used using blocks and I closed and disposed all the object in all the imagining ways), but I suspected to be a memory release problem...
Anyway, a very simple call on another thread fix it!