Ok so I have been keeping up with decompressing application pools and adding Pre Conditions to the applicationhost.config file. I am now stumped on server 2012.
Symptom:
Application Pool keeps crashing, even log error kicks off 4 listener channel errors and then kills the the app pool.
Previous Fix for older version servers:
Backup IIS. I add Pre Condtions to exppw and (and in this case)cafe_exppw. Additionally I add it to Kerbauth (In some cases the Pre Condtion was not needed.) Save. ResetIIS. I then run Anilr's script (ref:http://forums.iis.net/t/1149768.aspx) below which does not work. I am no programmer so I am not sure where to find an update version (if there is one) for 2012
%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/httpCompression /+[name='xpress',doStaticCompression='false',dll='%windir%\system32\inetsrv\suscomp.dll']
Thanks,
Jack
Often a problem with the 64 bit rpcproxy.dll which is loaded by iis by default even when "enable 32 bit applications" is set to true.
Here's a link that explains
http://blogs.technet.com/b/sbs/archive/2011/04/07/how-to-run-a-32bit-web-application-on-sbs-2008.aspx
Could be the source of your problem
Wing
For anyone who might be wondering how I got around this, just add "bitness64" /> to kerbauth and anything exppw in GlobalModules in the web.config file. Reboot IIS, verify OWA still works and that should do it. You might see some kerbauth errors but I am yet to see any real issue stem from it.
For your information there is no need to decompress the app pool:
%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/httpCompression /-[name='xpress']
Related
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.
I'm supporting a ASP.NET v2.0 app installed on a Windows 2003 SP3 Enterprise on a quad core 8G machine running on .NET 2.0 SP1.
before enabling the config, ran "tasklist /m mscorwks.dll"
Image Name PID Modules
w3wp.exe 7888 mscorwks.dll
add under section in web.config
ran IISRESET, rebooted server too
ran "tasklist /m mscorsvr.dll"
INFO: No tasks are running which match the specified criteria.
ran "tasklist /m mscorwks.dll"
Image Name PID Modules
w3wp.exe 6251 mscorwks.dll
It seems like gcServer is not taking effect. Are there any additional settings/ configurations necessary to get it working?
Update: Sorry, just saw that the link below, and thus maybe the whole information, applies to IIS 6.0. I don't know whether that is applicable to your environment.
I don't believe you can configure any GC setting on a per AppDomain basis, which is essentially what would happen when you only set it in a web.config file, thus on a per application basis.
You need to set this in the aspnet.config file. The Aspnet.config file is in the same directory as the Aspnet_isapi.dll file (check this for more information).
Edit: To figure out the GC in use, you can use WinDBG/SOS and the eeversion command:
0:010> !eeversion
2.0.50727.3082 retail
Workstation mode
SOS Version: 2.0.50727.3053 retail build
See this MSDN link, where Chapter 5 had the answer. Quote from Chapter 5:
Note: At the time of this writing, the .NET Framework 2.0 (code-named "Whidbey") includes both GCs inside Mscorwks.dll, and Mscorsvr.dll no longer exists.
I guess there is no way to check whether the server GC is working. EDIT: but see Christian's answer.
From code you can use GCSettings.IsServerGC.
Are there any particular settings one should optimally enable/disable/tweak when doing ASP.Net MVC development on local test machine Windows 7 using IIS 7.5 and moving in and out the debugger & recompiling refrequnetly (integration/troubleshooting stage now before TDD fantactics throw stones - although admittedly I could have more under test), I work with 64 bit edition but figure this probably applicable at both x86/x64?
I'll start with one:
Ping Period (seconds) - increase from 90 to 3000 (or something somewhat higher) so you can if unfortunately need to a good bit of time whilst debugging or disable ping on local test machine.
Credit: http://blogs.msdn.com/johan/archive/2007/09/12/my-web-application-times-out-when-debugging-in-iis7.aspx
However I see over stuff such as:
Disable Overlapped Recycle & Recycling settings etc.. that I wonder if could increase performance or make debugging less friction
Question prompted by the annoyance that I've ran across a few recent debugging issues (not apparent in production) including a random, and tempormental error "An assembly with the same simple name blah-blah-lah-assembly-definiton has already been imported . Try removing one of the references or sign them to enable side-by-side." (iisreset resovles) and generally slow debugging attaching. The points and answers to this question need not help with the above (I believe it may be related to spark view engine as that where the stacktrace ends) but figure it worth mentioning incase someone has a direct suggestion *
quick tip: if you're experiencing slow response times (~1-1.5 sec) from browsers other than internet explorer (eg: firefox, chrome, safari) while running your mvc/ other web app on your local machine using win7/vista, it is due to dns resolution with ipv6.
firefox solution: disable ipv6 in about:config (boolean cfg 'network.dns.disableIPv6')
machine wide soft solution: uncomment the good old localhost address in the hosts file (%WINDIR%\System32\drivers\etc\hosts):
# localhost name resolution is handled within DNS itself.
127.0.0.1 localhost
# ::1 localhost
machine wide hard solution: disable ipv6 completely
credit goes to this blogpost: http://weblogs.asp.net/dwahlin/archive/2007/06/17/fixing-firefox-slowness-with-localhost-on-vista.aspx
Embarcadero guys just published a fresh article on similar topic for Delphi Prism (aka Delphi for .NET), so why not take a look on their suggestions?
http://edn.embarcadero.com/article/40108
From the experience i have working with asp.net mvc, i can tell that there are no special settings for IIS 7 or IIS 7.5 for working on asp.net mvc projects. It works fine in the default form, you just need to create a new website and point it to the folder that has the files for you application.
For debugger if you ask, you can simply put a breakpoint in the code and hit that breakpoint when you run the application from visual studio. But by default the application will use the development web server that fires up when you run a web application from visual studio. If you want to the application to run using the IIS installed on your system you will have to change the project settings. See here for a screen shot of how to do so
http://blogs.bootcampedu.com/blog/post/Debugging-aspnet-mvc-application-using-IIS.aspx
Additionally you can also use System.Diagnostics.Debugger.Break(); for putting a break point in the code.
If you only want to debug your application, I recommend to use the built-in development server of Visual Studio.
If you debugged the most of it or want to do that on IIS, I recommend you the Ctrl+Alt+P shortcut, which enables you to attach a debugger. Select w3wp.exe and you can debug with IIS.
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.
Looked for an answer to this and didn't see it.
This is for IIS 6.0 / Windows Server 2003.
I'm working with an extremely large ASP/ASP.NET application and I'm trying to get my development environment to match my team members environment. This process is basically trial and error: get an error, go into IIS, make a change, hope the error is fixed. Ugh. I'm hoping to find a way to replicate a set of IIS directories and their configurations on one machine onto my machine.
I did find a script that will iterate through and give me a list of all virtual directories on a machine. It helped, but not a lot since I still have to go in and set up all those virtual directories (I think there are like 20 of them ballpark). The whole process is complicated by the fact that we're mixing ASP and ASP.NET applications in the same application which spans many solutions and projects. Getting the whole thing up and going seems like way too much work but I've never heard of a real solution to this.
Would Powershell be helpful here?
You should export and import IIS metabase.
These might help:
IIS Settings Replication
IIS Metabase Backup and Restore
Fortunately, in IIS7, ASP.NET config is integrated with IIS config so the job is done by copying Web.config.
Here's Microsofts' documentation for iiscnfg. iiscnfg documentation
When I ran it the first time, I got an error that said "This script does not work with WScript." If that happens to you:
1. Click OK.
2. At the "Would you like to register Cscript as your default host for VBscript?" click Yes.
3. At "Successfully registered Cscript" click OK.
4. Run the command again