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.

Published 31 March 08 01:24 by Tom

Filed under: ASP.NET, IIS

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# DotNetKicks.com said on March 31, 2008 1:25 PM:

You've been kicked (a good thing) - Trackback from DotNetKicks.com

# Tom said on March 31, 2008 1:29 PM:

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.aspx

# Eber Irigoyen said on March 31, 2008 1:43 PM:

so you just execute this one time and you're good to go?

# Tom said on March 31, 2008 1:50 PM:

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.

# molotov said on March 31, 2008 2:03 PM:

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...

# Tom said on March 31, 2008 2:32 PM:

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.

# Jason N. Gaylord's Blog said on March 31, 2008 3:24 PM:

Apparently the IIS stack has changed in Server 2003. I've never noticed any issues with my ASP.NET apps

# Jason N. Gaylord's Blog said on March 31, 2008 4:01 PM:

Apparently the IIS stack has changed in Server 2003. I've never noticed any issues with my ASP.NET

# Josh Coswell said on March 31, 2008 7:33 PM:

This stack problem is new to me.

Josh

http://riverasp.net

# Michael Reyeros said on April 1, 2008 8:20 AM:

Good morning, our team recently faced this issue with the Stack Size restriction in Windows 2003, and newer OSes for that matter. Our ASP.net application generates very large pdf files and what we were experiencing was that on XP, which still had the 1mb stack size, all was well. Once we move the code to production, a Windows Server 2003 box, we started seeing that the application would crash. We checked the Application event log and noticed that we were receiving an error on the w3wp.exe worker process service. The way that we resolved this issue was to create a seperate thread joined to the current thread of the application and call our generate pdf method from this thread. Here is some code for all that may need it for future reference:

protected void Button1_Click(object sender, EventArgs e)

{

Thread t = new Thread(GenerateCertificates, 4194304);

t.Priority = ThreadPriority.Lowest;

t.Name = "BatchCertificateThread";

t.Start();

t.Join();

}

Basically the new Thread() constructor accepts a delegate as well as a maxStackSize parameter here is where you can set the StackSize for this new thread. In the code above I have set it to 4mb since sometimes the pdfs that we are generating can grow to well over 1000 pages.

I hope that this information will be useful to anyone experiencing this issue.

# Tom said on April 1, 2008 8:39 AM:

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.

# ML said on April 1, 2008 11:20 AM:

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 :)

# Eber Irigoyen said on April 1, 2008 2:33 PM:

how do you change that file without Windows File Protection restoring it back?

# Tom said on April 1, 2008 2:57 PM:

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.

# rahulso said on April 3, 2008 7:36 AM:

Wow! Thanks for sharing that Tom :-)

# Sidar Ok said on April 21, 2008 8:29 PM:

Hi Tom, thanks for the great post ! I am just wondering, this is such a hack, so does it have any legal implications - like microsoft accepting no responsibility or support etc. ?

And I wonder your opinion, why isnt this configurable either through user friendly iis snap in or even metabase?

# Tom said on April 21, 2008 11:42 PM:

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.

# Ajay said on May 6, 2008 4:19 PM:

Tom,

Is it 256 KB for IIS 7 in Longhorn Server?

# Tom said on May 6, 2008 4:35 PM:

Yes it is the same for Windows Server 2008

# Cesar said on August 27, 2008 8:26 AM:

Hello, i'm facing the same problem with my production site so i found this info very usefull but i've tried with

C:\WINDOWS\system32\inetsrv>dumpbin /all /out:original-config.txt w3wp.exe

Later with

C:\WINDOWS\system32\inetsrv>EDITBIN /STACK:1048576 w3wp.exe

And once finished with

C:\WINDOWS\system32\inetsrv>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.

# molotov said on August 27, 2008 9:31 AM:

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?

# Cesar said on August 28, 2008 8:23 AM:

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 bands

# molotov said on August 28, 2008 9:28 AM:

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).

# Cesar said on September 1, 2008 9:09 AM:

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!

# molotov said on September 1, 2008 2:46 PM:

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#8347999

# Michael said on September 16, 2008 6:21 PM:

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:\Windows\System32\inetsrv>EDITBIN /STACK:1048576 "w3wp - Copy.exe"

Microsoft (R) COFF/PE Editor Version 9.00.21022.08

LINK : fatal error LNK1104: cannot open file 'w3wp - Copy.exe'

C:\Windows\System32\inetsrv>

# Michael said on September 16, 2008 6:28 PM:

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?

# Michael said on September 16, 2008 6:50 PM:

never mind it is not working what so ever.

# Tom said on September 17, 2008 5:47 AM:

What operating system are you on? You may be running into an issue with system file protection.

# Michael said on September 17, 2008 9:44 PM:

I am running Windows Vista Home Premium

I have given Administrator ownership of the file and I have given it full access. I then do the same thing again on an administrator Visual Studio 2008 Command Prompt and I get the same link error.

This is crazy. All this because Microsoft underestimates it's programmer's needs :-(

# Roger said on September 18, 2008 12:09 PM:

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();

# sebastian said on February 27, 2009 10:48 AM:

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...

1) My app just hosts WCF services... should I create the new thread in the Global.asax.cs's Application_Start?

2) 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

# Tom said on March 3, 2009 10:30 PM:

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).aspx

# Robert said on June 26, 2009 11:48 AM:

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 Windows\System32\Inetsrv 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,

Robert

# Tom said on June 26, 2009 12:15 PM:

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?

# Robert said on June 26, 2009 3:05 PM:

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?

# molotov said on June 26, 2009 10:45 PM: