In this post in Tales from the Trenches, I will cover some common Dynamics CRM error message troubleshooting. This post describes the error message dialogs and how to either troubleshoot the error or gather enough information to help expedite a fix.
The Error Report dialog:
If you work in CRM for any amount of time, you will see this error. Sometimes it means nothing, but if it occurs consistently then it's probably worth checking out. Typically, this dialog is displayed in one of the following three situations:
The Error Report dialog will not appear until you browse away from the page that caused the error. Some custom scripts can cause errors to occur in system scripts by passing bad data. Sometimes errors will occur if a page didn't load completely before the user tried to browse away.
The dialog gives you the option of sending the error report to Microsoft. If you choose to do this, the information will be sent to Microsoft. What happens next is a a bit of a mystery... Presumably Microsoft reviews these reports and prioritize fixes for the next release, but it's also possible the reports are fairly ignored.
Because these errors can happen fairly often, most users will be quick to dismiss this error and move along. However, if you are troubleshooting a script that isn't working and are getting this error message on a consistent basis, there might be some information here to help you track down and resolve the issue.
If you click on the "View data that will be sent to Microsoft" link, you will be presented with an error report that might look similar to this:
At first glance, this is a very confusing, difficult-to-read report. However, there are a few pieces of data that can help point you in the right direction. The relevant lines are marked in the image above.
This dialog can be disabled at an organization level by browsing to System > Settings > Privacy Preferences and setting the error reporting option.
However, I strongly discourage this, because it can mask legitimate issues that could otherwise be resolved.
Form Event JavaScript error:
These errors are typically linked to either malformed script or a misconfigured event handler. Typically you will get this as soon as the event is triggered, e.g., by changing a field value or saving/loading a form.
Check the script and make sure there are no syntax errors. Make sure the event functions exist within the script. Finally, check the event handlers on the form to verify that they are pointing to the correct functions. Remember that scripts are case-sensitive so the function blah_OnChange isn't the same as Blah_onchange.
If you get this error followed by the Error Report dialog when browsing away from a page, there is probably a syntax error in a custom script. The Error Report should give you enough information to know what to look for (e.g., a missing semi-colon), and at which line it found that issue.
On some occasions, some CRM out-of-the-box entities can contain hidden references to scripts that can get stripped out when exporting a solution and require some manually XML editing to fix. One example is documented here on Microsoft's forums.
Browser JavaScript Debug Error:
Generally you will see this only if: (a) you have the browser's debug console open; (b) certain user settings are enabled in IE; or (c) Visual Studio is attached to the IE process. Typically this same error will end up in the Error Report when you browse away from the page, but this message displays as soon as the error occurs. Opening the script debugger will probably not help you very much, so you should click on "No".
Server / Platform errors:
These are errors that occur on the server, rather than within the user's browser. Typically these are related to plugins, real-time workflows, or plain old system level errors. You should only see these when you save a record.
By itself this dialog is fairly useless. However, if you click upon the "Download Log File" button, that will give you information which can actually track down the error. The following screen shot shows a sample Log File that contains more details about what caused the issue and where it occurred.
Take note of the first line. The section in the double square brackets ("[" and "]") gives you the name of the assembly in which the exception was thrown. If it is not prefaced by "Microsoft." Or "System.", then it might be a custom plugin that we can actually fix.
The next piece of the puzzle is the Message. This can help the developer isolate the problematic section of code.
If the error occurred within a custom plugin, the Trace Text may contain custom messages that the developer added to the plugin to track execution.
This should help with some Dynamics CRM error message troubleshooting. Keep an eye out for more Tales from the Trenches and remember, there's always more to learn about Dynamics CRM!