Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 4개 있습니다.)

문제 재현 - Managed Debugging Assistant 'DisconnectedContext' has detected a problem in '...'

비주얼 스튜디오로 디버깅 시 다음과 같은 예외가 발생한다면?

Managed Debugging Assistant 'DisconnectedContext' has detected a problem in 'C:\...\ConsoleApplication1\bin\x86\Debug\ConsoleApplication1.exe'.

Additional information: Transition into COM context 0xdd0138 for this RuntimeCallableWrapper failed with the following error: The object invoked has disconnected from its clients. (Exception from HRESULT: 0x80010108 (RPC_E_DISCONNECTED)). This is typically because the COM context 0xdd0138 where this RuntimeCallableWrapper was created has been disconnected or it is busy doing something else and cannot process the context transition. No proxy will be used to service the request on the COM component and calls will be made to the COM component directly. This may cause corruption or data loss. To avoid this problem, please ensure that all COM contexts/apartments/threads stay alive and are available for context transition, until the application is completely done with the RuntimeCallableWrappers that represents COM components that live inside them.


아래의 문서에 따라 원인을 짐작할 수 있습니다.

disconnectedContext MDA
; https://learn.microsoft.com/en-us/dotnet/framework/debug-trace-profile/disconnectedcontext-mda

말 그대로 다음의 원인 때문입니다.

The OLE apartment or context has been shut down when the CLR attempts to transition into it. This is most commonly caused by STA apartments being shut down before all the COM components owned by the apartment were completely released. This can occur as a result of an explicit call from user code on an RCW or while the CLR itself is manipulating the COM component, for example when the CLR is releasing the COM component when the associated RCW has been garbage collected.


문제를 이해하기 위해 간단한 재현 프로그램을 만들어 보면 좋겠는데요. 막상 재현하려니 또 잘 안나는군요. ^^; 그래도 다소 억지스럽게 재현 코드를 쉽게 구성해 볼 수는 있습니다. 우선, ATL COM 프로젝트를 만들어 다음의 메서드만 하나 구현해 줍니다.

STDMETHODIMP CSimpleObject::DoDelay(LONG seconds)
{
    wprintf(L"DoDelay started!");
    Sleep(seconds * 1000);
    wprintf(L"DoDelay ended!");
    return S_OK;
}

그리고 이 COM 객체를 C# 콘솔 프로젝트에서 다음과 같이 사용해 줍니다.

using System.Threading;

namespace ConsoleApplication1
{
    public class Program
    {
        static ATLProject1Lib.SimpleObjectClass _so;

        static void Main(string[] args)
        {
            ApartmentState aptState = ApartmentState.STA;

            Thread t1 = new Thread(threadFunc1);
            t1.ApartmentState = aptState;
            t1.Start();

            Thread.Sleep(2000);

            Thread t2 = new Thread(threadFunc2);
            t2.ApartmentState = aptState;
            t2.Start();

            t1.Join();
            t2.Join();
        }

        private static void threadFunc1()
        {
            _so = new ATLProject1Lib.SimpleObjectClass();
            Thread.Sleep(5000);
        }

        private static void threadFunc2()
        {
            try
            {
                _so.DoDelay(5);
            } catch { }
        }
    }
}

위의 예제가 억지스러운 이유는 COM 객체를 생성한 threadFunc1에 메시지 루프가 없다는 점입니다. 이 때문에 해당 COM 객체를 다른 스레드에서 접근하는 경우 직렬화된 윈도우 메시지를 처리해 주지 않게 되므로 threadFunc2의 _so.DoDelay 호출은 blocking이 걸립니다. (즉, 이런 식으로 쓴다는 것 자체가 말이 안됩니다. 그냥 재현 예제로만 봐주세요.)

결국, ATL COM 객체를 생성했던 STA 스레드가 종료되었지만 t2 스레드에서는 여전히 해당 Apartment에서 생성된 COM 개체를 호출중인 상황이 발생한 것입니다.

이 프로그램을 Visual Studio에서 F5 디버깅을 걸면 "MDA(managed debugging assistant)" 덕분에 "DisconnectedContext" 유형의 상황이 발생했다는 아주 자세한 오류 메시지를 받게 됩니다.

반면, 디버깅을 하지 않으면 try/catch로 인해 예외를 먹는 상황이 됩니다. 혹은 threadFunc2의 try/catch를 하지 않으면 다음과 같은 예외가 발생하는 것을 볼 수 있습니다.

