I'm quoting myself on a previous question I asked to further explain:
"I'm trying to run a freshly created ASP.NET Website using C#, however when I do so it launches FireFox and attempts to connect to http://localhost:1295/WebSite1/Default.aspx (for example), but after about 10-15 seconds it displays a "Connection Interrupted - The connection to the server was reset while the page was loading." Error.
This issue is also present with older ASP.NET C# pages/Web Services I've built in the past, nothing is actually running off the ASP.NET Development server."
This is the problem that was occuring, that is before I noticed every time I ran the website, the notification for the ASP.NET Server-startup showed one port (1130 for example), and when the website failed to load; it turns out it was attempting to load the site on another port (In this case, 1128). It was suggested that an anti-virus program could have caused this kind of redirection; low and behold uninstalling Nod32 fixed the problem!
So my question is: Has anyone found a way to create an exception or remove this functionality from Nod32?
Within Nod32 enter the Advanced Setup options, and turn off protocol filtering.
It's a known problem with NOD32. Looks like it's IMON module (protocol filter) accidentally does some modifications of TCP packets that go through it.
The solution is to either turn it off, or use a different software.
Related
Everything was working fine up to yesterday. VS2019. Net.Core 2.2 C#. Today I'm getting "This site cannot be reached" As far as I know I haven't changed any settings other than a routine Windows Update. I've read a fair few articles and nothing seems to work. Even a brand new web project with no changes has the same problem.
I get the same/similar no matter what browser I point at
I'm completely stuck. Does anyone have any ideas what it could be ?
Wierd!
To fix this all I did was connect to a local SQL database (on my machine) as opposed to a remote one (external server) and then delete all the cookies related to the localhost website.
It looks like some cookies get left laying around (from the external SQL) that affect IIS somehow, for any and all sites using SSL. Monitoring cookies I get around 7 created when I use the external SQL and only 3 when using the local.
Anyway, I just deleted all those cookies (localhost) because IIS still refused to work. I don't know why and I've just lost the entire day with this issue I may investigate another time but right now I need to crack on:(
It is not a specific problem because I have more than one experience that fiddler save my app.
A recent example:
I had an excel addin app write in C#. In the app I had a httpclient to connect to my server through ssl. And I ignored the certification in my code explicitly.
The app always worked well(I mean the connection part), but one day in a QA environment, it failed in no causes. The connection seemed to be blocked for long long time.
Coincidentally, we opened the Fiddler and tried to grab some http. Then everything worked fine.
(Fiddler may do something in the middle)
Then after closing Fiddler, we cannot recreate the problem because all things went back to fine again.
(Fiddler change something permanently!)
Here are some clues:
We use the normal C# http clients System.Net.Http .
Our server is ssl (https, but we must ignore the cert)
The app was good in the same environment at frist.
The lastest change is about the localization, and the test enviroment changed the windows local and language.
We are under a company network, using a proxy in the example above.
The failure is not the whole connection module, but a specific request.(In our case, a request that post two small xml files including excel itself)
Please give us some hint and guess, so we can feel better on this mystical problem.
How long is a "long long time" exactly?
Fiddler does not make any persistent changes to the system; if you start and stop it, the system is returned to the prior configuration. I suppose it's remotely possible that if some configuration setting were corrupt before Fiddler ran, that corruption wouldn't be replicated after Fiddler attempted to reapply it, but we don't know of any such "corrections."
This article describes some of the things folks find unexpected in terms of Fiddler "magically" fixing things while it runs.
I've inherited an ASP.NET web application written in C#. In many pages throughout the site the hostname is retrieved using:
BaseHost = Request.Url.Host;
Since I am using Visual Studio 2012 Express and it's installed local IIS Express server, I seem to be stuck with a port number appended to the hostname (localhost) when I debug/run locally. The above code does not result in the port number being included and as such breaks links that are generated by code (menu item links, redirects, etc).
I see that I can overcome the issue by changing the code to:
BaseHost = Request.Url.Authority;
This seems to fix it by including the port when I'm running locally (localhost:4652) and when published to my staging server (development.mysite.com).
My question: Is this bad form? Is there a time or a situation in which this is going to cause problems on my live site? It just seems a lot easier to do a quick replace of all these instances. I've considered writing a small routine to append : with Request.Url.Port, but it seems easier just to use Request.Url.Authority. Too easy maybe...
I've tried to research my question online and at MSDN, but I don't see an answer.
According to MSDN Authority includes the port number while Host does not. Another aspect is that Authority will escape reserved characters if need be.
Without knowing your application it is hard to say whether it is a good idea, but in general I would suspect that it won't break anything... so go ahead...
Another option is to run the application IIS instead of IIS Express...
My problem with this is that it ALWAYS adds the port, even when the port is not required. This can cause issues with multiple servers in some cases For example, in a production server environment behind a firewall on a pair of load-balanced web servers, it kept putting the firewall port in place, but that caused the URL to break because the port was tied to a specific web server in the server farm that wouldn't map correctly through the firewall. So I would be very careful with this method if you're using it across multiple servers. It caused a breaking issue with our application and had to be reverted back to using Url.Host. Plus, it made production web URL's look weird with the port number.
(Sorry if this is a really long question, it said to be specific)
The company I work for has a number of sites, which have been running for some time with no problems. The applications are a mix of ASP.NET 2.0, 3.5, and 4.0, all using an ADO.NET to connect to a SQL Server Standard instance (on the same webserver) all being hosted with IIS7.
The problem began when we moved to an upgraded webserver. We made every effort to set up the server, db instance and IIS with the exact same settings (except for the different machine name, and the fact that we had upgraded from SQLExpress to Standard), and as far as we could tell, we did. Both servers are running Windows Server 2008 R2 (all current updates applied), and received a default install.
The problem is very apparent when starting up one of these applications. When you reach the login page of our application, the page itself loads extremely fast. This is true even when you load the page from a new machine that could not possibly have the page cached, with IIS caching disabled. The problem is actually visible when you enter your login information and click the login button. Because of the (not great)design of our databases, the login process must access a number of databases, theoretically up to 150 separate DBs, but in practice usually 2. The problem occurs even when only 2 databases (the minimum) are opened. Not a great design, but we have to live with it for now.
When trying to initially open a connection to the database, the entire process stops for about 20 seconds every time, regardless of whether you are connecting to 2 dbs or 40. I have run a .NET profiler (jetbrains dottrace) against the process, and the only information I could take from it was that one or all of the calls to sqlconnection.open() was accounting for 90% of the time. This only happens on first-use of the application, but the problem is compounded by the fact that IIS seems to disregard the recycling settings we have set for it, and recycles the application after a few minutes of idle, causing the problem to occur again.
I also tried to use the SQL Server profiler to see which database operations were the cause of the slowdown, but because of all the other DB activity, (and the fact that I had to do this on our production server, because the problem doesnt occur in our test environments) I couldn't pin down the exact operation that was causing the stoppage. I will try coming in late at night and shutting down the production sites to run the SQL profiler, but I might not be able to do this right away.
In the course of researching the problem, I have tried a couple solutions
Thinking it might be a name resolution problem, I tried modifiying both the hosts file on the webserver as well as giving the connectionstrings an IP address instead of the servername to resolve, with no difference. I have heard of the LLMNR protocol causing problems like this, but I think trying to connect by IP or resolving with the hosts file should have eliminated that possibility, tho i admit I never tried actually turning off LLMNR.
I have increased the idle timeouts, recycling intervals etc in IIS, but this doesn't even seem to be respected, much less solving the problem. This leads me to believe there is a setting overriding the IIS application settings on the machine.
multiple other code fixes, none of which made any difference. Is a SqlServer setting causing the problem?
other stuff that i forgot by now.
Any ideas, experience or whatevers would be greatly appreciated in helping me solve this problem!
I would advise using a non-tcp connection if you are still running the SQL instance on the local machine. SQL Server supports several protocols, tcp, named pipes, and shared memory are the more common.
Named Pipes
Data Source=np:computer\instance
Shared Memory
Data Source=lpc:computer\instance
Personally I prefer the Shared Memory. Remember you need to enable these protocols, and to avoid configuration mistakes I suggest you disable all you are not using.
see http://msdn.microsoft.com/en-us/library/ms187892.aspx
IIS Reset
In IIS7 there are two ways to configure the idle-timeout. Both begin by clicking on the "Application Pools" section and right-clicking the appropriate app domain. If you click the "Recycling..." option there is one setting. The other is in "Advanced Settings..." under the section for "Process Model" you will find "Idle Time-out (minutes)" which set to zero disables the process timeout. This later option is the one that works for us.
If I were you I'd solve this problem first as restarting the appdomain and/or worker process is always painful even if you don't have a 20 second lag.
Some ideas:
from the web server, can you ping the db server and get a "normal"
response, or are you seeing a similar delay?
if you're seeing a delay, run a tracert to see if you can nail down where the slowness is occurring
try using a tool like QueryExpress (http://www.albahari.com/queryexpress.aspx) which doesn't require an install to run. You can download this EXE and run it from your web server. See if you can connect to your db using this and run queries in a normal fashion.
Try something like SysInternals' TcpView (http://technet.microsoft.com/en-us/sysinternals/bb897437) to take a look at your open connections and see what activity is happening on your server and how much data is being sent to and received from your db server.
Just some initial thoughts on where I'd start to look based upon your problem description. I hope this helps. Good luck with things!
With IIS not respecting recycling settings: did restarting IIS/rebooting change the behavior?
Whenever I debug my application (ASP.NET Web Application converted to Web Role), I am able to get to the login page. I go ahead and sign in, debug through that and it seems to work fine, but as soon as it takes me to the landing page after login, DevFC.exe stops working with the error:
An unhandled exception ('System.Net.Sockets.SocketException') occurred in DevFC.exe [8072].
Now, I've searched for the issue and have seen something about DevFC.exe crashing due to VMWare Workstation that listens on the same port (12000) and HTC Sync that also listens on that port. I have neither of those applications on my machine, so I am lost here. Using TCPView (from Sysinternals), I find no other application using that port.
The one thing I do notice is that [System Process] goes crazy creating connections to localhost:12000 once DevFC.exe gets started.
Anyone have some insight on this?
This might sound ridiculous but restarting your machine might solve the issue. If that doesn't work, try your project on a different machine. If the project works then there is an issue with your primary machine try uninstalling then reinstalling the Azure SDK. If the devFabric still crashes on the secondary machine then it's something related to your project.
You might want to take a look at the logs created in the DevFC folder here: %localappdata%\dftemp\DevFCLogs (C:\Users\[user]\AppData\Local\dftmp\DevFCLogs). This will hopefully shed light on the actual error (which in my case, was a conflict on port 12001. Ran netstat -ab afterwards and found it was vmware-hostd.exe. This is a service included with VMWare Workstation 8. I know you said you don't have that, but you may have some other conflicting software).
See this thread as well for more detail.
http://social.msdn.microsoft.com/Forums/en-US/windowsazuredevelopment/thread/7e205afd-4b9a-4387-8e10-99e4b8f27788