“Data Execution Prevention” kills (VS2008) local ASP.Net Development Server (aka Cassini) on Vista 64

Question

Occasionally, I find that while debugging an ASP.Net application (written in visual studio 2008, running on Vista 64-bit) the local ASP.Net development server (i.e. 'Cassini') stops responding.

A message often comes up telling me that "Data Execution Prevention (DEP)" has killed WebDev.WebServer.exe

The event logs simply tell me that "WebDev.WebServer.exe has stopped working"

I've heard that this 'problem' presents itself more often on Vista 64-bit because DEP is on by default. Hence, turning DEP off may 'solve' the problem.

But i'm wondering:

Is there a known bug/situation with Cassini that causes DEP to kill the process?

Alternatively, what is the practical danger of disabling Data Execution Prevention?

Answer 1

The only way to know for sure would be to dig through the Cassini source and see if there are any areas where it generates code on the heap and then executes it without clearing the NX flag.

However, instead of doing that, why not use IIS?

EDIT:

The danger of disabling DEP is that you open up security holes. DEP works by not allowing arbitrary generated code on the heap to be executed. This helps prevent malware programs from inserting code into the data segments of legit programs.

Answer 2

You are on vista, iis got better (7), cassini stayed crappy.

So just start this app on iis with a host header and a hosts file entry.

Answer 3

You can grant certain programs exclusion from DEP if you need.

As Jonathan

mentions this does open up any vulnerabilities that application may have.

Answer 4

Using IIS in Visual Studio isn't the pain in the ass that it used to be in 1.1/VS02/03 days. There are lots of good reasons to prefer IIS over the Cassini server (articles by Dominick Baier):

Cassini considered harmful
Another Reason why I would not recommend Cassini

Dominick is 'the man' when it comes to IIS and security stuff.

When using IIS for a web app, I always create the app in IIS first, point it at my preferred folder, then get VS to create the project. This means you don't end up cluttering c:\inetpub\wwwroot with your web apps.

Of course, now we have IISExpress which if you're targeting IIS7.x it's the obvious choice for developing ASP.NET applications in Visual Studio.

Answer 5

Thanks for the answers. I guess I developed such an aversion to IIS in the .net 1.x era that I've refused to consider re-using it -- until now.

aside: when choosing between two equally acceptable answers from ChanChan and Jonathan, I arbitrarily marked Jonathan's as 'accepted' because a) he got in first and b) his rep is currently lower.