web
You’re offline. This is a read only version of the page.
close
Skip to main content

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Microsoft Dynamics CRM (Archived)

Microsoft.Xrm.Tooling Thread safety

(3) ShareShare
ReportReport
Posted on by

Hi all,

First of all, I am a total newbie. I am starting playing with the SDK I already have 3 questions :

1) CrmServiceClient : IDisposable

The sample code from https://community.dynamics.com/crm/b/develop1/archive/2017/03/11/simplified-connection-management-amp-thread-safety-revisited does not call client.Dispose. When I am adding client.Dispose in the final clause of the // For then the app start crashing randomly with exceptions like:

System.ObjectDisposedException occurred
HResult=0x80131622
Message=Cannot access a disposed object.
Object name: 'System.ServiceModel.ChannelFactory`1[Microsoft.Xrm.Sdk.IOrganizationService]'.
Source=System.ServiceModel
StackTrace:
at Microsoft.Xrm.Tooling.Connector.CrmServiceClient.RetrieveMultiple(QueryBase query)
System.NullReferenceException occurred
HResult=0x80004003
Message=Object reference not set to an instance of an object.
Source=Microsoft.Xrm.Tooling.Connector
StackTrace:
at Microsoft.Xrm.Tooling.Connector.CrmServiceClient.RetrieveMultiple(QueryBase query)

Am I suppose to call Dispose on CrmServiceClient ?

2) TLS version

The handshake protocol is 1.0. Is this a limitation of the client ? Who is managing the (tls) session : windows or client ? 

3) Connections

Whatever the number of threads I am running, only 2 connections are opened to my organisation. I guess that I can improve the overall performance by using more connections. Is there perf counters showing the contention on the connection ? Is there a way to allow more connection to be created (same process)?

Thank you for your help and time.

*This post is locked for comments

