Question Re: Invalid API call made causes ContextSwitchDeadlock error in Visual Studio.N in Technology Q&A

Invalid API call made causes ContextSwitchDeadlock error in Visual Studio.N

Former Member — Tue, 24 Aug 2010 23:13:14 GMT

I have a windows forms application written in Visual Basic (Visual Studio.net). I have been working with a microsoft engineer for over two months now trying to identify the source of a context switch deadlock error that occurs when you run a report on an STA thread. We have traced the problem down to some API calls made by Crystal Reports that prevent COM resources from getting freed when the STA thread terminates.

The short version of the problem is that the registry entry for the COM object (GUID = {cb352f5b-7dbe-446c-a949-df925b6f6068} has an entry that reads: ThreadingModel=Both. When a STA thread creates a COM object with u201CThreadingModel=Bothu201D, it creates the object as STA: see (http://msdn.microsoft.com/en-us/library/ms809971.aspx). However, the Crystal Reports engine goes on to call CoCreateFreeThreadedMarshaler() which should not be called when the thread is STA.

How did the thread get to be STA? If you run a report on a thread that is MTA, then try to view it, then click the export button from the crystal reports viewer control, you get an error stating that you must use an STA thread. So I did. But then I get this other problem.

Since I have spent so much time and resources tracking down this problem I feel I really should follow through and get it corrected. Is there someone at SAP with the knowledge of threading and COM that can handle this problem?

Andy

Re: Invalid API call made causes ContextSwitchDeadlock error in Visual Studio.N

Former Member — Wed, 25 Aug 2010 13:35:08 GMT

What version of .NET

What version of CR?

What Service Packs for CR applied?

Is this happening on your dev box or after you deploy the app?

Ludek

Re: Invalid API call made causes ContextSwitchDeadlock error in Visual Studio.N

former_member11696 — Wed, 25 Aug 2010 13:50:51 GMT

Hi Andy,

From the GUID it would appear you are using CR 2008. - C:\Program Files\Business Objects\BusinessObjects Enterprise 12.0\win32_x86\rptdefmodel.dll

Need more info on which report engine you are using, CrystalDecisions.CrystalReports.Engine or CrystalDecisions.ReportAppServer?

Also, when is this happening? Are you closing and disposing of the report objects?

Thank you

Don

Re: Invalid API call made causes ContextSwitchDeadlock error in Visual Studio.N

Former Member — Wed, 25 Aug 2010 16:20:28 GMT

Hi Ludek. Sorry I didn't include this information... I meant to.

I am using Visual Studio 2008 (version 9.0.30729.1). I am also using Crystal Reports 2008 (version 12.3.0.601). Both have been patched just before I began working on this problem.

My application is a windows form application that uses crviewer.dll to preview reports. The error message occurs on my development box because the Visual Studio debugger will detect this problem. Since the debugger isn't used at runtime, you won't necessarily see the deadlock error. I am not certain how the problem will show up to the end user. One this for sure is I don't want to find out. It has been very difficult to find this problem when I can reproduce it and when I can see that it has occured and it is on my development computer. Can you imagine how hard it will be on some user's computer where you have no access to the machine, not debugger, and no known symptom to know that this is the problem?

Andy

Re: Invalid API call made causes ContextSwitchDeadlock error in Visual Studio.N

Former Member — Wed, 25 Aug 2010 16:32:27 GMT

I am using Visual Studio 2008 (version 9.0.30729.1). I am also using Crystal Reports 2008 (version 12.3.0.601). Both have been patched just before I began working on this problem.

My application is a windows form application that uses CrystalDecisions.CrystalReports.Engine

When I have finished with the report document, I do the following

' Close the crystal report document.

If (mcrxReport IsNot Nothing) Then

If mcrxReport.IsLoaded = True Then

mcrxReport.Close()

End If

mcrxReport = Nothing

End If

I have also tried (adding dispose):

' Close the crystal report document.

If (mcrxReport IsNot Nothing) Then

If mcrxReport.IsLoaded = True Then

mcrxReport.Close()

End If

mcrxReport.Dispose()

mcrxReport = Nothing

End If

Both produce the same result (ContextSwitchDeadlock error). The error occurs when I run a 1 report on a separate thread, view the report (also on the same separate thread), close the viewer, then repeat the process with another report.

Andy

Re: Invalid API call made causes ContextSwitchDeadlock error in Visual Studio.N

Former Member — Wed, 25 Aug 2010 18:30:48 GMT

Hello Andy:

I discussed the issue with a number of very senior reps and their advice was to create a phone case for this as the issue will most likely not lend it's self to troubleshooting over these forums. A simple application that demos the issue will be good to have as well.

Before we go into creating a phone case, I will also ping one of the guys in Program Management, ask for his feedback and update this thread.

Another thing to consider I suppose is; why use this approach? Is there another way to achieving similar results? This may sound like I'm trying to weasel out of the issue, but it does need to be understood that once this is reproduced and reported to QA, a typical fix takes 6+ months - if QA accepts it. And I suspect that there is a reason why the registry entry for the COM object(s) is set to ThreadingModel=Both. E.g.; QA may reject the issues as "By design". But that would be up to QA to tell us.

Ludek

Re: Invalid API call made causes ContextSwitchDeadlock error in Visual Studio.N

Former Member — Wed, 25 Aug 2010 18:44:04 GMT

Hi Ludek.

To answer your question: why use this approach, the 'approach' is to generate a report on its own thread. The reason is that the main UI thread must remain responsive to the user at all time, or else Windows will report that the application is 'not responding'. Multi-threaded applications have become the new norm. To use another approach means don't use mutliple threads. Not really an serious option, especially with multi-core processors being the norm with all new computers.

My biggest concern is how to get the needed information from Microsoft to your development person. The detailed tracing and investingating was done by someone at Microsoft with more brains that I have. Anybody in-between those two will just be in the way (i.e. me).

Andy

Re: Invalid API call made causes ContextSwitchDeadlock error in Visual Studio.N

former_member11696 — Thu, 02 Sep 2010 18:05:07 GMT

Hi Andy,

I've been discussing this with the PM group and they agree we should not be setting the Threading model to Both. We've always been STA so it's likely something that was missed.

In any event I'll track it and get our Developers to "fix" the issue either way.

As a temp work around try changing the GUID to STA model as recommended by MS. It won't be supported but may resolve your issues.

Problem_Report: ADAPT01473793

Thank you

Don

Edited by: Don Williams on Sep 2, 2010 12:24 PM

Re: Invalid API call made causes ContextSwitchDeadlock error in Visual Studio.N

former_member11696 — Wed, 08 Sep 2010 20:20:18 GMT

Hi Andy,

This has been discussed within the developer group and they do agree we should not be allow/setting the registry keys to both and they should be set to STA mode.

Here's what Ian had to say:

Background

All COM objects get created in some apartment: an STA (Single-threaded apartment: there can be many) or the MTA (Multi-threaded apartment: there is only one). COM takes care of marshaling calls to COM objects when they live in different apartments. COM assumes you do your own marshaling and thread management if you call MTA objects from within the MTA.

If you create a COM from within the MTA and that COM object indicates that it can live in either an STA or the MTA (i.e., itu2019s marked u2018BOTHu2019), then COM will create the object in the MTA and itu2019s up to the developer to keep things straight.

If you create a COM object from the MTA and that COM object indicates that it can only live in an STA, then COM will create an STA for it and all calls to the objectu2019s methods will be marshaled by COM to/from the STA.

EROM

The EROM u201Csupportsu201D being called from the MTA. u201CBeing careful about threadingu201D means:

1. Make sure developers create EROM objects on the same thread. This is most easily done by creating the object in an STA.

2. If they copy EROM object pointers from one apartment to another, the pointers must be marshaled! As a bonus, you get to use the Win32 API with the longest name: CoMarshalInterThreadInterfaceInStream. Calling that API lets you use the pointer to a COM object that lives in a different apartment if you are moving the pointer yourself. COM sets up the marshaling as a result.

u201CMy understanding that if being called in an MTA application we will work as long as the initialized ReportDocument object stays inside its own threadu201D u2013 yes, this is a result of being created in an STA. If an customer can guarantee that they will always call the ReportDocument on the same thread from within the MTA, then yes, they could skip using the STA. Thatu2019s really playing with fire though.

Cheers

Ian.

Thank you

Don

Re: Invalid API call made causes ContextSwitchDeadlock error in Visual Studio.N

former_member11696 — Tue, 14 Sep 2010 20:38:13 GMT

Hi Andy,

Sorry I should have noticed this before.

YOU CAN NOT use the crviewer.dll as the report viewer in a .NET application. It's our legacy ActiveX viewer and is only now supported in the .NET IDE to view reports you design in the application IDE. It's compliment was the craxdrt.dll ( RDC ) and it's designer craxddrt.dll which is used to design report in the IDE. The craxddrt.dll and viewer have both been deprecated and you are not licensed to distribute either in an application.

Replace the crviewer with the CrystalDecisions.Windows.Form viewer and test again.

If you still have issues then let me know?

Thank you

Don

Re: Invalid API call made causes ContextSwitchDeadlock error in Visual Studio.N

Former Member — Wed, 15 Sep 2010 02:13:56 GMT

Hi Don.

I just checked and I am using CrystalDecisions.Windows.Form.CrystalReportViewer to preview reports on the screen. I mispoke (OK, I lied) in my original post. Sorry about that that.

Andy

Re: Invalid API call made causes ContextSwitchDeadlock error in Visual Studio.N

Former Member — Wed, 15 Sep 2010 02:18:14 GMT

The technical support person I am working with at Microsoft now thinks this may be a bug in the CLR. Here is what he said:

I have come to the conclusion that this is a bug with .NET CLR. When Finalizer cleans it up, it should be treating it as MTA as the thread exiting code does.

There is the KB that discusses ThreadingModel=Both:

http://support.microsoft.com/kb/150777

u201CBecause a ThreadingModel "Both" object is also designed for MTA access (it is totally thread-safe internally), it can speed performance by aggregating with the marshaler provided by CoCreateFreeThreadedMarshaler. This system-supplied object is aggregated in to any calling objects and custom marshals direct pointers to the object into all apartments in the process. Clients in any apartment, whether an STA or MTA, may then access the object directly instead of through a proxy. For example, an STA model client creates the in-proc object in STA1 and marshals the object to STA2. If the object does not aggregate with the free-threaded marshaler, STA2 gains access to the object through a proxy. If it does, the free-threaded marshaler provides STA2 with a direct pointer to the object.u201D

As a COM object with ThreadingModel=Both does not know which apartment (STA or MTA) it will belong to at runtime, it needs to be written as a MTA object.

As it is designed as MTA, CoCreateFreeThreadedMarshaler() is necessary to avoid overheads when a STA thread accesses it.

I will go ahead and file a bug, but I donu2019t think it will be addressed in the near future.

I do have a workaround. Here it is:

' Previews the report using a new thread (asynchronously) 
    Public Sub PreviewReportAsynch(ByVal sourceDatabase As clsMainApplicationDatabase)

        Dim staThread As System.Threading.Thread

        ' Start the preview report function on a new thread. This must be done on an STA thread so we will
        ' start another of that type.  See description of PreviewReportAsynchStart() 
        staThread = New System.Threading.Thread(AddressOf PreviewReportAsynchStart)
        staThread.Name = mName
        staThread.SetApartmentState(System.Threading.ApartmentState.STA) ' do not use System.Threading.ApartmentState.MTA
        staThread.Start(sourceDatabase)

    End Sub

    ' The preview form must be launched on a thread that use the single-threaded apartment (STA) model.
    ' Threads use the multi-threaded apartment (MTA) model by default.  This is necessary to make the
    ' export and print buttons on the preview form work.  They do not work when running on a 
    ' thread using MTA.
    Private Sub PreviewReportAsynchStart(ByVal sourceDatabase As Object)

        ' Call the normal preview function.  The only reason this stub exists 
        ' is to cast the sourceDatabase as the correct type.
        Call PreviewReport(DirectCast(sourceDatabase, clsMainApplicationDatabase))

        ' Before we end this thread, make sure all COM objects have been garbage collected and
        ' finalized.  If we don't do this, a ContextSwitchDeadlock error will occur.
        GC.Collect()
        GC.WaitForPendingFinalizers()
        GC.Collect()

    End Sub

    ' Previews the report.  From the preview window, the user can print it.
    Public Function PreviewReport(ByVal sourceDatabase As clsMainApplicationDatabase) As FunctionEndedResult

        Dim errorBoxTitle As String
        Dim frmPreview As frmReportPreview

        ' Setup error handling
        errorBoxTitle = "Preview " & Name & " Report"
        PreviewReport = FunctionEndedResult.FAILURE
        On Error GoTo PreviewError

        ' Initialize report preview.
        If InitializeReportProcess(sourceDatabase) <> FunctionEndedResult.SUCCESS Then
            GoTo PreviewExit
        End If

        ' Use the preview form to preview the report
        frmPreview = New frmReportPreview
        frmPreview.Report = mcrxReport
        frmPreview.ShowDialog()

        ' Save any settings that should persist from one run to the next
        Call SavePersistentSettings()

        ' If we got this far everything is OK.
        PreviewReport = FunctionEndedResult.SUCCESS

PreviewExit:

        ' Do any cleanup work
        Call CleanupReportProcess(sourceDatabase)

        Exit Function

PreviewError:

        ' Report error then exit gracefully
        ErrorBox(errorBoxTitle)
        Resume PreviewExit

    End Function

Edited by: andrew pelkey on Sep 14, 2010 9:18 PM

Re: Invalid API call made causes ContextSwitchDeadlock error in Visual Studio.N

former_member11696 — Sun, 19 Sep 2010 16:48:15 GMT

Thank you for posting your solution. I've closed the Adapt and marked it as not a CR issue.

According to our Develoeprs we are setting the threading model correctly, you just really have to be careful when using the MTA and STA models.