How can I debug "Object reference not set to an instance of an object" in VS2013?

Question

I have a c# Azure project that is just a web api, and wanted to remove some of the non-API default components (welcome page, help, etc). After doing so, when launching the application, I get an error message "Object reference not set to an instance of an object." I've seen this before when doing things in Azure, and somehow got around them each time. My question really is: how can I debug this error on my own? This error description is woefully lacking in detail (there's no call stack or anything, as if the app hasn't yet launched, and the dialog is modal so I can't click on anything within VS)

Extra notes:

• it's an ASP .NET project.
• it works once I publish to Azure.
• after copying the project entirely and rebuilding, it seemed to work. then when mucking with NuGet dependencies, we're back to it not working (i've tried deleting my packages folder and having NuGet recreate - no luck; no idea if related to NuGet at all)
• I re-copied the project, so just 'MySolutionFolder' -> 'MySolutionFolder - Copy', reopened with same version of VS, runs fine. This is an amazingly sloppy solution obviously, so looking for something better.

As described in a comment, the issue presumably dealt with access rights to various files, most likely NuGet related but possibly Azure as well, which explains why copying to a new solution directory 'fixed' the issue. I would love to see better error info, such as "Error: Visual Studio couldn't write to 'packages.config'", so I know actually where to fix this sort of issue. As it stands now, it's like a compilation error that says "Syntax error in code. Somewhere. Good luck finding it".

Solution 1

Unfortunately, I never did discover a way to debug issues of this sort in a more general way. I eventually worked around the problem, and then saw it pop up again; following advice someone else tried on another forum, I deleted my packages folder, and had NuGet recreate it, which for whatever reason corrected the issue.

Another time, a solution from this question worked (remove and re-add all roles); sometimes this seemed to require an Azure SDK reinstall and computer restart as well.

EDIT

Finally, the best solution I could find was here: delete SUO files and restart VS.

Hopefully this solution will help someone with a similar problem in the future!

Solution 2

tick Debug > Exceptions > Common Language Runtime Exceptions > System > NullReferenceException and run your app

Solution 3

I've seen similar symptoms when something goes wrong very early in the asp.net app start-up cycle (before the debugger has attached).

One workaround I have used before:

1. Make sure you are debugging with a local IIS instance and not IIS Express (right click project properties -> Web -> Servers dropdown -> Local IIS
2. Hit F5 and get your error dialog. (Just to make sure the IIS process has started). Close the error dialog.
3. Debug -> Attach to Process -> attach to w3wp.exe (iis process). If it's not there make sure 'show processes from all users/sessions' are both checked.
4. Force a restart of your app by changing the web.config file.

The restart will now occur with the debugger attached to the process from the very start. If that doesn't give any more useful info, then look at turning off 'Just My Code' debugging exception/breakpoint handling and repeating.

Solution 4

You can enable Intellitrace and remote debug your azure services:

http://blogs.msdn.com/b/webdev/archive/2013/11/05/remote-debugging-a-window-azure-web-site-with-visual-studio-2013.aspx

Solution 5

For Visual Studio 2019, click on menu "Debug > Windows > Exception Settings".

Under Common Language Runtime Exceptions, tick on System.NullReferenceException. Debugger will break at the point where this exception is caught.

View more solutions

Comments

[Rollie]

Gave it a shot - that one was already selected (user handled box). I tried 'Thrown' as well, no dice. Tried selecting all 'Thrown' boxes, and nada.

[Rollie]

In this case, I'm more interested in what I can do to diagnose and fix the issue locally, than work around it by debugging in a different environment.

[Rollie]

I have done this, and had it working in various states - the problem I have been having (and making progress on) is related to VS throwing errors with no obvious avenue to figure out why the errors are being generated.

[matt_lethargic]

Event Viewer? Stack Trace?

[user626528]

@Rollie, are you sure your debugger is attached with a correct debugging engine? Check "Debug/Attach to Process" dialog.

[Rollie]

There is no stack as the application doesn't actually run. Nothing meaningful in event viewer - thanks for the idea tho!

[Rollie]

I'm actually running from Debug in VS, and as described this debugging process works fine after the solution is copied to a new directory. I likely found the issue (access rights), but the question here isn't "how do I make it run", it's "how do I debug this myself so I don't have to ask again". The answer I'm going for is "oh if you run VisualStudioInternalErrorViewer.exe in the install directory, you can see errors that occur with VS itself in more detail", or something of that sort