Unable to start debugging a Visual Studio 2012 project using local host on port 8280

Question

Two other developers can debug the asp.net website solution locally on their work stations without any issues.

However, one developer still cannot debug the solution locally on his workstation.

He is getting the following error shown in the image below. "Unable to start debugging on the web server. The server committed a protocol violation. Section=ResponseHeader Detail=CR must be followed by LF".

The website is configured to run on localhost, port 8280.

We used netstat to verify that nothing else was running on port 8280.

We've tried all of the solutions from Error : "Unable to start debugging on the web server..." ASP.NET 4.0 , and other forums.

We have ran out of ideas on what to try.

What else could be causing this error? What else can be done to resolve this error?

Answer 1

We found a "work around" to this issue. It doesn't solve it, but it does allow the developer on our team that's having this issue to be able to debug the project now.

https://stackoverflow.com/a/19787785/323696

Manually attaching the process (TOOLS -> Attach to process (ctrl + ALT +p)) to w3wp.exe for IIS, or IIsExpress.exe also worked, which leads me to suspect that VS is having trouble figuring out which process it should attach to automatically.

On the developer's computer, with other projects and solutions, when trying to debug, Visual Studio automatically attaches to the w3wp.exe process.

However, on the one solution/project that he's having issues with, and also only on his computer, he is having to manually attach to the w3wp.exe process every time he uses the Visual Studio debugger.

EDIT 08/12/2015:

The actual solution to the issue on the developer's computer was that in IIS, at the server-level, in the "HTTP Response Headers" properties, there was a duplicate entry for the "X-Powered-By" HTTP header.

Once that duplicate entry was removed, there were no further issues with starting the debugger in Visual Studio.

What led us to check the "HTTP Response Headers" properties was this SO post: https://stackoverflow.com/a/6124267/323696 .

It suggested to check that the "HTTP Keep Alives" were enabled, something that gets checked in the "HTTP Response Headers" properties in IIS, right-clicking on a HTTP header, then selecting "Set Common Headers...", then checking the "Enable HTTP keep-alive" option in the "Set Common HTTP Response Headers" dialog pop-up.

While the "Enable HTTP keep-alive" setting was already selected, and wasn't the root cause or our issue, following that lead to check that setting was what led us to find the root cause, the duplicate HTTP Response Header.

Problem Solved, but the symptoms didn't give any indication to what was causing the issue. While we lost a day of work to that issue, it feels good to to done with it and be able to move on now.