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:

stack

This is before making the change.

kick it on DotNetKicks.com

Comments (41)

  1. You’ve been kicked (a good thing) – Trackback from DotNetKicks.com

  2. tomchris says:

    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

  3. so you just execute this one time and you’re good to go?

  4. tomchris says:

    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.

  5. molotov says:

    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…

  6. tomchris says:

    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.

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

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

  9. Josh Coswell says:

    This stack problem is new to me.

    Josh

    http://riverasp.net

  10. Michael Reyeros says:

    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.

  11. tomchris says:

    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.

  12. ML says:

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

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

  14. tomchris says:

    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.

  15. Wow! Thanks for sharing that Tom :-)

  16. Sidar Ok says:

    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?

  17. tomchris says:

    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.

  18. Ajay says:

    Tom,

    Is it 256 KB for IIS 7 in Longhorn Server?

  19. tomchris says:

    Yes it is the same for Windows Server 2008

  20. Cesar says:

    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.

  21. molotov says:

    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?

  22. Cesar says:

    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

  23. Cesar says:

    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!

  24. molotov says:

    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

  25. Michael says:

    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>

  26. Michael says:

    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?

  27. Michael says:

    never mind it is not working what so ever.

  28. tomchris says:

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

  29. Michael says:

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

  30. Roger says:

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

  31. sebastian says:

    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

  32. tomchris says:

    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

  33. Robert says:

    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,

    Robert

  34. tomchris says:

    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?

  35. Robert says:

    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?

  36. molotov says:

    Robert – in addition, check the event logs for messages that may relate to WFP kicking in…

  37. Tom says:

    Where can I get editbin.exe from ?

  38. tomchris says:

    It is included with the Microsoft Visual C++ development environment.

  39. Ayman Zaza says:

    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?

  40. Vikas says:

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