MSDN Blogs: Tips of using Crash Diagnoser on Azure Web App

After Crash Diagnoser was released, glad to see it does help users and support team to collect expected dump data to perform further analysis. If you haven’t touched it before, can read the previous posts here:

http://blogs.msdn.com/b/asiatech/archive/2015/12/29/use-crashdiag-site-extension-to-capture-dump-for-intermittent-exception-issues-on-microsoft-azure-web-app.aspx

http://blogs.msdn.com/b/asiatech/archive/2016/01/12/how-to-use-crashdiag-to-capture-stack-overflow-exception-dump-in-mvc-web-app-on-microsoft-azure.aspx

Actually the problem that Crash Diagnoser is going to resolve is in an advanced troubleshooting area (Debugging and Exception capture). Based on the users’ feedback and usage experience, I’d like to share some tips so that the extension can help you easier during Crash/Hang problem investigation:

1. Ensure the web app Application Setting “Always On” is enabled (So your Web APP service plan should be Basic or above)

The reason is Crash Diagnoser runs as continuous web job on backend.

Without “Always On”, after 20 minutes idle time the SCM kudu site will be unloaded, and the web job will be stopped.

2. When your ASP.NET application terminated unexpectedly, normally you have to use 1^st chance exception capture because:

Since ASP.NET 2.0, ASP.NET by default will handle all unhandled 1^st chance exceptions thrown from HTTP Context and make the process exit.

This means you have no chance to see 2^nd chance exception unless the unhandled 1^st chance exception doesn’t happen in HTTP Context

3. If the exception code is .NET exception (generally you will see its terms in d:\home\logfiles\eventlog.xml, such as NullReferenceException, FileNotFoundException, TimeoutException, etc), when configure the 1^st chance exception, please make sure the “Managed Exeption” is marked as Yes:

4. After troubleshooting, click “Safe Stop” will almost stop the Crash Diagnoser (it will be waked up every 60 seconds but doesn’t do any task and then quit). To completely stop it, can open Web Job list under the Web APP, and explicitly stop it. In the WebJobs blade, right click and stop CrashHelper (CrashDiagnoser package).

After this operation, if you want to start Crash Diagnoser again through (https://yourwebapp.scm.azurewebsites.net/crashdiag ), please start this job explicitly first.

5. For php and node.js exceptions, they are their “managed” exceptions and are not exposed as native exceptions handled by Kernet32!RaiseException. For those third party “Managed” exceptions, can use their verbose error logging to do further diagnostics. If the crash/exception happened on their product level and no useful information their logs, can use Crash Diagnoser to capture the issues.

Thanks,

Freist from APGC DSI Team