Saturday, August 30, 2008

Cannot debug web based apps in Visual Studio (VS2008)

The company or product being named and shamed: Eset NOD32 AntiVirus.

Here's why: I was trying to debug a Silverlight application i had just whipped up, but i had an issue - i would press F5 in Visual Studio, IE (IE7 to be exact) would pop up, but i would just get a "Internet Explorer cannot display the webpage" message in IE, along with the usual list of suggestions to fix the problem. Upon checking the url in the address bar, i see it is pointing to the correct place:


so of course i initially think the problem was my fault and spend some time checking the code for errors, but of course there were none. So i loaded up a current web application that i am working on, hit F5, and the same thing happens. It has been about three weeks since i worked on that web application, and the only changes that have been made to this machine in that time are when i installed NOD32 and SP1 for Vista. As i had installed SP1 just a day ago, and because it is a major install (i.e. heaps of critical OS files get updated), i thought that it must have caused the issue. So i did what any self respecting geek does - i asked Google. It's not easy formulating a search query when you don't know exactly what the problem is, so i started with:

vista sp1 cannot debug web application

and after checking a few likely hits on the list i start noticing a recurring theme: Eset NOD32 was being blamed for the behaviour. The problem occurs because NOD32 adds an entry to your hosts file:

it's the entry at the bottom, the one that says "::1 localhost". I'm not sure exactly *why* it adds the entry, but obviously it's there to foil those badass pieces of malware that people get when they visit dodgy porn sites. But it also has the side effect of breaking the mapping between the loopback and the name "localhost", so when Cassini spins up and tries to serve my web or silverlight application it cannot resolve "localhost" back to the local machine.

Fixing this is easy - just remove the entry from the hosts file. And i have to say shame on you Eset, for not considering this behaviour, and for not checking for the presence of development tools in your install process.

To remove the entry:
- find your hosts file. This resides in %windows%\system32\drivers\etc, it is just called "hosts", with no suffix. This location is hidden, so you will have to make sure that both hidden and system files are visible.
- if you are running XP, you can just load the file into Notepad, remove the line, save it, then rerun your VS project.
- if you are running Vista, you have to jump through a few more hoops first. You need to take ownership of the file, to do this start a command prompt with administrative privileges:

either type Start-R, type cmd and then press Ctrl-Shift-Enter, and accept the UAC prompt
- or -
Start->All Programs->Accessories, right click on Command Prompt, choose Run As Administrator, and accept the UAC prompt

Then type the following commands:

take ownership of the file (so that you can change the ACLs on it)

c:\>takeown /f c:\windows\system32\drivers\etc\hosts

then you need to grant yourself full access rights to the file:

c:\>icacls c:\windows\system32\drivers\etc\hosts /grant [YourUserName]:f

then you can just load it into Notepad, remove the line, and save it. Of course it also wouldn't be a bad idea to revoke your access rights to the file once you have edited it, just to make sure it doesn't "accidentally" get modified without you realising it (modifying this file is an easy attack vector for malware). This is what the process looks like:

Those whited-out bits are just my username, you don't need to know what that is :) Interestingly enough, when i edit this file and save it, Windows Defender captures the change and prompts me to accept or revoke the change, but this never happened when i installed NOD32. I can't believe that Defender gets suspended while an application is installed (otherwise it would never detect that some malware just installed itself), so maybe NOD32 is doing something special during its install process.

Here are a couple of references that were helpful in diagnosing this problem:

Keywords: VS2008, Eset, Nod32, debugging, F5

No comments: