I have a web app running in a local instance of IIS 7.5. My app pool has it Maximum Worker PROCESSES at 3. When I go to Vs2008 and attach my debugger to my local IIS I see three w3wp.exe processes as expected. I attach to all three. When I run a web page my breakpoint hits in my code behind, as expected.
Here's the problem: in my code behind my C# code is calling a service on another computer that in turn sends a request back to my local IIS box. This is all synchronous. The problem is that while I'm in the debugger it seems like that remote code's call to my IIS box is immediately failing. If I go on to that remote box while I'm debugging and try to pull up any URL from my local box it hangs. And, as soon as I hit F5 in VS2008 the browser frees up and fulfills the request.
So why does the VS2008 debugger cause IIS to not use any of the other worker processes to service other incomming requests?
Thanks for any ideas.
While you debugging any process - all the threads hangs.
So what you're describing is expected behavior. You're debugging a thread in IIS, the whole process hangs until you press F5 and return the control to the process.
Related
I've notice that on the production server, my asp.net 4.7.2 application is very slow. By debugging I've found that in global.asax the Application_start and Application_end is called on every request, causing a recompile of the application each time and slowing down the response.
I0ve test it on several servers and the behaviour is always the same.
Running the website on localhost in IIS (not iis express) this not happen.
How can I check why Application_End is called and from where?
Debugging in VS the Application_end stacktrace is empty, I cannot see from where is called.
Thanks
The problem was cause by Kaspersky Endpoint Security for Windows Server version 11.0.0.480.
For some unknown reason it act on w3wp.exe causing the application restart on each requests. The only way to solve the problem is excluding w3wp.exe from the monitored applications/processes.
There are many circumstances when the Application_end will be called, such as application pool's recycle, web.config file's change, or bin file's change. For more detailed information about Application_end be called you need to check the Event log in the sever.
We have an asp.net web application that works fine in our environment. One of our partners tries to the exact same code in their environment and can only process one request at a time. For example, there is only page that calls a long running stored procedure (5 minutes). If you call that page and the try to open a new page, the new page won't serve until after the first page has completed. We can see the request back up by looking at the worker processes for their application pool. They are running IIS 8.5 on a windows 2012 server. They're also running SQL Server 2016.
The database connection is structured the same as as in our environment. The stored procedure is not wrapped in a transaction. Any ideas what might be causing this behavior?
IIS also can work in the Debug mode, when it is enabled, Asp is limited to processing one request at a time in a single-threaded manner.
Open “InetMgr” or IIS manager, double click ASP under the IIS section of the website. Check the below settings in Asp section.
See the below discussion for more information.
IIS7 - only serves up one page at a time. It's a making me crAzY!
I just started using SignalR (latest 2.0.3) on project running latest IIS and Visual Studio 2013.
I noticed an issue where sometimes the web page just hangs trying to load for an abnormal amount of time (never actually loads).
When this happens, I go into Visual Studio and hit the square to stop debugging, and visual studio starts to hang (not that it freezes VS but just loading symbol trying to stop debugging never actually stops debugging)
I realized the solution is to stop IIS which immediately causes the page to load and visual studio to respond and stop debugging. Start IIS and it's back to normal but this has occured multiple times already.
When this happens, try checking the current requests in IIS (go to Worker Processes in the IIS server features view and double-click the App Pool of your website) and I suspect you'll find 10 of them in process. This can happen because IIS on Win7/Win8 is limited to 10 concurrent requests and depending on your app, signalR could be using all of them up. and once all of those requests are used up, new requests will hang.
You can also kill them requests by recycling the App Pool.
At our shop, we develop on Windows Server 2008 VMs running IIS 7, same as our production web servers. With VS2010 (and VS2008, but more so 2010), I've been having issues with debugging our ASP.NET applications. If the application throws an exception, I'll often kill the debugger (Shift-F5) so I can correct the faulty code. But after doing this, the process in IIS continues running, with the exception!
This leads to numerous faulty scenarios. Sometimes the exception floats to the top at IIS, and I get a prompt asking "Would you like to debug this process in [choice of Visual Studios]" and other times there is no prompt but the debugger reattaches to the faulty process instead of starting a new one the next time I go to debug.
What am I doing wrong here? Or what is configured wrong? I want the workflow I had back: run web site, see exception, fix code, run web site again to verify fix. Instead I have to manually kill W3WP in the task manager in order to continue working.
Extra info: It may also be related to the fact that the solution contains both a web site application and a web service application which the site application accesses, both running on the local IIS in two virtual directories. Normally the attached debugger will drop into either the web site or service, if either has a problem.
I wonder if there's something else going on that is being hidden. Can you setup Visual Studio to break on all exceptions. From with in the IDE press CTRL + ALT + E. That will open the Exceptions dialog.
By default, the IDE will only break on user-unhandled exceptions. If a different exception is being thrown you might not know about it. Add checks to each checkbox in the "Thrown" column and try running through your code another time. If another exception is being generated, Visual Studio will break on it now.
I develop and debug an ASP.NET application with VS 2010. My ASP.NET application holds some connections to other applications on other machines. When I stop debugging, I want these connections to be released. If this doesn't happen, these other applications fail and I have to restart them.
In the end I will store my termination code in the Application_End method in Global.asax.cs, but this one is not called when stopping debugging.
Is there a way to terminate the debugging of my ASP.NET application so that not everything is killed at once, but so that one last method is called in which I could add my termination code?
I'm not sure what your problem is but probably...
You initialize your debug session by pressing F5 and thus debugging through cassini. This way when you end your debug session the application is terminated.
If you have a configured IIS application you could simply attach to the running process - it's usually "CTRL + ALT + P" - choosing w3wp.exe (mind the checkboxes on the bottom to be checked). This way your app won't be terminated on ending the debugging session.
Does it solve your problem?
I misunderstood how debugging an ASP.NET application works. I thought the moment I stop debugging (by pressing Shift+F5) the ASP.NET application is terminated and no further line of code is executed. It was my explanation to why the Application_End method is not called.
But in fact the ASP.NET application goes on when the debugger is detached and therefore the Application_End method is not called.