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.
Related
Answering one of the recent question on SO, i encountered this anomaly.
This msdn blog suggests using IIS to generate machine key, which looks more secure to me as Microsoft tool being used. However, it seems this feature is only supported until IIS 7 or less.
I don't find it on my box IIS 8.5. I checked on IIS 7.5 and its not present there either. However, I found it in IIS 6.1 on a coworker box.
I am wondering whether:
It still exist in IIS latest versions, if yes, how to use it?
If it is removed from latest version of IIS, what's suggested approach from Microsoft to generate a secure enough machine key?
Is it safe to use these custom generators?
a. Machine Key Generator (online)
b. ASP.NET machineKey Generator (tool you can modify)
See https://support.microsoft.com/kb/2915218#AppendixA for information on how to generate a <machineKey> element. There's a script there that you can copy & paste into a Powershell window.
Reminder: only use keys that you generated yourself on your own machine. Never use an online generator.
As for mentioned by #ryanulit, you can just copy the script directly to your PowerShell window
Steps :
Open powershell window (anywhere is fine)
Copy the script from the microsoft link and paste in your powershell window and press enter
Type Generate-MachineKey -validationAlgorithm SHA1
That's it. Your machine key description will show up in the window.
PowerShell image sample from my PC
Script Link from Microsoft http://support.microsoft.com/kb/2915218#AppendixA
I know I came to very late to provide this answer. Hope this helps for any others.
I'm using the latest IIS 10(which is the latest)
By default, the Machine Key feature is not installed when enabling the Internet Information Service in the windows features.
You need to install ASP.NET XX from the World Wide Web Service
After installing this, you can generate your keys from the Machine Key Option.
Make a copy of the administration.config file in C:\Windows\System32\inetsrv\config. Then, in the <moduleProviders> node under <!-- ASP.NET Modules--> remove the MachineKey node. Then run iisreset. Re-open IIS and see if the ASP.NET area is present. If it is, put the MachineKey node back in the administration.config file (or just re-instate the original config file) and run iisreset again.
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']
Windows Web Server 2008 R2 (x64) &
.Net Framework 4.5
It is a classic ASP.Net Web Site (Not a web project, code is in App_Code directory and compiled when the site is being launched)
And it depends on many reference DLLs in /Bin directory.
For those DLLs I have source code, I compile them targeted as "x64" platform.
And I have some other DLLs without source code (mysql.data.dll / etc), which are compiled as "Any CPU".
I modified them in EditBin.exe to ensure the IMAGE_FILE_LARGE_ADDRESS_AWARE flag is indicated in their PE header.
According to this table:
http://msdn.microsoft.com/en-us/library/aa366778%28VS.85%29.aspx#memory_limits
x64 process can't use more than 2GB memory unless IMAGE_FILE_LARGE_ADDRESS_AWARE is set.
How can I verify whether it works?
Is there any place I can see the memory limitation of running x64 process?
I don't know if you can actually "see the memory limitation" explicitly stated (assuming you don't trust MS's own documentation that you cited) other than getting your hands on and digging into the IIS and/or ASP.NET source code.
That being said, you could try stress testing the site, and monitor memory consumption (via Task Manager or Process Monitor), to see if it exceeds 2GB. I would recommend tinyget, part of the IIS 6 Resource Kit, which can still be used with IIS 7.
tinyget -svr:localhost -uri:/<your site> -loop:200 -threads:20
You'll have to play with the loop and thread count to try to push it over 2GB. I would expect to see an System.OutOfMemoryException as you approach about 1.4GB of combined physical and virtual private bytes. You may want to create a stress test function in the site itself, for testing purposes only of course, which will help you reach this limit, by using the exact opposite of good practices. You can read more about what would lead to an System.OutOfMemoryException` here, and then do things they recommend against. For example, add a test method that just concatenates strings in a very large loop.
try procexp, from sysinternals here. This application can monitor .NET specific metrics.
Nevertheless, according to your link, you should be able to address at least 8GB.
Please keep in mind that enforcing the IMAGE_FILE_LARGE_ADDRESS_AWARE is irrelevant in your case. You could have all your components compiled to target "Any CPU", the only flag that is checked is the flag of the executable file.
after installing .NET 4.5 on a Windows Web Server 2008 R2, some performance counters shows the wrong values. I'm using the built in Performance Monitor and looking at the group
ASP.NET Apps v4.0.30319 for counters Anonymous Requests/Sec and Requests Executing.
Before those values reflected the current load with fluctuating values, but now they instead increases for each request, so they behave more like Total Requests and Total Requests Executing.
We have seen the same behavior in a production environment and also on internal servers.
Have any of you seen the same behavior, I can find anything when googling for it.
Regards
Patrik
Fix for this issue is available now. http://support.microsoft.com/kb/2805227 for windows8 and http://support.microsoft.com/kb/2805226 for windows 7 platform.
So below workaround is no longer required.
The workaround for this issue is to execute below commands from 4.5 installed directory, (e.g. “%systemroot%\Microsoft.Net\Framework64\v4.0.30319”)
aspnet_regiis -u
aspnet_regiis -I or aspnet_regiis -iru
One thing that comes to mind is permissions on this registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\version of ASP.NET\Names
I'd start off by checking those and ensuring they're correct. If you have multiple versions you can even cross-check/compare the settings (ie if 2.0 still works fine)..
I have an ASP.NET 3.5 website running under IIS7 on Windows 2008.
When I restart IIS (iisreset), then hit a page, the initial startup is really slow.
I see the following activity in Process Explorer:
w3wp.exe spawns, but shows 0% CPU
activity for about 60 seconds
Finally, w3wp.exe goes to 50% CPU for
about 5 seconds and then the page
loads.
I don't see any other processes using CPU during this time either. It basically just hangs.
What's going on during all that time? How can I track down what is taking all this time?
We had a similar problem and it turned out to be Windows timing out checking for the revocation of signing certificates. Check to see if your server is trying to call out somewhere (e.g. crl.microsoft.com). Perhaps you have a proxy setting incorrect? Or a firewall in the way? We ultimately determined we had enough control over the server and did not want to 'call home', so we simply disabled the check. You can do this with .NET 2.0 SP1 and later by adding the following to the machine.config.
<runtime> <generatePublisherEvidence enabled="false"/> </runtime>
I am not sure if you can just put this in your app.config/web.config.
IL is being converted into machine native code (Assembly) by the Just-In-Time compiler and you get to wait while all the magic happens.
When compiling the source code to
managed code, the compiler translates
the source into Microsoft intermediate
language (MSIL). This is a
CPU-independent set of instructions
that can efficiently be converted to
native code. Microsoft intermediate
language (MSIL) is a translation used
as the output of a number of
compilers. It is the input to a
just-in-time (JIT) compiler. The
Common Language Runtime includes a JIT
compiler for the conversion of MSIL to
native code.
Before Microsoft Intermediate Language
(MSIL) can be executed it, must be
converted by the .NET Framework
just-in-time (JIT) compiler to native
code. This is CPU-specific code that
runs on the same computer architecture
as the JIT compiler. Rather than using
time and memory to convert all of the
MSIL in a portable executable (PE)
file to native code. It converts the
MSIL as needed whilst executing, then
caches the resulting native code so
its accessible for any subsequent
calls.
source
Thats the compilation of asp.Net pages into intermediate language + JIT compilation - it only happens the first time the page is loaded. (See http://msdn.microsoft.com/en-us/library/ms366723.aspx)
If it really bothers you then you can stop it from happening by pre-compiling your site.
EDIT: Just re-read the question - 60 seconds is very long, and you would expect to see some processor activity during that time. Check the EventLog for errors / messages in the System and Application destinations. Also try creating a crash dump of the w3wp process during this 60 seconds - there is an chance you might recognise what its doing by looking at some of the call stacks.
If it takes exactly 60 seconds each time then its likely that its waiting for something to time out - 60 seconds is a nice round number. Make sure that it has proper connections to the domain controllers etc...
(If there are some IIS diagnostic tools that would do a better job then I'm afraid I'm not aware of them, this question might be more suited to ServerFault, the above is a much more developer-ish approach to troubleshooting :-p)
I found that there was a network delay making an initial connection from the front end web server to the database server.
The issue was peculiar to Windows 2008 and our specific network hardware.
The resolution was to disable the following on the web servers:
Chimney offload state
Receive window auto-tuning level
Greater than 60 seconds sounds fishy. Try running a test.html page to see how long that takes. That will isolate IIS7's role.
Then temporarily rename your web.config, global.asax and application folders and try a test.aspx page (very simple page). That will isolate ASP.NET.
If both of those are fast (i.e. about 10 seconds), then it's your application. But, if either are slow then not the application and something with the server itself.
This hat nothing to do with JIT compiling. The normal C# compiler compiles your code behind files (.aspx.cs) into intermediate language into an assembly at startup if this assembly dont exist or code files have changed. Your web site assembly is located in the "bin" folder of your web site.
In fact the JIT compiling occures after that, but this is very fast and won't take several minutes. JIT Compiling happens on every startup of an .net application and that won't take more than a view seconds.
You can avoid the copmpiling of your web site if you deploy the already compiled website assembly (YourWebsite.dll) into the bin folder. It is also possible to deploy only the aspx files and leave the code behind files (aspx.cs) files away.
I've just been battling a similar issue. For me it turned out to be that I had enabled internal logging for NLog. It added about 3 minutes to the startup time!
Original config
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
autoReload="true"
throwExceptions="false" throwConfigExceptions="false"
internalLogLevel="Debug"
internalLogFile="C:\Temp\NLog.Internal.txt">
Fixed Config
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
autoReload="true"
throwExceptions="false" throwConfigExceptions="false">
For Info I discovered this by using SysInternals' ProcMon.exe, filtering on the Process Name "w3wp.exe"