I have the same question (0)
  • Daniel Wikell Profile Picture
    2,360 on at

    Hi

    I don't know if you got further with the dispose problem of question #1 but we've been struggling with the same thing and ran some extensive tests during the past week to better understand the behaviour of the random disposes.

    What I gather so far is that CrmServiceClient does not work very well in a multi-threaded environment (despite everyone saying that it should be thread safe) if you utilize the built in connection pooling. Dispose problems do not occur if the RequireNewInstance parameter is specified, but one would not want to rely on this as it has a severe performance impact on your app when it has to recreate a new connection all the time.

    Calling dispose on a CrmServiceClient seems to immediately break things for the other running threads causing their connection objects to be disposed as well. I take it the connection pooling feature links the instances of CrmServiceClients a bit too tightly. The same thing happens if you try to dispose the containing OrganizationServiceProxy.
    Result: Don't dispose CrmServiceClient or the OrganizationServiceProxy (also means don't wrap these in a using statement anywhere) if you are running in a multi-threaded environment.

    Alright so we've stopped manually disposing the objects and removed all using-blocks, but we're still seeing random dispose errors. Here's where things get interesting.
    Utilizing the connection pooling from multiple threads seems to work as intended up until the point where one of your calls to the organizationservice fails. As soon as you have one failure, the CrmServiceClient (or one inner part of it) becomes disposed and your other threads will run into a disposed object.
    I've been testing around with trying to recover from this state but there seems to be nothing on the CrmServiceClient object that indicates this error state. Thus, the other threads have no chance of knowing whether or not they still can use their connection object.

    Here's what we've tried so far:

    • Recreating the CrmServiceClient as soon as an error occurs
    • Recreating the CrmServiceClient using RequireNewInstance as soon as an error occurs
    • Use one static CrmServiceClient instance for all threads
    • Each thread maintains a single CrmServiceClient for all calls within the thread
    • Each thread creates a new CrmServiceClient object before each call


    but none of these seems to change anything. The other threads still run into a disposed object after the first call that ends with an exception.

    The only way we've been rid of the dispose problem is by having to use the RequireNewInstance parameter, which sadly hits us with a performance impact of 6 times longer calls.
    From all the testing we now have a small console application that replicates the problem, so next step is that we plan on providing it to Microsoft support and hope for a fix in an upcoming SDK release.

    Tested with SDK versions:
    8.2.0.362
    8.2.0.713

  • ScottDurow Profile Picture
    21 on at

    Just to add to this - you shouldn't dispose CrmServiceClient since it handles it's own connection pool - but you should Dispose of OrganizationServiceContext - since this is a single thread instance.

  • Community Member Profile Picture
    on at
    I have exactly the same issue when using the CrmServiceClient under an MVC webapi, random object disposed exceptions. For now I have switched back to a plain old OrganizationService but I will conduct a little more investigation and post the results back to this thread.
  • Community Member Profile Picture
    on at

    Hello,

    Sorry for the late response.

    I opened a ticket to Microsoft support, here are their responses:

    For the first question, they told me that I do not have to call Dispose on CrmServiceClient... but use 'using' instead !!!

    For the second question, they need to investigate

    For the third question, they told me that Microsoft can raise the number of threads for a limited period of time (I do not understand how this is related to my question).

    Performance:

    Microsoft is happy with a 20 seconds connection time on the first connection and 3 seconds for the followings.

    I told them that I was not satisfied with their responses and I am now waiting for them to get back to me.

    We had more problems with Dynamics last weeks : random security errors, locked account (unable to connect for 6 hours), empty response (no error, no response), unexplained performance issues, ...

    Good luck.

  • Community Member Profile Picture
    on at

    Hello Scott,

    Thank you.

    Don't you think every object implementing IDisposable must be disposable ? CrmServiceClient implements IDisposable, I must be able to call dispose with no side effect.

  • Community Member Profile Picture
    on at

    Hi All,

    We are also facing the same error when using XrmTooling . Did anyone get around to resolving this? 

  • Rodrigo Groener Profile Picture
    20 on at

    Hi all,

    we are seeing the same error with CrmServiceClient in Azure Functions.

    Azure Functions runtime handles scalling with multiple threads on multiple instaces.

    Looking forward to see a fix from Microsoft.

  • Davide Mognaschi Profile Picture
    20 on at

    The new connection string parameter SkipDiscovery=True speeds up the first connection time from 30secs to 4secs, which is useful while RequireNewInstance=True.

    Sadly this parameter seems to break the early bound proxy types resolution and you get serialization exceptions for unknown type being serialized when calling the org service.

    SDK version: 9.0.0.7

  • Drongo Profile Picture
    45 on at

    We are still using OrganizationService because of this bug. It is fast, it doesn't break after errors like CrmServiceClient. Sadly we need to use ...Client.dll from crm 2015 for this, but at least it is working like it should. One day we will need to rewrite source of OrganizationService for new connection, but for this CrmServiceClient looks like realy bad solution.

  • Silver100 Profile Picture
    20 on at

    Hello,

    thanks for your investigation :-)

    After we went through whole hi-load performance testing of our application (WCF service) we have found exactly the same conclusions.

    We get first generic collection error on Retrieve and the object is disposed on CrmServiceClient. Tthen all threads are getting the same error without any chances to recover.

    Have you made some progress on this thread safe issue with tooling dll ?

    Thanks for response.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Introducing the 2026 Season 1 community Super Users

Congratulations to our 2026 Super Stars!

Meet the Microsoft Dynamics 365 Contact Center Champions

We are thrilled to have these Champions in our Community!

Congratulations to the March Top 10 Community Leaders

These are the community rock stars!

Leaderboard > 🔒一 Microsoft Dynamics CRM (Archived)

#1
JS-09031509-0 Profile Picture

JS-09031509-0 3

#2
AS-17030037-0 Profile Picture

AS-17030037-0 2

#2
Mark Eckert Profile Picture

Mark Eckert 2

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans