We were getting lots of unhandled null reference exceptions in our application as below.
System.Web.HttpUnhandledException: Exception of type
'System.Web.HttpUnhandledException' was thrown. --->
System.NullReferenceException: Object reference not set to an instance
of an object. at
To get the exact line numbers in the error logs we deployed PDB files in the production environment with PDB only option enabled in release mode.
Now we are getting the line numbers error description but the lines numbers are always pointing to finally block where this is no possibility for the error to occur.
In the Project properties when give the build in release mode the Optimize code will be checked, we found that due to this option the line numbers are incorrect.
Now we are planning to give a deployment in production with this option unchecked so that we will get the correct line numbers. Wanted to check if this will have any impact to the performance of the application if we deploy with this option unchecked to production environment.
Please let me know incase if you have tried this or has come across such scenarios.
Yes, it certainly may have impact on performance, that's what the option is there for.
Basically, you have two options:
Check optimize. This way, your code will be easier to debug, but it may be less efficient.
Don't check optimize. This way, your code will be most likely more efficient, but also harder to debug.
The difference is because if you turn optimize on, the compiler will perform more optimizations, which may transform your code so that line numbers are not accurate, you can't get the value of local variables, etc.
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.
I get an EXC_BAD_ACCESS error at a place that doesn't have anything to do with the root cause. I fortunately found the reason to be an array that was too small for the following statement [data getBytes:&tcpBuffer length:i];.
Now my question: I tried all these theree methods - but without success:
Using NSZombiesEnabled did not change anything in the debug window printout
When I set the scheme to debug and to use Leaks instrument it starts the leaks instruments but I don't see the debugger.
When I just run the app in iPhone Simulator and the start Instruments separately, selecting the running app as a target (in the pop-up-menu in Instruments) it stops with an error saying something like "couldn't find the target ".
How does one find the root cause in cases like that? Keep in mind, at the end, it wasn't even a Zombie error! This error message is REALLY more confusing than helpful!
(luckily I just thought of my array, but surely, the next time this will haunt me somewhere else)
It's quite likely that the place you get the EXC_BAD_ACCESS will not be related to the root cause. It could be related and could therefore offer a clue. But that's not certain.
To answer your points:
NSZombiesEnabled will only have an effect if you invoke a method on an object that has been deallocated. That might not be the cause of your EXC_BAD_ACCESS.
Using Instruments is separate to the debugger. If you profile in Instruments, the debugger is not active. Basically, it's a different tool.
This should be ok. Check that your Build Configuration is set to "Debug" and not "Release".
Here's a great link on what causes EXC_BAD_ACCESS and how to track down the root problem:
Lou Franco's Understanding EXC_BAD_ACCESS
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.
Why do server errors occur on running a solution, even if the solution is building successfully?
Compile time versus run-time errors. See this stackoverflow thread for the difference between these two.
From wikipedia:
Thus, for example, a "run-time error" is detected only during the execution of the program, whereas a "compile-time error" is detected by the compiler before the program is started.
It's impossible for the compiler to catch all errors beforehand: see the 'halting problem'.
There are several possibilities:
Difference in run-time vs. compile-time environments (version of .NET, version of IIS, system-level web.config or machine.config or applicationHost.config, etc)
Run-time errors vs. compile-time errors
Different security environment / permissions
Different database connection string requirements
Using IIS vs. Cassini
If you have dynamic references (eg. if you're using NHibernate, for example), it's possible that there are references to an assembly that's not present. These kind of references cannot be picked up by the compiler. It's only one of many possible situations where you'll get a run-time error that's not logic related.
As Q8-coder said, what is the error? Impossible to give solutions without knowing what the error is.
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.