Unhandled Exception: An easy guide to interpret Dynamics CRM error messages.

How many time times have you been confronted with an error message (Unhandled Exception: …) when trying to do an action in Dynamics CRM? Today I’m going to take a closer look at how you can interpret those messages and take suitable actions based on them.

Exception examples

Lets take two examples without knowing what the user is trying to do or what the bigger context of the action is. Tl;dr: just scroll through them!

First example:

Unhandled Exception: System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=8.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]: SecLib::AccessCheckEx failed. Returned hr = -2147187962, ObjectID: 5dd8ae22-c3c8-e511-810c-3863bb349780, OwnerId: 371d7f67-03ba-e511-8113-3863bb34f748, OwnerIdType: 8 and CallingUser: fd1b738d-eef7-e511-80dd-5065f38b2571. ObjectTypeCode: 5, objectBusinessUnitId: b15e2c8d-bee7-e411-80fb-c4346badb168, AccessRights: DeleteAccess Detail:
<OrganizationServiceFault xmlns:i=”http://www.w3.org/2001/XMLSchema-instance” xmlns=”http://schemas.microsoft.com/xrm/2011/Contracts”>
<ErrorCode>-2147187962</ErrorCode>
<ErrorDetails xmlns:d2p1=”http://schemas.datacontract.org/2004/07/System.Collections.Generic” />
<Message>SecLib::AccessCheckEx failed. Returned hr = -2147187962, ObjectID: 5dd8ae22-c3c8-e511-810c-3863bb349780, OwnerId: 371d7f67-03ba-e511-8113-3863bb34f748, OwnerIdType: 8 and CallingUser: fd1b738d-eef7-e511-80dd-5065f38b2571. ObjectTypeCode: 5, objectBusinessUnitId: b15e2c8d-bee7-e411-80fb-c4346badb168, AccessRights: DeleteAccess </Message>
<Timestamp>2016-04-26T11:45:32.7691878Z</Timestamp>
<InnerFault i:nil=”true” />
<TraceText i:nil=”true” />
</OrganizationServiceFault>

Second example:

<s:Envelope xmlns:s=”http://schemas.xmlsoap.org/soap/envelope/”><s:Body><s:Fault><faultcode>s:Client</faultcode><faultstring xmlns:xml=”http://www.w3.org/XML/1998/namespace” xml:lang=”en-US”>SecLib::AccessCheckEx failed. Returned hr = -2147187962, ObjectID: 00000000-0000-0000-0000-000000000000, OwnerId: a9dd5cc5-5242-e511-80de-3863bb347d90, OwnerIdType: 8 and CallingUser: fd1b738d-eef7-e511-80dd-5065f38b2571. ObjectTypeCode: 2, objectBusinessUnitId: b15e2c8d-bee7-e411-80fb-c4346badb168, AccessRights: CreateAccess </faultstring><detail><OrganizationServiceFault xmlns=”http://schemas.microsoft.com/xrm/2011/Contracts”><ErrorCode>-2147187962</ErrorCode><ErrorDetails /><Message>SecLib::AccessCheckEx failed. Returned hr = -2147187962, ObjectID: 00000000-0000-0000-0000-000000000000, OwnerId: a9dd5cc5-5242-e511-80de-3863bb347d90, OwnerIdType: 8 and CallingUser: fd1b738d-eef7-e511-80dd-5065f38b2571. ObjectTypeCode: 2, objectBusinessUnitId: b15e2c8d-bee7-e411-80fb-c4346badb168, AccessRights: CreateAccess </Message><Timestamp>2016-04-26T11:48:20.6143717Z</Timestamp><InnerFault><ErrorCode>-2147187962</ErrorCode><ErrorDetails /><Message>SecLib::AccessCheckEx failed. Returned hr = -2147187962, ObjectID: 00000000-0000-0000-0000-000000000000, OwnerId: a9dd5cc5-5242-e511-80de-3863bb347d90, OwnerIdType: 8 and CallingUser: fd1b738d-eef7-e511-80dd-5065f38b2571. ObjectTypeCode: 2, objectBusinessUnitId: b15e2c8d-bee7-e411-80fb-c4346badb168, AccessRights: CreateAccess </Message><Timestamp>2016-04-26T11:48:20.6143717Z</Timestamp><InnerFault xmlns:i=”http://www.w3.org/2001/XMLSchema-instance” i:nil=”true” /><TraceText xmlns:i=”http://www.w3.org/2001/XMLSchema-instance” i:nil=”true” /></InnerFault><TraceText xmlns:i=”http://www.w3.org/2001/XMLSchema-instance” i:nil=”true” /></OrganizationServiceFault></detail></s:Fault></s:Body></s:Envelope>

