I really need your help because I have a very unusual problem with my programs:
I get this error when I try to debug an ASP.NET or MVC application on the local IIS 7.5 server: "Cannot start debugging on the web server. The debug request could not be processed by the server due to invalid syntax."
I tried literally every solution that I could find on google until today. I spent 12 hours trying to figure it out. No luck.
The error occurs only with this address: http: // localhost / AspDemo is not with this: https: // localhost / AspDemo. Basically, I can debug, as always, if I set https instead of http.
https is disabled on my local IIS server :), I mean that it is ignored.
In addition, I can open my sites using the BOTH protocols in the IIS control panel
If I turn off the ASP.NET debugger in the properties of my application in Visual Studio, the application works fine.
This is an error from the httperr log:
2014-10-30 00:23:46 :: 1% 0 2977 :: 1% 0 80 - - - 400 - Verb -
I’m not sure where exactly, but in some other magazine I saw a link to something like this: Error 400 "Bad request - wrong verb"
A week ago, ALL the applications I came across worked fine with the asp.net debugger from visual studio, I had no idea what happened.
I suspect some update. Because updates recently messed up my own bootloader.
When I turn on tracing - the log is empty with http
Fiddler's log is also empty, maybe there is some configuration that I can use in Fiddler to create some more logs? (It certainly logs in with the machine.config parameter changed when I use https)
It would be eternally grateful for your help, if you need a few more magazines, please do not ask about it.
I would also like to mention that yes, I saw similar entries on this site, but none of them described a problem similar to mine.
/ change
From what I was able to observe, an error occurs before the debugger gets access to the machine.config file, can you guys tell me how to catch errors at this point?
==== / edit 2 ====
Is anyone No one knows the answer? I recently managed to find the full error message in: C: \ Users \\ AppData \ Local \ Temp \ Visual Studio Web Debugger.log
http://localhost/MVCDemo/debugattach.aspx Status code=400 (Bad Request) Protocol version=1.1 Cached=False Connection=close Content-Length=326 Content-Type=text/html; charset=us-ascii Date=Fri, 31 Oct 2014 03:44:14 GMT Server=Microsoft-HTTPAPI/2.0 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd"> <HTML><HEAD><TITLE>Bad Request</TITLE> <META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD> <BODY><h2>Bad Request - Invalid Verb</h2> <hr><p>HTTP Error 400. The request verb is invalid.</p> </BODY></HTML>
In the proccess monitor, I found this one too:
<event> <ProcessIndex>1339</ProcessIndex> <Time_of_Day>04:40:33,3661553</Time_of_Day> <Process_Name>devenv.exe</Process_Name> <PID>10768</PID> <Operation>CreateFile</Operation> <Path>C:\Users\<UserName>\AppData\Roaming\Microsoft\VisualStudio\12.0\Debugger\StepIntoFilterData.ini</Path> <Result>PATH NOT FOUND</Result> <Detail>Desired Access: Read Data/List Directory, Read Attributes, Synchronize, Disposition: Open, Options: Sequential Access, Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Delete, AllocationSize: n/a</Detail> </event>
I really need some help.
=== / edit 3 ===
The second error is not relevant, I just checked and is present with https (C: \ Users \\ AppData \ Roaming \ Microsoft \ VisualStudio \ 12.0 \ Debugger \ StepIntoFilterData.in) and debugging how https localhost works fine.
=== / edit 4 ===
Here are the process monitoring logs captured while running Visual Studio Debugging HTTP (not working) and HTTPS (working)
(The test runs in a random MVC tutorial)
Use CTRL + F and look for “Visual Studio Web Debugger.log” in the logs to get an idea of when this happens. In https, the log is good, in the HTTP log the incorrect Verb error mentioned earlier is returned.
I can be wrong, but I think the key here is that only HTTP does not work and only with VS Debugger, everything else is just fine (HTTP and HTTPS without debugging and HTTPS with debugging.)
(This happens with every solution in IIS, the new ones are also affected by all these solutions, and some of them have not even changed since they worked, the IIS configuration has not changed either)