This article is to show how to capture a real stack overflow exception happened in MVC web app on Azure. Actually after reading you will find this method can be used to solve other web apps which has intermittent 1st chance exception issues.
The sample MVC web app is from a small test project from https://github.com/freistli/Dev14_Net46_Mvc5/tree/StackOverflow. When run it and click the Contact menu, the application will immediately exit and shows this error on Azure Web App:
In this sample, we know it is a fatal c00000fd exception (native stackoverflow exception). If in real production situation cannot retrieve the code info from event log or other logs, can contact Microsoft Support Team to see if can get exit code from backend logging tables.
To further investigate the exception, we expect to take the crash dump exactly when the exception happens. Now let’s use CrashDiag:
1. Install Crash Diagnoser site extension from the Azure Site Extension Gallery from Azure Portal. For detailed installation steps please refer to this article.
Please make sure the web app configuration is “AlwaysOn” because the Crash Diagnoser runs as a Continuous web job. Refer to: http://blog.amitapple.com/post/73574681678/git-deploy-console-app/#.VpcHaPl96Ul
2. Browse the extension (https://yourtestapp.scm.azurewebsites.net/cashdiag). Click the 1st chance exception tab, set the setting as:
Please notice The Managed Exception option is selected as “No” because it is a crash on native exception code c00000fd
The reason we don’t configure and capture 2nd chance unhandled exception for the MVC app is ASP.NET by default captures unhandled 1st chance exceptions in HTTP Context directly and makes an exit. It quits directly after those “fatal” 1st chance exceptions without throwing 2nd chance exception.
If you saw StackOverflowException exception code was recorded in d:\home\logfiles\eventlog.xml, it means the exception is managed exception:
Then you should set exception code as “overflow” or “StackOverflowException”, Managed Exception as “Yes”:
3. Click the Start button. The CrashDiag starts monitoring w3wp process.
4. Once the c00000fd exception happens, the dump can be generated automatically. After dump is generated completedly (the file size doesn’t change for 10 seconds), click the file name to download it.
Then we can use debugging tool (Windbg or DebugDiag) to debug the dump to see how the exception happens. This sample dump shows calls tack as below, then it accurately points to the Foo() function caused the process termination:
-Freist Li from APGC DSI Team