I've got an admin .aspx page that I need to run on an instance to iterate through a bunch of items and fix some Worflow fields that aren't set properly. It's got to get through a lot of items. I ran it on my dev machine and it worked fine. It took a really long time, but completed.
Now, I'm trying to run the same page in the client's environment and I keep getting an HttpException: Request timed out error.
I just need to run this thing once. Any thoughts on why it won't run there and how to make it so I can get it to complete?
In .NET There is a executionTimeout. This time-out applies only if the debug attribute in the compilation element is False. This can explain the different behavior on your dev vs production
msdn
An other option is the app pool recycle setting.
Try the following:
Open IIS, and Select "Advanced Settings" for your Application Pool
Set the Ping Maximum Response Time to a larger number, note its in seconds
Reset those values back to the original value, once the task is done
Hope This helps
Related
It stops responding after a few seconds of being idle. I have to restart it every time this happens.
I have tried putting startMode="AlwaysRunning" into my applicationHost config, but nothing changed.
The output of the console is just a bunch of
The thread X has exited with code 0 (0x0).
I don't think this is related to idleTimeOut either, because the website completely stops responding; it just hangs.
applicationHost if anyone is interested (too large to post here):
http://pastebin.com/quVMXPHP
Let me know if you need further information.
Are you sure it's from being idle? By default, every time you stop debugging, IIS Express unloads the website, and quits entirely if there's no other websites running. You can disable this by unchecking Enable Edit and Continue in the project properties under the "Web" tab.
If it happens more randomly, then IIS Express may actually be crashing. Check in the notification area of the taskbar for IIS Express, make sure it's there, and (by right-clicking) ensure your web project is still loaded (in the list). If it's actually crashing, you most likely have a memory leak, infinite loop, or something similar going on somewhere in your application that's overloading the process. There's no much we can do to help you with that, without being able to examine your entire codebase. You'll just have to trace and profile until you find it.
It may be a silly question but why one would like to attach debugger to IIS instance?
These SOs
Attach Debugger to IIS instance
How do I attach the debugger to IIS instead of ASP.NET Development Server?
show you how to do it but could you let me know what are the benefits of doing this?
One time, in my entire career, we had a web app that started getting strange errors that had us baffled. We tried a dozen things to try and figure out what was wrong, but we were panicking and needed an answer immediately. So, we attached a debugger to the production instance and set up a few watch/break points. It helped us track down the errors and fix the problem.
Naturally, it hung the server during our debugging session, and made people mad, but no more mad than they already were, because of the problem we had.
It would not have been necessary if the code had been written better, with error logging and diagnostic points. I don't expect to ever do it again.
Apart from TimG's post a couple of reasons I can think of are:
To debug the application in a closer representation of its
production environment
To debug on a remote machine
Example, like #TonE #1 -- in order to test a deployed website (with web.config transformations) locally, like if you can't remote debug a live website or just need to test config transforms (since you can't run them in-place):
Open site project from C:\Dev\AwesomeWebSite\AwesomeWebSite.sln
Publish the site to a local folder C:\Webs in Release mode (or Whatever mode)
Set up a local IIS website pointing at the published project
Do stuff on the locally-deployed version (e.g. browse pages, make webservice calls, etc)
Attach VS to w3p.exe (appropriate instance) in order to debug the deployed version
You might be able to effectively do the same thing by instead pointing the Project at your IIS website per this answer.
Can anyone help me with this error?
alt text http://abbeylegal.com/downloads/parsererror.jpg
full image here
It happens usually once a day when trying to load any one of a number of custom asp.net pages in my sharepoint web site. If I recycle my application pool the error disappears (usually for the day).
So far this is what I’ve tried to eliminate the error (which has helped reduce the number of occurrences, but not solved it)
Set the IIS_WPG, Local Service and Network Service account to Full Control permission
on the folder
%windir%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files
Added
<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="3DES" decryption="3DES"/>
to the web.config file section.
Recycle the application pool every two hours
My gut feeling is some sort of file locking issue. Have you tried running Process Monitor and having a look at the trace when this error occurs? Be warned that running it may sap some resources on your server.
To use, follow these steps. (You may also find Mark Russinovich's blog useful.)
Set the filter so that it only displays the w3wp.exe process. This will reduce noise. The simplest way is to right-click on 'w3wp.exe' in the list and select Include 'w3wp.exe'.
The monitor should have automatically started so now just wait until you receive the ASP.NET error. Make a note of the time the error occurs! It may also be reported in the SharePoint ULS log.
Stop Process Monitor from capturing events (File, Capture Events) and narrow down to the time of the error.
Look for the word 'FAIL' or 'ERROR' (you can use the program's find feature) and see if you can work out what's happening. You may need to remove the filter as the problem might have occurred with another process besides w3wp.exe.
There may also be interference with an anti-virus program as I've seen these lock files and cause problems on SharePoint before. Can you try disabling it to check if the error disappears? Alternatively, here are details of locations that need to be excluded so that SharePoint can operate correctly with a file-level virus scanner. You may need to add others, I don't believe that list is comprehensive.
I can see why the app pool recycle works, the dll's get recopied to the Temporary ASP.NET files folder.
The question here is, why are they not there anymore? It could be that the files were locked when the app pool recycled overnight, the files were not overwritten with a new version and remain in a locked state. Maybe search crawl was running when the app pool tried to recycle, visiting that page at the time?
P.S. Is your custom page build as part of a "Visual Studio Web Site" or a "Visual Studio Web Site Project"?
This may seem like a silly question, but we are having an issue debugging IIS in a shared test environment and I'm hoping that someone out there can give us an answer.
We have a Windows Server 2003 that is running IIS 6 and sharepoint 2007. We are debugging locally on the server with visual studio 2008.
When someone attaches the debugger and steps through the code, we find that all users are affected. In essence the web server stops handling all requests from all users.
Our question is whether this is a typical situation and is to be expected? Or is there some configuration that we can change that would allow the one user's session to be debugged but leave the other's unaffected.
Kev's on the right track. You need to make sure that the project you want to debug separate from the others is in its own application pool. This will isolate it to its own process and allow that process to be stopped/debugged without affecting the other applications which can remain in a different pool.
Setup
Start -> Run -> inetmgr
Right Click on Application Pools
Click New -> Application Pool
Name the new pool
Right Click on the application you want to isolate
Click Properties
Click on the Home Directory tab
In the application pool drop-down list select your new pool
Click OK
If there are any requests queued in the old process, they may take a few minutes to terminate before all requests are being diverted to the new process.
Debugging
To figure out which instance of w3wp.exe you need to attach the debugger to:
Start -> Run -> cmd
Type iisapp
You may be prompted to register CScript, if so click yes and run it again
The only gotcha you may still find is that if multiple applications are using the aspnet_state service you may run into blocking issues if you need to debug that process as well.
Links
MSDN
Developer.com
"When someone attaches the debugger
and steps through the code, we find
that all users are affected. In
essence the web server stops handling
all requests from all users."
This is normal, once you attach a debugger to a process such as inetinfo.exe or w3wp.exe and set a break point, every request/thread will be blocked until you allow the debugger to continue, until the next break-point.
I've never found a way around it. Is there some reason you can't debug on each developer's workstation?
Set up a parallel project on the server and try using that. You could use debug.mydomain.com and then just use that for testing. The only reason that I personally can think of to debug on your live servers is if there is a significant difference in the functioning of your app due to either hardware or software configuration.
Ideally you want to have a separate server/instance of your system in as similar an environment as possible so that you don't have to debug on your live machine. Also you might want to consider writing all errors to the event log or at least checking the log since asp.net usually get logged there. This way you can see where your errors are and use that to help you solve your problem in the development environment.
I believe in visual studio you can set the debugger to break only the process being debugged, and not all the processes. Depending on how your system is set up, YMMV with this.
It can't be changed AFAIK. But that's a normal practice to set up separate web-node or web-application for development/debugging purposes. If that's necessary to know exact values of some vars in certain situations you can always use debug logging.
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.