Here are a couple of easy ways to have insight to route debugging your MVC applications. If you begin to build up your route tables with lots of different options, possibly including complex regular expressions, you might get undesired results based on incorrectly intended matching. Remember routing works in a top down matching methodology, so if a URL matches an earlier route then intended the incorrect view might be returned (if anything at all).
The easiest way in my opinion is to use the Route Debugger utility (thanks to Phil Haack) that can be installed from NuGet. This process takes all of 2 minutes, so check it out. Use the following command from the Package Manager Console to install:
The configuration for enabling and disabling is in the web.config <appSettings> section:
<add key="RouteDebugger:Enabled" value="true"></add>
As you can see the output shows the matched route at the bottom of each page:
Another technique for debugging routes not found via the result of a HTTP 404 is to use Fiddler. Open it up, but remember to place a dot '.' after the word 'localhost' if using the local IDE to spin up your web application (I have a post about this here: Using Fiddler With VS.NET And The Local Web Development Environment 'Cassini'). After refreshing the page, click on the the 404 entry in Fiddler, and then press the 'TextView' button on the response. Scroll to the bottom, and take a look; you get a much more meaningful response message to view.
Lastly, Glimpse is another route debugging tool but last I checked they are still working on support to port over the MVC3 version to MVC4. If you are still using MVC3, check out Glimpse on NuGet as well.