Troubleshooting Dynamics CRM extensions – Part 1

Gayan Perera, 06 August 2010

In this multi-part blog series I’ll show you how you can troubleshoot errors in Dynamics CRM. Part 1 will cover ISV extensions (custom aspx pages); Part 2 will cover plugins, part 3 and 4 let’s see how we go ☺

We specialise in creating xRM solutions and most of them are fairly large involving custom aspx page extensions. Occasionally one of those pages will crash due to a bug, when this happens in the development environment we can catch and fix easily but when it happens in the production environment we need to have useful information about the crash in order to fix it.

One of the techniques is making sure we are notified whenever there is an unexpected crash. We do this by using an HttpModule and registering it inside the web.config file.

<add name="ErrorModule" type="Magnetism.Generic.ErrorModule, Magnetism.Generic" />

We capture the following information

• Error using Server.GetLastError();

• Form keys and values using Request.Form.Keys

• Server variables using Request.ServerVariables

• Session keys and values using Session.Keys

All of that information gets emailed to <spam-blocker>@magnetism.co.nz.

Stack trace, form variables and session variables gives us an insight into the problem and gives us a starting point.

The added benefit of having the error emailed to us is when the user submits a bug report with unuseful information all we need is the approximate time it happened and we can look at where and why it happened.

Another technique we use is tracing within the application, we write all important events to a log file, which can be turned on or off via the web.config file, this allows us to track down logic errors in the production environments where debugging is not available.

When dealing with calculations in addition to unit tests a tracer is used in the production environment to track anomalies.