Lets start!

First of all, you don’t need the entire message, a lot of it is just technical mambo-jambo which you don’t need to solve the exception. So I’ll cut away everything I don’t need, leaving me with this message:

SecLib::AccessCheckEx failed. Returned hr = -2147187962, ObjectID: 00000000-0000-0000-0000-000000000000, OwnerId: a9dd5cc5-5242-e511-80de-3863bb347d90, OwnerIdType: 8, CallingUser: fd1b738d-eef7-e511-80dd-5065f38b2571., ObjectTypeCode: 2, objectBusinessUnitId: b15e2c8d-bee7-e411-80fb-c4346badb168, AccessRights: CreateAccess

So what does it all mean?

  • ObjectID: this is the ID of the record that is creating the error message.
  • OwnerId: this is is the ID of the owner of the record
  • OwnerIdType: 8: this means the owner is an user. Yes, a team can  also be owner of a record.
  • CallingUser: this is the ID of the user who is doing the action which resulted in the exception
  • ObjectTypeCode: 2: you can check online to see to which objectype this relates to. In this case it relates to the contact entity in Dynamics CRM
  • objectBusinessUnitId: this is the ID of the busines unit in which the record resides
  • AccessRights: CreateAccess: this is the privilege that the user who is trying to do an action is missing and as a consequence is resulting in the “unhandled exception”-error.

So if we summarize the previous messages with the missing accesrights we can get the following conclusion; The user is trying to do an action in which he creates a contact.

Wow! this conclusion still leaves a lot of options open…. So I contact the user and he informed me that he was trying to qualify a suspect.

So “what does the qualification of a suspect have to do with a contact?”, I hear you think. Well, if you qualify a suspect, it automatically creates 3 records: an account, a contact and an opportunity for that suspect.

Furthermore, if we check the role of the user, we see that he has createacces rights, but only for the records he ownes. As he is trying to qualify a suspect of which he is not the owner, he is also not possible to create a contact.

CreateAcces1

So we could ask another user to qualify the suspect, or we could give the user more privileges to be able to qualify it and create a contact.

CreateAcces2

Next example

Lets cut again everything away we don’t need, leaving us only with the essential information:

<Message>SecLib::AccessCheckEx failed. Returned hr = -2147187962, ObjectID: 5dd8ae22-c3c8-e511-810c-3863bb349780, OwnerId: 371d7f67-03ba-e511-8113-3863bb34f748,  OwnerIdType: 8, CallingUser: fd1b738d-eef7-e511-80dd-5065f38b2571. ObjectTypeCode: 5, objectBusinessUnitId: b15e2c8d-bee7-e411-80fb-c4346badb168, AccessRights: DeleteAccess </Message>

So what does it all mean?

  • ObjectID: this is the ID of the record that is creating the error message.
  • OwnerId: this is is the ID of the owner of the record
  • OwnerIdType: 8: this means the owner is an user. Yes, a team can  also be owner of a record.
  • CallingUser: this is the ID of the user who is doing the action which resulted in the exception
  • ObjectTypeCode: 5: you can check online to see to which objectype this relates to. In this case it relates to the annotation entity in Dynamics CRM
  • objectBusinessUnitId: this is the ID of the busines unit in which the record resides
  • AccessRights: DeleteAccess : this is the privilege that the user who is trying to do an action is missing and as a consequence is resulting in the “unhandled exception”-error.

So if we summarize the previous messages with the missing DeleteAccess rights we can get the following conclusion; The user is trying to do an action in which he deletes an annotation.

Wow! this conclusion still leaves a lot of options open…. So I contact the user and he informed me that he was trying to delete a picture that was added in CRM as an annotation by another user.

Furthermore, if we check the role of the user, we see that he has deleteacces rights, but only for the records he ownes. And as another user added the annotation, he doesn’t have enough rights to delete it.

DeleteAcces1

Change the privilege from the user to also be able to delete annotations within the business unit and voila, the problem is solved! Another workaround would be to assign the annotation first to the user and then he’s able to delete it. Last workaround would be to let another user delete it.

DeleteAcces2

So, there you have it, 2 possible examples of UnhandledExeptions in Dynamics CRM and how you can interpret them. Finally, we also took a look at how you can solve the issue at hand.

4 Comments

  1. Pingback: Hosk’s Top CRM Articles of the week – 27th June – Hosk's Dynamic CRM Blog

  2. Pingback: Unhandled Exception: An easy guide to interpret Dynamics CRM error messages. – Part 2 – Koen's CRM Blog

Leave a Reply

Your email address will not be published. Required fields are marked *