Skip to main content

ASP.NET MVC and WebAPI – “The parameters dictionary contains a null entry for parameter”

WWW Logo

When working in ASP.NET MVC and WebAPI you may run across this exception.  Consider the following controller action:

public void SomeAction(int id)

And a simple AngularJS ajax call to the method:

var someAction= function (id) {
var d = $q.defer();
$'api/SomeController/SomeAction', id)
.success(function (data) {
.error(function (data) {
return d.promise;

The ajax call can be from any client-side framework, AngularJS, jQuery, etc.  What’s important is the routing to the MVC controller action and, more specifically, how WebAPI performs the parameter binding.

By default, for value types (int, bool, string, etc) WebAPI will try and get a parameter value for a simple type from the URL.  This obviously creates an issue in this case since we are using a POST request; the parameter value will be in the body of the HTTP request and not in the URL.

In order to resolve this issue the parameter in the controller action must be decorated with the [FromBody] attribute indicating that WebAPI should look in the HTTP request body when performing the parameter binding.
The controller action would then look like this:

public void SomeAction([FromBody] int id)

Now the parameter binding works and the parameter value is sent to the action method just fine.

Mike Wasson has an excellent article with a lot more details here:

IIS – “The page cannot be displayed because an internal server error has occurred.”

WWW Logo

I recently ran across this common error when migrating an IIS7.5 web site to IIS8.5.


This error occurred regardless of what I was trying to access; the server responded with it for all requests. For this particular site I had exported the site and app pool configuration from the old server and imported it into the new server using appcmd.  Everything seemed to be fine with the application cofigurations.

It didn’t matter if it was static content or a request to an application.  Also, I had detailed error messages enabled to see what the problem was but nothing I tried returned a detailed error, only this generic error.  It seems to me now that a site level configuration error will prohibit detailed error messages from being returned to the client.  I got lucky when trying to look at different configuration elements from within IIS manager.  I got lucky when clicking on one of the configuration items.  I happened to try and open the MIME Types element on the site level and received an error message stating that there was a duplicate MIME type for MP4 files:


IIS7.5 does not include a mapping for MP4 out of the box so on the old server I had to add it manually:


IIS8.5 now includes this type, which is a good thing since it’s obviously a popular format.  I opened the web.config file of the site on the IIS8.5 server and saw the mapping:


I then removed the entire <staticContent> section that is highlighted and the site started behaving properly.  My site has a fairly simple configuration so if you have more than just the one MIME type in your <staticContent> section then you obviously don’t want to remove the whole section, but rather just the duplicate mapping.