I have a client with a server using IIS 7.5. They have an FTP service for their customers for use with their software package.
The server has been working flawlessly for years. Just over the last week the svchost.exe(ftpsvc) process is using 100% cpu. Until you reboot. Then it is good for a day or so and happens again.
The ftp site has anonymous connections disabled, and just basic passthrough authentication. When the server is at 100% I can remote into the server and see in IIS under FTP Current Sessions a few (10 maybe) of their customers hung in a RETR command. I am not sure if this is what is causing the issue or something else.
If anyone knows the best way to find the root cause of the problem I would appreciate any help you could give.
All windows updates have been installed.
Good afternoon Brian,
I experimented same behavior.
Can you check if you have KB4338818 installed?
It's seems to be the origin of this behavior.
I found this information here:
https://social.technet.microsoft.com/Forums/Lync/en-US/08662831-952f-4d86-b8e8-67874f117d98/july-2018-update-kb4338815-and-kb4338824-causes-issues-within-world-wide-web-publishing-service-on?forum=winserver8gen
After uninstall this update (KB4338818) the problem is gone.
Related
I've had an Azure VM running fine for years but all of a sudden I can't access it anymore. Not through RDP nor through http.
Nothing changed on my side and Microsoft only gives phone support for 230€/month. What to do?
Maybe it has corrupted? The only two things I can think of are: try connecting over Powershell to see if it will respond; You could pull it down from storage and launch the console locally to see what is going on? Azure as you may know doesn't offer a console access. The only other option is to rebuild it assuming you have backups etc.
Ok, finally put the money down and got it up again. The advice on the phone was to upgrade from A2 to A3 processor/memory specs. This would force the VM to go to another machine, ruling out problems with the hardware / NIC. This worked but was quite expensive. They will get back to me next week with the exact problem report.
I get this problem, when trying to connect to Windows Azure hosted server from my Mac OSX Filezilla FTP Client:
220 Microsoft FTP Service530 User cannot log in
Error: Critical errorError: Could not connect to server
This only started happening as of October 29, 2013. Prior to that, I would get a "Critical error" every now and again, but was always easy to refresh and upload without haste.
I tried CyberDuck and it told me to contact service provider, but has anyone found a solution to this?
We use Windows Azure to host our site, and I run Mac OSX. Surely, this would have always been a problem before and not have just sprung up recently for this reason alone (Windows vs Mac) right?!
Please see: Servicedashboard Windows Azure at http://www.windowsazure.com/nl-nl/support/service-dashboard/
30 Oct 2013 7:00 PM UTC
We are aware of an issue being reported regarding Windows Azure Web Sites FTP data access. We are responding to this issue with the highest level of priority. Further updates will be published to keep you apprised of the impact. We apologize for any inconvenience this causes our customers.
Last update:
We are narrowing in on the issue with full engineering engagement. Web Site customers are advised to publish content using Web Deploy or Git which are fully functional. For details on using these methods, visit Azure.com and search for "Websites with Webmatrix" or "Publishing with Git". We apologize for any inconvenience this causes our customers and will provide an update at 2pm UTC.
You can find more details on the issue and a possible workaround here http://social.msdn.microsoft.com/Forums/windowsazure/en-US/b2853874-160f-4156-bd0a-0247cac04831/cannot-connect-to-azure-websites-ftp-server?forum=windowsazurewebsitespreview
We are working with Visual Studio 2010 and Team Foundation Server 2010. We did not have any problems for about half a year, but:
Since a couple of days we get the following error: Team Foundation services are not available from server (...) The remote name could not be resolved; (...)
The problem occurs randomly (we are unable - yet - to pinpoint the conditions on which it occurs) and persists until we restart Visual Studio. The problem occurs about 8 times per day per developer.
Because we seem not to get past this problem and we cannot find anybody writing about this specific combination (the error and the 'remote name' part), I thought it wise to ask you guys about it ;) . Could anyone please help?
This is a client, server or infrastructure related problem on network level. The DNS entry for your TFS server cannot be resolved correctly at times for host dfz-vm223.
Suggestions for troubleshooting:
On some developer systems, replace the hostname dfz-vm223 by the ip-address of the TFS server. If the problem stop occuring there the DNS system is instable.
Setup a continuous ping stream (ping -t dfz-vmm223 from command window) and see if the host system is pingable in case you have TFS server problems.
Just found out what the problem was: the problem is proxy related. When we disable our proxy, the problem is gone. It appears our proxy and TFS are troublesome together. If anyone experiences the same problem and you are working with a proxy server, I would suggest you try disabling the proxy too.
I had the same problem, although I'm using VS2012 and a WAN connection to TFS.
I solved the problem by flushing the DNS cache.
To flush the DNS cache, start a command prompt with admin rights: ipconfig /flushdns
You need to do this in all the computers where the problem occurs.
I know this is old, but I had this problem sometimes when I ran Fiddler.
Sometimes Fiddler would crash or not clean up properly and the whole machine would get into some weird state where not even reboots were helping. The solution to it usually is to start Fiddler again, turn off any interceptors/collecting traffic and shut it down again.
Some of my co-workers and I had this problem as well. Out of about 25 developers, most never got this error. But three of us got it pretty consistently. The symptoms are identical, but we are using Visual Studio 2013 almost exclusively. In this version of Visual Studio, the error is preceded by the code: TF400324.
We found eventually that the three of us had all installed Productivity Power Tools 2013. And the developers that were not affected by this error had not installed it. Most had not heard of it. This used to be a very popular extension, so I have always installed it as I set up my system since about 2007. But apparently, in its modern incarnation in Visual Studio 2013, perhaps in combination with some quirk in our network or something, it can cause this problem. We have each uninstalled it, and have not gotten this error since. (It's been several months now.)
If you have this extension installed, you probably already know about it, because you probably installed it yourself. You probably started using it years ago, and it became a habit to add to each new installation. You will find that today, the default installation of Visual Studio actually includes most of its features already. To uninstall, go to Tools --> Extensions and Updates... Then click on Productivity Power Tools 2013, and click Uninstall.
Hade the same issue. For whatever reason the windows DNS Client service on my PC wasn't running. Changing it from Disabled to Automatic solved this problem for me.
Too long for comments:
First off, as #kroonwijk stated, this is an infrastructure issue. Your DNS queries are either timing out or the DNS server is not responding at certain times.
In a comment you mentioned a change over from regular machines to laptops for your entire dev team. If I had to make a bet I'd say that the DNS configuration on the laptops is not the same as what you had on the other machines.
You need to take this up with your infrastructure people. If you still have access to the older machines boot one of them up and compare the IP configuration. If not, get them to fix the problem. The DNS resolution problem could be any one of a number of factors. For example, the new machines could be pointing to an incorrect DNS server that has network issues or their might be some incompatibility between how Win7 makes DNS requests and your DNS server.
I have also experienced this problem and it doesn't always have to do with name resolution.
If you add an entry to your %systemroot%/system32/drivers/etc/hosts file for your TFS server, it removes any dependance on your name resolution servers.
If you are still experiencing the problem, then it has to do with either visual studio or one of the VS Extensions that you are running. There may be a memory leak somewhere. Disable all your Extensions using the extension manager, restart VS, and see if you still experience the problem.
I've set up a Mercurial server on a Windows 2003 / IIS 6 machine and when I try to pull the repository I get the following sequence
requesting all changes
adding changesets
adding manifests
adding file changes
transaction abort!
rollback completed
abort: premature EOF reading chunk (got 91303 bytes, expected 1542634)
I've tried pretty much everything I can think of, but with no success. I followed the steps of Jeremy Skinners guide on doing it for IIS7, but on an IIS6 server.
I found a post where the author was experiencing the same issue, but was unable to find a solution.
So far it looks like the solution is to migrate to Apache or upgrade to Windows 2008/II7 .. but if someone knows how to solve this, please let me know
I'll answer this one myself.
The problem turned out to be that there is a CGI script timeout of 5 minutes in IIS 6 (and below, not sure about 7) and this was what kept being hit. To change the timeout value you have to have the IIS 6 Resource Kit installed.
Once installed, start the MetaBase Explorer utility and navigate to \LM\W3SVC and locate the CGITimeout entry and change the value from the default 300 (5 minutes) to a higher value (I ended up using 20 minutes).
After changing the value I restarted IIS to make sure it was used by the server. Once this has been done, everything worked like a charm!
Cross posted on my blog
I haven't tried it yet, but there's this: Running Mercurial on Windows
If you scroll down to the "Windows Server 2003/XP" section, I think that should cover you for IIS 6.
Have you checked out Joel's tutorial? Maybe you'll find the answer there.
We run an old Windows NT Machine, fully patched running IIS4.0.
Today we were hit by "linuXploit_crew", and they took down our websites for a minute or two. (luckily we were quick to notice a change on the websites and fix it within minutes of the attack).
However -- After fixing the website, I'm left with trying to figure out HOW this happened.
Looking in our FTP Logs, there's no changes in our default.asp files, and I see nothing out of the ordinary for Web Logs. Any ideas on how to pinpoint how they got in? We've only got 3 ports open, FTP, HTTP, and HTTPS (21,80,443) on a Cisco Firewall.
NT/IIS4 no longer get security updates. Any new exploits will remain unpatched. Time to upgrade.
Once you've been "owned" enough to change your site, you can't necessarily trust your logs anymore- they could have been "cleaned" by the attacker.
IIS 7 + .NET 3.5 SP1 should be a nice upgrade :)
They appear to be using some form of Injection Attack: See http://msdn.microsoft.com/en-us/library/bb355989.aspx?ppud=4
A wide array of attacks are possible through just port 80. What applications are you running on the server? The number of asp- and php security holes is a magnitude higher than the number of OS/server application holes.
Stay away with Windows NT class systems. IIS 7 might be okay for security, but the price is not up to standard. USE BSD instead or Linux with Apache. Centos if Linux and OpenBSD if BSD my suggestions.