Cannot start debugger on Visual Studio 2010 (F5) H

Question

The environment:

• Clean (new) install of Windows 7 64bit.
• Clean (new) install of Visual Studio 2010 Professional (10.0.30319.1).
• Windows Update is up to date.

The problem:
I cannot start the debugger on Visual Studio 2010 (hit F5):
'Unable to start debugging on the web server. Unable to connect to the web server. Verify that the web server is running and that incomming HTTP requests are not blocked by a firewall.'

However, 'attach to process' (what I usually do) does work, but it is painfully slow to start (Visual Studio 'thinks' a lot of time before the debugging is actually enabled).

On the same hardware, running VS 2008 on good old Windows XP (32bits), this problem never happened.

Trying to debug a site running under the ASP.NET Development Server also fails:
'Unable to connect to ASP.NET Development Server.'.

There are plenty of web pages about these errors (many very outdated and does not apply to my environment), none of them worked for me.

Notes:

• No matter if I run Visual Studio as Administrator or not. The problem is the same.
• The problem happens even when running a brand new blank IIS web site, either created as 'localhost/something' or 'sample.local'.
• If I create a 'File System' web site (to try ASP.NET Development Server), when I hit F5, the server starts, but after a long wait Visual Studio says 'Unable to connect to ASP.NET Development Server.'
• The 'hosts' file has an explicit 127.0.0.1 entry for 'localhost' and for 'sample.local'
• It's the same problem either running .NET 2.0 or 4.0.
• It's the same either configuring the application pool with or without 'Enable 32-Bit Applications' true or false.
• It's the same either configuring the application pool is classic or integrated mode.
• In a desperate attempt, I've added all the IIS 6.0 legacy 'features' stuff (not needed!) and doesn't helped at all.

I don't now what else I can try.
Thanks.

Answer 1

OMG!, I'm so stupid. The most oblivious thing was truly wrong. There was a wrong rule in the firewall. Therefore, even being in 'interactive mode' (as it is was always set), the connection was denied.