Stack sizes in IIS - affects ASP.NET
The default stack size of IIS starting with Windows Server 2003 was changed. Prior to 2003, it was set to 1 MB. This is also true of the aspnet_wp.exe process that Windows 2000 uses.
In 2003 and later, it is now set to 256 KB.
This can cause a process to run out of stack space if it has something that uses a recursive function.
This is talked about in our Knowledge Base here.
If you want to change this back to the 1 MB that it used to be, you can use editbin to do this.
EDITBIN /STACK:1048576 w3wp.exe
This will change the process. You can use dumpbin to view the sizes:
This is before making the change.
Comments
Anonymous
March 31, 2008
You've been kicked (a good thing) - Trackback from DotNetKicks.comAnonymous
March 31, 2008
One additional note, if you are creating your own thread, and it is a native thread, you can use the CreateThread API and pass it a stack size, but since this doesn't work work .NET, I didn't want to include it in the main post. This is talked about here: http://msdn2.microsoft.com/en-us/library/ms686774.aspxAnonymous
March 31, 2008
The comment has been removedAnonymous
March 31, 2008
yes, once you run this command, it will change the exe and it will always run that way. Until you install an update, like the next Service Pack. That will put down a fresh exe and so it will set it to whatever Microsoft has set it to.Anonymous
March 31, 2008
It may be worth mentioning that the modification to the binary / EXE will render it "unverifiable" - it would seem that tools like Sigcheck and Process Explorer would be unable to verify the module...Anonymous
March 31, 2008
Molotov, that is a very good point. Since you would be modifying the original file so anything that checks it would say the file has changed.Anonymous
March 31, 2008
Apparently the IIS stack has changed in Server 2003. I've never noticed any issues with my ASP.NET appsAnonymous
March 31, 2008
Apparently the IIS stack has changed in Server 2003. I've never noticed any issues with my ASP.NETAnonymous
March 31, 2008
This stack problem is new to me. Josh http://riverasp.netAnonymous
April 01, 2008
The comment has been removedAnonymous
April 01, 2008
Thanks Michael, that is another useful workaround that will allow you to keep the stack size the default. You just have to be careful that you watch your thread count as this will create an extra thread for each request to this page. You may need to raise your threadpool settings to accomidate the additional threads.Anonymous
April 01, 2008
Just wanted to add a small comment here about this approach of creating you own thread as opposed to using editbin. The approach of creating your own thread and set a specific size limit to workaround the .net stack size limitlation under IIS6 seems to be much more better since you don't have to keep track of new updates that may change w3wp.exe and on the other hand it addresses just specific threads that you would need them to have larger size instead of all threads within w3wp.exe. I debugged this yesterday and it seems that even if you set a size limit of 4 MB (Thread t = new Thread(GenerateCertificates, 4194304);), the thread is created first with a size of 8k and continues growing anytime more space is needed until it reaches the specified limit. So no worries of using the whole 4 MB at thread start :)Anonymous
April 01, 2008
how do you change that file without Windows File Protection restoring it back?Anonymous
April 01, 2008
That is a good question. There are some ways to do it that you can find online, like turning WFP off or disabling it for a folder. If you'd like to do that, just search online and proceed with caution! The suggestion from Michael is a good solution if you know where you may run into this. Generally it isn't a common problem unless you are doing some intensive work.Anonymous
April 02, 2008
Wow! Thanks for sharing that Tom :-)Anonymous
April 21, 2008
The comment has been removedAnonymous
April 21, 2008
Sidar, You are right, changing the file would mean we accept no responsibility, but it really wouldn't cause any harm. Just have to watch out for updates changing the file back. See some of the comments above for other options. I can't really comment on why it isn't configurable other then to say it was a decision they made. Probably didn't think this was something that people would need to configure.Anonymous
May 06, 2008
Tom, Is it 256 KB for IIS 7 in Longhorn Server?Anonymous
May 06, 2008
Yes it is the same for Windows Server 2008Anonymous
August 27, 2008
Hello, i'm facing the same problem with my production site so i found this info very usefull but i've tried with C:WINDOWSsystem32inetsrv>dumpbin /all /out:original-config.txt w3wp.exe Later with C:WINDOWSsystem32inetsrv>EDITBIN /STACK:1048576 w3wp.exe And once finished with C:WINDOWSsystem32inetsrv>dumpbin /all /out:modified-config.txt w3wp.exe and both output files (original-config.txt and modified-config.txt) are exactly the same, stack size was't modified :( and the web application remains without work. What I'm missing ? Thanks in advance.Anonymous
August 27, 2008
Hi Cesar, It's possible that WFP is kicking in. Any entries in the event logs indicating that changes have been detected and that a file has been restored?Anonymous
August 28, 2008
Yes molotov, In the event logs i have events indicating changes and restoration file on w3wp.exe I've disabled the firewall, but w3wp remains unchanged :( molotov = one of my favorite bandsAnonymous
August 28, 2008
So WFP is restoring the original file after detecting modification. WFP is discussed in the comments above, by Eber (http://blogs.msdn.com/tom/archive/2008/03/31/stack-sizes-in-iis-affects-asp-net.aspx#8348630) and Tom (http://blogs.msdn.com/tom/archive/2008/03/31/stack-sizes-in-iis-affects-asp-net.aspx#8348671).Anonymous
September 01, 2008
Thank you so much, the problem was solved implementing the Michael Reyeros solution, creating a thread with the desired size and later join them to the main process. Tks!Anonymous
September 01, 2008
Good to hear you've found something that works, Cesar. Just be sure to note Tom's comment @ http://blogs.msdn.com/tom/archive/2008/03/31/stack-sizes-in-iis-affects-asp-net.aspx#8347999Anonymous
September 16, 2008
I can not get it to work. What am I doing wrong? I have even tried it to a copy of the file and even tried in administrator mode. I am using Visual Studio 2008 Command Prompt C:WindowsSystem32inetsrv>EDITBIN /STACK:1048576 "w3wp - Copy.exe" Microsoft (R) COFF/PE Editor Version 9.00.21022.08 Copyright (C) Microsoft Corporation. All rights reserved. LINK : fatal error LNK1104: cannot open file 'w3wp - Copy.exe' C:WindowsSystem32inetsrv>Anonymous
September 16, 2008
I got it to work! While searching the web I found this entry. http://forumplanet.gamespy.com/battlefield_2_technical_help/b49106/5428486/r19538781/ Search down to GhostSpyke's post. It seems that you are not supposed to put spaces??? Why is this?Anonymous
September 16, 2008
never mind it is not working what so ever.Anonymous
September 16, 2008
What operating system are you on? You may be running into an issue with system file protection.Anonymous
September 17, 2008
The comment has been removedAnonymous
September 18, 2008
Michael's approach was working. I created a thread to handle the pdf content and the rendering in the IE browser. But when my code rendered the pdf document to the browser, the pop-up browser was blank. The pdf content got rendered in Adobe Reader instead. If I removed my code change, the pdf content was rendered correctly in the browser. Do anybody know why this happened? Thanks. Note: Here is how I render the content MemoryStream ms = report.RunReport(...); Response.Buffer = true; Response.ClearContent(); Response.ClearHeaders(); Response.ContentType = "application/pdf"; Response.AddHeader("content-disposition", String.Format("inline; filename=illustration{0}.pdf", uniqueId)); Response.BinaryWrite(ms.ToArray()); Response.End();Anonymous
February 27, 2009
Hey, facing the same problem here. The EDITBIN solution worked for us but since we're shipping the product we need to increase the stack by code. I have two questions...
- My app just hosts WCF services... should I create the new thread in the Global.asax.cs's Application_Start?
- What about the child threads... the logic of the services sometimes creates new threads (BackgroundWroker). Will these inherit the size of the stack from the parent thread? TIA sebastian
Anonymous
March 03, 2009
Sebastian, A couple questions first, often times there is another way to design your application so you don't need this much stack space. Have you investigated that yet? Application_Start should be a good place to create it. For new threads, the Thread constructor takes a maxStackSize parameter. Take a look at: http://msdn.microsoft.com/en-us/library/5cykbwz4(VS.80).aspxAnonymous
June 26, 2009
I tried editing the stack size of w3wp.exe in its native folder, but even after carefully taking ownership of the file and granting Full control, I am getting "LINK : fatal error LNK1104: cannot open file 'w3wp.exe'". If I make a copy of the file to another folder, I can edit it OK. But if I try to copy it back after editing, it appears that the copy worked OK (the directory entry shows the new modified date of the file) but the file has the old stack size again. This happens even if I take ownership and full control of the WindowsSystem32Inetsrv folder. I think Windows Resource Control is doing something insidious here. I am using Windows Vista 64 bit. Is this a Windows Resource Control problem, and is there a way around it? Thanks, RobertAnonymous
June 26, 2009
Robert, It is probably the windows file protection that is doing it. So it is probably detecting that the file has changed and putting back the original. If you check the timestamp, do you see the file go back to the old version?Anonymous
June 26, 2009
No Tom, the timestamp stays the same. From what I can tell, Windows Resource Protection under Vista works differently than the old "Windows File Protection". I don't fully understand how, though. All I know is, I can modify a copy of the file in a different folder, verify with DumpBin that the stack size has changed, then copy the file to the Inetsrv folder, and the timestamp of the file in Inetsrv now reflects the new timestamp of the modified file, suggesting the copy was successful. However, when I run Dumpbin on it, the stacksize is back to 40000 hex. I think Windows Resource Protection makes an extra effort to trick a legacy installer into thinking it successfully copied a file, when it really didn't. The question is, is there a way to get around this? I've seen other posts from people that think if you take ownership of a file and give yourself full control, you can edit system files, but that doesn't seem to be working for me. Have you heard of any way of doing this?Anonymous
June 26, 2009
Robert - in addition, check the event logs for messages that may relate to WFP kicking in...Anonymous
June 27, 2010
Where can I get editbin.exe from ?Anonymous
July 01, 2010
It is included with the Microsoft Visual C++ development environment.Anonymous
September 21, 2011
Is it the same command for Windows 2008 R2 and IIS 7? when i run the command it always give me this error ( LINK : fatal error LNK1104: cannot open file 'w3wp.exe') and as Michael was said about removing the spaces; it didn't work as well. Any other ideas to change the stack size for IIS 7?Anonymous
November 03, 2011
I also faced fatal error for EDITBIN /STACK:1048576 w3wp.exe, but then I created new Thread. Thankyou Michael, creating new thread worked for me. Thanx a lot!!!