I have a very strange problem I'm fighting with since VS 2015 (maybe even 2013).
Now I'm working with VS 2017 and it still occurs.
Here is the situation.
I have a legacy web application (Webforms, later enhanced by integrating webapi REST with javascript/html client code, some WCF endpoints, etc).
I build and start debug session from within VS (I do debug/testing mostly with Chrome and FF, rarely with IE/Edge/etc.), and I use IIS Express.
Most of the time the application debug session starts just fine - the page loads in browser and I can either debug server side in VS / client side in browser's debug tools.
But sometimes, the page actually never completes loading, and no matter how long I wait, it just stays locked on "loading..." message.
The only solutions I found are:
- either restart PC
- or (in Chrome), start browser in new identity.
- switch to a different browser (e.g. after starting with Chrome, open page in FF - or vice-versa).
When the page loads normally, the VS's Output Debug window displays various tracing / debug messages or progress of loading various dlls.
However, as soon as the problem described above starts to happen, the VS Output Debug starts to log msgs like
The thread <#nnnn> has exited with code 0 (0x0).
When this starts to happen, no matter what I do (except starting browser in new identity / change browser / restarting PC) I can no longer debug.
No matter if I totally close and restart the browser, clear cache, close and restart VS / IIS. Nothing helps.
The situation mentioned above occurs at very random intervals.
Sometimes I can work and debug for days (I suspend / hibernate the PC at the end of the day, resume next days, end everything works ok).
However other times the issue occur after just starting few debug sessions, and on occasions, even after a full shutdown / restart, at very first debug session, this happens.
I have lived with it for long time, but sometimes is very annoying.
Anyone have experienced a similar issue?
Any idea what is causing it, and is there is any fix / workaround?
Thank you
The messages in your output log reporting:
The thread <#nnnn> has exited with code 0 (0x0)
Just indicates that the thread has exited safely and is very normal to see this in correctly working code. In fact it would be abnormal to not see this as you will end up using all available threads.
From what you have explained I would suggest that you need to look at the extensions you have installed in your browsers. I typically will use a vanilla profile (blank profile with no modifications / extensions) so that my debugging is not affected by any modifications the extensions can make.
I would also monitor your system's CPU and memory usage. Are either of these being maxed out?
Related
I'm building a .net core react app. When starting the application in debug mode, I have no problems the first time I run, but if I stop debugging and attempt to run again, visual studio will stop debugging on its own as the web page is loading.
If I restart my computer, I can debug again, but if I stop and start, I experience the same issue. Restarting Visual Studio works occasionally, but it seems like I need to close out all instances of it, wait a few seconds, relaunch, wait for a few seconds after everything finishes loading, and then it will work (again, only once).
I'm assuming there's a process that isn't shutting down properly and is blocking the debugger from fully starting but I can't seem to find it. I am also running visual studio as Admin. Any help would be appreciated.
Ok so it's not a complete answer but I found what seems to be causing the issue. When the debug would fail, the URL briefly changed, showing that chrome was attempting to use the legacy browser support extension. After a bit of googling I learned that this could be caused by enabling "Javascript Debugging for ASP.NET" under Tools>Options>Debugging>General. Disabling this checkbox allows me to run debug without any issues.
Since I don't really care about the javascript debugging, this is a suitable enough answer for me, but if anyone else sees this and knows the answer that would keep javascript debugging enabled, please provide the details in case anyone needs it in the future.
I have a very odd problem with Chrome and FF browsers, when I'm using them while developing asp.net applications in VS 2013 / 2015, with IIS Express
Precisely, after few debug sessions (edit / run), the browsers no longer load the page (the site). The page keeps trying to load, the spin indicator is keep loading, if I monitor in VS in Output I see the app seems to work (I see regula messages, like
'iisexpress.exe' (CLR v4.0.30319: /LM/W3SVC/2/ROOT-1-131087453511178120): Loaded 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\vs\70993733\b377d6be\App_Web_tzrs4sq3.dll'
but the page never loads.
Even if I totally restart the browser and all its instances (from task manager), exit VS, kill IIS Express, nothing gets solved.
If for example this starts to happen in Chrome, and I try to load the same page in FF, it works. But after few more debug sessions (edit / run), FF starts behaving the same.
This happens erratically (sometimes I can debug a full day, tens of session, without problem), and sometime it happens just after 2-3 sessions.
Any other page (form internet) loaded in that browser still works just fine. Somehow it seems the browser cannot get back data from local IIS Express.
The only solution I found so far was to restart PC - after that, the debug session works, but also, till some moment.
I cannot tell if this happens in IE or Edge also, because it never happen to me with them, but I'm using them rarely (because I'm more accustomed with Chrome and FF's web developer tools - source, console, etc).
Did anyone encountered this behavior?
Any solution, or advice?
Correction:
Only Chrome still fails to load page even after restart and closing all instances in Task Manager.
FF (at least in latest version) seems to recover after a close / kill in Task Manager
Thank you
I'm just diving into Web API development (ASP.NET 4.6, Visual Studio 2015) and I have a strange problem. When running my web application with the startup option "Don't open a page. Wait for a request from an external application" selected, the initial request that is supposed to kick things off is very delayed.
For example, I start debugging and the VS output window is blank. I figure this is normal. Then in Fiddler I send the initial request. The time it takes for VS to start spitting out debug information and actually spinning up the application varies: sometimes it is instantly, most of the time it is about 10 seconds. Occasionally it will take up to 1 minute. During that time nothing is happening.
Edit:
Clarification: this is a delay before ANYTHING happens (i.e. before bootstrapping/spin-up occurs)
This mysterious delay also occurs when the project is configured to start with the default MVC home page. And it also happens when running without debugging. This happens with fresh project made from the template. Same goes for ASP.NET 5 template app. Also happens when I run in full IIS.
I wonder if it's a problem specific to my computer, as I tried all these things on another machine and there were never any delays.
I found out what was stalling out the HTTP request: my antivirus. I have AVG Internet Security Business Edition on my system. All that was required was to select "Temporarily Disable AVG Protection". Boom--right away, all my HTTP requests came through instantly.
Additional info: I tried disabling individual components from the AVG control panel, but none of those provided the fix. It seems, unfortunately, that it's all-or-nothing with AVG.
Conclusion:
At least on my system, completely disabling AVG (or presumably, uninstalling) AVG is required for ASP.NET development where waiting up to 1 minute for the first request to be processed is unacceptable.
Intermittently, my team's (overweight) VS2010 solution fails to load in the debugger. We get informed that "The web server did not respond in a timely manner".
Workarounds for when this happens:
Build, then debug (but not hitting F5 before building)
IIS Reset
Killing other apps, or closing extra open tabs in my other browser (debugging in IE, browsing stuff/keeping Gmail open in Opera)
Is there a registry key we could set that would make the response timeout longer, or similar?
I've found the hint of an answer here:
There are registry keys that control timeouts for VS's debugger. As these are generally not documented, it's a matter of trial and error from here.
So far I've been toying with HKCU\Software\Microsoft\VisualStudio\(version number)\Debugger\ScriptDocsTimeout
I have deployed an application written in ASP.NET 2.0 into production and it's experiencing some latency issues. Pages are taking about 4-5 seconds to load. GridView refreshing are taking around the same time to load.
The app runs fine on the develpment box. I did the following investigation on the server
Checked the available memory ... 80% used.
Cheched the processor ... 1%
Checked disk IO from perfmon, less than 15%
The server config is
Windows Server 2003 Sp2
Dual 2.0 GZH
2GB RAM
Running SQL Server 2005 and IIS only
Is there anything else I can troubleshoot? I also checked the event log for errors, it's clean.
EDITED ~ The only difference I just picked up is on the DEV box I am using IE7 and the clients are using IE6 - Could this be an issue?
UPDATE ~ I updated all clients to IE8 and noticed a 30% increase in the performance. I finally found out I left my debug=true in the web.config file. Setting that to flase got the app back to the stable performance... I still can't believe I did that.
First thing I would do is enable tracing. (see: https://web.archive.org/web/20210324184141/http://www.4guysfromrolla.com/webtech/081501-1.shtml)
then add tracing points to your page generation code to give you an idea of how long each part of the page build takes:
System.Diagnostics.Trace.Write(
"Starting Page init",
"TraceCheck");
//Init page
System.Diagnostics.Trace.Write(
"End Page init",
"TraceCheck");
System.Diagnostics.Trace.Write(
"Starting Data Fetch",
"TraceCheck");
//Get Data
System.Diagnostics.Trace.Write(
"End Data Fetch",
"TraceCheck");
etc
this way you can see exactly how long each stage is taking and then target that area.
Double check that you application is not running in debug mode. In your web.config file check that the debug attribute under system.web\compilation is set to false.
Besides making the application run slower and using more system memory you will also experience slow page loading since noting is cached when in debug mode.
Also check your page size. A developer friend of mine once loaded an entire table into viewstate. A 12 megabyte page will slip by when developing on your local machine, but becomes immediately noticeable in production.
Are you running against the same SQL Server as in your tests or a different one?
In order to find out where the time's coming from you could add some trace statements to your page load, and then load the page with tracing turned on. That might help point to the problem.
Also, what are the specs of your development box? The same?
Depending on the version of visual studio you have, Team Developer has a Performance Wizard you might want to investigate.
Also, if you use IE 8, it has a Profiler which will let you see how long the site takes to load in the browser itself. One of the first things to determine is whether the time is client side or server side.
If client side, start looking at what javascript you have and optimize / get rid of it.
If server side, you need to look at all of the performance counters (perfmon). For example, we had an app that crawled on the production servers due to a tremendous amount of JIT going on.
You also need to look at the communication between the web and database server. How long are queries taking? Are the boxes thrashing the disk drives? etc.