Methods of .NET self-annihilation part 3: Stack Overflow

This is another issue that results in Frequent Web Application Restarts, which causes the performance to plunge.

Death by Stack Overflow

This one is interesting, yet it has nothing to do with

The StackOverflowException is one of very few exception classes in .NET that are not catch-able. Scratch that, it’s not possible to “swallow” it in a try-catch clause, because even if you don’t re-throw it, .NET will:

Starting with the .NET Framework 2.0, you can’t catch a StackOverflowException object with a try/catch block, and the corresponding process is terminated by default.

Some time back, I was involved in a case where the w3wp.exe’s started crashing. No recent deployments had been made. This message could be found in the event log:

Faulting application name: w3wp.exe, version: 7.5.7601.17514, time stamp: 0x4ce7afa2
Faulting module name: clr.dll, version: 4.0.30319.18034, time stamp: 0x50b5a783
Exception code: 0xc00000fd Fault offset: 0x000000000001a840
Faulting process id: 0xd50
Faulting application start time: 0x01ce97fe076d27b4
Faulting application path: c:\windows\system32\inetsrv\w3wp.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll Report Id: e0c90a5f-0455-11e3-8f0e-005056891553

The important piece in this message is 0xc00000fd , that’s the exception code meaning “Stack Overflow”.

Needless to say, the restarts were detrimental to the site’s performance.

It was found that this exception was caused by a code snippet like this:

// StackOverflowException-causing example code -- Do Not Use!
string FindUniqueName(string suggestedName, string ext, int counter)
    string candidateName = string.Format("{0}{1}.{2}", suggestedName, counter, ext);
    if (HostingEnvironment.VirtualPathProvider.FileExists(candidateName))
        return FindUniqueName(suggestedName, ext, counter+1);
    return candidateName;

If the method is called with the same suggested name repeatedly (turns out most mobile devices name their uploads “image.jpg”) and then image0.jpg .. image6842.jpg, after a few months “image6843.jpg” would be churned out as the unique name for the upload. Unfortunately when the function recursed that deep, it ran out of stack space and so the StackOverflowException was thrown by the .NET runtime.

This blog post covers the tools needed to troubleshoot issues of this kind quite well and also explains steps required to find which piece of your application causes it to die.

2 responses to “Methods of .NET self-annihilation part 3: Stack Overflow”

  1. Been there. We inherited a site that a few years later restarted a few times per hour. Turned out it was a function that parsed links in comments that did an infinite loop. Took som headbanging to find that little feature…

    • You think having this post would’ve helped you nail it? If not, what’s missing?

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.