After deploying a new build (mostly changed DLL's) of an ASP.NET web app the CPU on the server is now jumping to 100% every few seconds and the culprit is lsass.exe. Do you think that the deployment of the asp.net web app to the server and this problem are related? (or a coincidence that it happened at the same time?)
More info:
This is the first time that I've done the build on a Server 2008 x64 machine. Previous the builds were done on a Server 2003 x86 machine. Target is "Any CPU" so should work on either. Deployed to server is Server 2003 x86.
I've searched the web for more info on this and have confirmed that the process is lsass.exe (first character a lower case L and not an upper case i) so ruled out the virus version. Found some docs relating to a Server 2000 bug but doesn't apply here.
I eventually isolated the problem to an ASP forum running "under" that ASP.NET web app. Using the admin page on the forum I took the forum down and then brought it back up again and the problem disappeared. I find this very frustrating because the problem has now gone but I don't know what caused it and as such it could easily return.
I also installed this Microsoft Hotfix and rebooted this server but that didn't work.
Have you checked the System and Application event logs for anything unusual?
Have you updated to use Active Directory role provider? I've seen issues where enumerating groups to do role checking pegs the CPU and really slows down the app. I actually implemented a customized provider that allowed me to specify a particular OU and set of groups that I actually care about to get around this issue.
The xperf tools distributed in the Windows Performance Toolkit will tell you exactly what is usin CPU time or disk bandwith. These tools are free and work on any retail build of WS2008 or Vista. Here is series of posts on the xperf tools from myself.
Related
I have a legacy Classic ASP web application that performs slowly on my current Windows 10 / SQL Server 2017 Dev machine as well as a Windows server 2016 machine.
In more detail, the ASP parts of the application construct and execute a lot of queries on the SQL server behind it. The queries seem to be taking about 5-10 seconds each to execute and some parts have more than 200 queries resulting in script timeout errors.
The interesting thing is that the same code ran on another Windows 10 Dev machine and performed just fine (the main difference is Windows defender being turned off on that machine), as well as on Windows server 2008.
I've tried disabling real time protection as well as Windows defender altogetger on my Dev machine with no luck.
Any ideas or hint as to what could be causing this?
Turns out the very undocumented (local) value for the database source was what was causing the delays. Changing (local) to the actual machine's name in your Classic ASP project's configuration will fix the issue. This is usually found in a some ASP configuration file within your project (e.g. config.asp).
I will edit this answer with several other topics that I found throughout my research which should apply to anyone having issues with Classic ASP projects.
What's also interesting and hasn't been answered yet is that two machines with (basically) the same stack were having different results.
This may be the dumbest question but I have a small problem I am using windows7 and recently I had an issue with my outlook as a result I had to recreate my profile on windows.
since that moment I can't see IIS7.5
I have also tried to use control pannel add windwos feature and I can only find IIS6
The strange thing about this is that I have files hosted in IIS7.5 and when I browse to the web Url(I use custom host) I can go there but creating a new website is impossible as I can't go to IIS 7.5
also browsing to Localhost gives me the indication that IIS7 is installed
What can I do?
I have tried also using the script from Microsoft site link but that wasn't successful and I am wondering what to do really.
also when I type Localhost on any browser I get the big image with IIS7 on it what suggest it is installed.
Just today using manage mycomputer(Win 7), service and application and restarted the IIS Admin service and now I can see the IIS7.5 as per the , but not sure why I can't see it in the accessories on when I do a search for IIS
Thanks
You could always download IIS 7.5 express from Microsoft
There is a similar post in super user forum discussing about the posted issue.
https://superuser.com/questions/752946/iis-manager-disappeared-from-start-menu-and-administrative-tools
Copied from there:
Your system is behaving in an abnormal manner, and it is hard to diagnose that error. It seems like it is caused by some system corruption.
The following tools can diagnose and fix errors in Windows :
sfc /scannow
Scans the integrity of all protected Windows 7 system files and replaces incorrect corrupted, changed/modified, or damaged versions with the correct versions if possible.
System Update Readiness Tool for Windows
Scans for Windows corruption errors that prevent Windows updates and service packs from installing.
Windows 7 Upgrade Advisor
Scans hardware, devices, and installed programs for known compatibility issues, giving guidance on how to resolve potential issues found, and recommends what to do.
Windows Update fixit or Reset Windows Update components
then try again to turn off the IIS Windows feature, reboot, reinstall, reboot.
Full antivirus scan by your current product and in addition at least Malwarebytes Anti-Malware.
If running these tools gives no hint as to the problem, the next step is a Repair Install to Fix Windows 7, which fixes the current installation of Windows while preserving user accounts, data, programs, and system drivers.
The last resort, to reinstall Windows from scratch, is not to be taken lightly unless really necessary.
We have an ASP.NET application running on a webfarm. When we release a new version and copy it to the production servers, occasionally it happens that after a few hours the application reverts to a an earlier code base.
Have anyone else experienced something like this? Would sharing an application pool between two applications running different versions of the code make this happen?
Additional information:
3 x web servers running w2k3/iis6
ASP.NET 3.5
I've had this happen rarely on non-precompiled sites and the solution was to stop IIS and clear out the temporary cache at:
%WINDIR%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files
Is not a long-term solution, but will address the immediate problem. If not already, it is worth considering deploying the site pre-compiled.
Working with one of our partners, we have developed now two separate sets of web services for their use. The first one was a simple "post to an https URL" style web service, which we facilitated by building a web page in ASP.NET that inspected the arguments in the URL, and then acted accordingly. This "web service" (if you can call it that) has been very stable.
At some point, the partner asked us to begin using SOAP based web services. At their request, we built them a new set of web services largely based on the previous objects, reimplemented as an actual "Web Service". This web service has not been very stable: around once a week, Nagios will alert us that our web service is not responding - and a quick iisreset does the trick.
Analyzing the log output and working in a debugger has not led us to anything concrete. The volume on this new web service is actually much lower than the HTTP web service. I think this could be a code problem or a platform problem, or of course something in between.
We've tried, with little improvement:
To duplicate the behavior in the lab
Debugging in the Visual Studio debugger
Tinkering with IIS options to give it its own application pool
My question, what are the next steps for troubleshooting?
Environment:
Windows Server 2003 Standard Edition R2 Service Pack 2 32 bit, Visual Studio 2005, MS SQL 2005, .NET Framework 2.0.50727
You may get some answers by profiling your webservices and understanding how they are using their resources. perfmon and procmon are both very useful tools in this regard.
EDIT: Since you say errors happen after about a week, the only thing I can think of is resource usage. Ensure your DB connections are being cleaned up, and any opened files (system call to the exe) are being closed.
Also, if your webservices can tolerate it, IIS has a setting that triggers a periodic recycle of an App Pool to handle cases where performance degrades over time. Its dirty, but it may work well for your case.
Since there isn't much to go on - here's another odd issue we came up against regarding our web services.
When the web service stops responding how is memory utilization? We have experienced issues with memory and memory fragmentation relating to busy web services on a system (there was also other things running causing additional fragmentation). When we re-factored the web services to load from smaller dll's and depend on other libraries (instead of one large library) we were able to resolve the memory fragmentation.
To identify what was occurring we would take a dump from the offending iis worker process where the app pool resided and then reviewed that using WinDbg.
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
Additionally we used DebugDiag to take the postmortem dumps.
http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1286
Hope this provides another direction to look at.
Occasionally, I find that while debugging an ASP.Net application (written in visual studio 2008, running on Vista 64-bit) the local ASP.Net development server (i.e. 'Cassini') stops responding.
A message often comes up telling me that "Data Execution Prevention (DEP)" has killed WebDev.WebServer.exe
The event logs simply tell me that "WebDev.WebServer.exe has stopped working"
I've heard that this 'problem' presents itself more often on Vista 64-bit because DEP is on by default. Hence, turning DEP off may 'solve' the problem.
But i'm wondering:
Is there a known bug/situation with Cassini that causes DEP to kill the process?
Alternatively, what is the practical danger of disabling Data Execution Prevention?
The only way to know for sure would be to dig through the Cassini source and see if there are any areas where it generates code on the heap and then executes it without clearing the NX flag.
However, instead of doing that, why not use IIS?
EDIT:
The danger of disabling DEP is that you open up security holes. DEP works by not allowing arbitrary generated code on the heap to be executed. This helps prevent malware programs from inserting code into the data segments of legit programs.
You are on vista, iis got better (7), cassini stayed crappy.
So just start this app on iis with a host header and a hosts file entry.
You can grant certain programs exclusion from DEP if you need.
As Jonathan
mentions this does open up any vulnerabilities that application may have.
Using IIS in Visual Studio isn't the pain in the ass that it used to be in 1.1/VS02/03 days. There are lots of good reasons to prefer IIS over the Cassini server (articles by Dominick Baier):
Cassini considered harmful
Another Reason why I would not recommend Cassini
Dominick is 'the man' when it comes to IIS and security stuff.
When using IIS for a web app, I always create the app in IIS first, point it at my preferred folder, then get VS to create the project. This means you don't end up cluttering c:\inetpub\wwwroot with your web apps.
Of course, now we have IISExpress which if you're targeting IIS7.x it's the obvious choice for developing ASP.NET applications in Visual Studio.
Thanks for the answers. I guess I developed such an aversion to IIS in the .net 1.x era that I've refused to consider re-using it -- until now.
aside: when choosing between two equally acceptable answers from ChanChan and Jonathan, I arbitrarily marked Jonathan's as 'accepted' because a) he got in first and b) his rep is currently lower.