Unhandled Exception: System.Runtime.InteropServices.InvalidComObjectException: COM object that has been separated from its underlying RCW cannot be used. The COM object was released while it was still in use on another thread.
   at System.StubHelpers.StubHelpers.GetCOMIPFromRCW(Object objSrc, IntPtr pCPCMD, IntPtr& ppTarget, Boolean& pfNeedsRelease)
   at ATLProject1Lib.SimpleObjectClass.DoDelay(Int32 seconds)
   at ConsoleApplication1.Program.threadFunc2() in C:\...\ConsoleApplication1\Program.cs:line 37
   at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()

이처럼, MDA(managed debugging assistant)는 Managed/Unmanaged가 섞인 환경에서 CLR 입장으로써는 파악하기 힘든 문제의 원인을 보다 더 자세하게 알려주는 역할을 합니다. 그래서, 때로는 이 예외가 발생한 경우 무시해도 되고, 무시하지 않아야 하는 경우도 있습니다.

가령, 위에서 DoDelay 메서드는 호출 코드까지는 스레드가 수행했음에도 불구하고 그 이후 작업을 전혀 못하고 예외가 발생한 것입니다. 따라서, 여러분의 코드에서 이 작업의 중요도에 대한 경중에 맞게 예외를 해결하든가, 무시하든가 하면 되는 것입니다.

(첨부한 파일은 이 글의 예제 코드를 포함합니다.)




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 2/14/2025]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 181  [182]  183  184  185  186  187  188  189  190  191  192  193  194  195  ...
NoWriterDateCnt.TitleFile(s)
433정성태1/12/200732906Windows: 14. 보호 모드와 필수 무결성 제어(MIC: Mandatory Integrity Control) [3]파일 다운로드1
432정성태1/10/200723979Windows: 13. InitOnceExecuteOnce API 소개 [5]
431정성태1/8/200721568Windows: 12. 비스타는 안전한 윈도우인가? [2]
430정성태1/7/200727520웹: 6. IIS 7 마이그레이션 정리 - Sysnet
427정성태12/30/200618235Team Foundation Server: 14. VS.NET IDE에 통합된 TFS Annotate [1]
425정성태12/29/200622149Windows: 11. Vista IIS 7(Integrated mode)에서의 ASP.NET F5 디버깅 방법
424정성태12/29/200620260기타: 16. 첫걸음 [2]
426정성태12/30/200618642    답변글 기타: 16.1. 예외 발생
420정성태12/27/200623340Windows: 10. Internet Explorer 7.0 호환성 백서 (Word 문서, 1.92MB) [7]파일 다운로드1
419정성태12/25/200625040Windows: 9. VS.NET 2005 원격 디버깅 구성
418정성태12/25/200633118웹: 5. IIS 7에서 클라이언트 측 인증서 사용 시 주의점 [2]
417정성태12/24/200625642Windows: 8. VS.NET 2005에서의 웹 애플리케이션 디버깅 설정
416정성태1/31/200725615오류 유형: 23. MSI 설치 시 로그 파일 생성하는 레지스트리 설정 [3]
415정성태12/31/200629420개발 환경 구성: 20. 인증서 오류 체크 목록
413정성태12/20/200626322VC++: 26. volatile 키워드 [1]파일 다운로드1
412정성태12/17/200630126오류 유형: 22. VS.NET 2005 SP1 설치 도중 오류 [9]
411정성태12/16/200619168오류 유형: 21. TFS SP1 설치 관련 오류 (2) - KB919156 패치 이후 TFS 접근 문제
410정성태12/16/200620507오류 유형: 20. TFS SP1 설치 관련 오류 (1) - KB919156 패치
408정성태12/10/200622688Windows: 7. USB 드라이브 내용 암호화
407정성태12/10/200620294오류 유형: 19. Vista 에서의 VS.NET 2005 로 개발한 어셈블리에 대한 서명 확인 오류
406정성태12/10/200625081Windows: 6. IE 7 검색 공급자 - 영한 사전
403정성태12/6/200632189Windows: 5. Vista 와 웹 인증 등록 서비스의 문제 [5]
402정성태12/11/200623163Windows: 4. Vista 설치 후기 [1]
409정성태12/11/200627178    답변글 Windows: 4.1. Vista 설치 후기 - 두 번째 이야기 [3]
396정성태2/13/200729884오류 유형: 18. "Automatic Updates" 서비스 CPU 100% 점유 현상
393정성태11/8/200619415오류 유형: 17. Unable to start debugging - The binding handle is invalid.
... 181  [182]  183  184  185  186  187  188  189  190  191  192  193  194  195  ...