Question

I inherited a customer facing asp.net web application, in which customers can upload files to our file servers. It works fine for all users except for one individual. Two weeks ago she tried to upload a file and received the following error:

Object reference not set to an instance of an object.

The error goes on to describe what line of code causes the error. However, this is in our production, external environment and I have debugging turned off. So this information, I am assuming is more or less bunk (the lines of code it the error is reporting really don’t make sense to me as being the cause of the error).

I know something is being accessed that is null, but I have not been able to reproduce the error in my development environment and it works fine for the rest of our user base. The same user experienced the error two weeks ago, and then tried again yesterday with a different file and received the same error.

I know this all sounds very vague, but I guess my question is does anyone have any good ideas of how to trace the user’s execution to the error so that I can get an accurate look of what line of code is REALLY causing it? Like I said I have not been able to reproduce the error, in dev, in production, internally, externally, and no other users have had a problem. My only idea was to publish a debug release to our customer facing production site but I don’t really want to do that. Thanks!

Answer 1

1. Are you SURE that the information that you’re getting in the exception is erroneous? It’s so easy to make that assumption, we’ve all done it, only to be proven wrong when you’ve spent a little longer looking at it.
2. Make sure you’ve got PDB (Debug Symbols) deployed. You can still push these out even if the site is built in “Release”, rather than “Debug” to ensure that you get appropriate line numbers in your stack trace.
   1. Make sure you deploy the matching .PDB files, ones that don’t match won’t be any use.
   2. Keep the .PDB files under version-control along with your releaseables, it makes it a lot easier to test issues if you have both, along with the code for that specific version (i.e. treat your compiled output and .pdb’s as you would your source).
3. Add some additional instrumentation to the code that logs, using something like log4net (don’t write your own logging system – other people are better at it than you, or I!) that logs as much state as possible around the area that’s encountering the issue.
   1. Make it so that the logging can be switched on or off based on a configuration setting. log4net makes it easy to do this.
   2. Make sure your logging code checks all objects that it inspects for null prior to using them, so you don’t end up with a NullReferenceException being caused by your logging code.