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

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




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 7/17/2021]

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

비밀번호

댓글 작성자
 




... 46  47  48  49  50  51  52  53  54  55  56  57  58  [59]  60  ...
NoWriterDateCnt.TitleFile(s)
12151정성태2/22/202011631.NET Framework: 896. C# - Win32 API를 Trampoline 기법을 이용해 C# 메서드로 가로채는 방법 - 두 번째 이야기 (원본 함수 호출)파일 다운로드1
12150정성태2/21/202011497.NET Framework: 895. C# - Win32 API를 Trampoline 기법을 이용해 C# 메서드로 가로채는 방법 [1]파일 다운로드1
12149정성태2/20/202011241.NET Framework: 894. eBEST C# XingAPI 래퍼 - 연속 조회 처리 방법 [1]
12148정성태2/19/202012472디버깅 기술: 163. x64 환경에서 구현하는 다양한 Trampoline 기법 [1]
12147정성태2/19/202011082디버깅 기술: 162. x86/x64의 기계어 코드 최대 길이
12146정성태2/18/202011347.NET Framework: 893. eBEST C# XingAPI 래퍼 - 로그인 처리파일 다운로드1
12145정성태2/18/202010577.NET Framework: 892. eBEST C# XingAPI 래퍼 - Sqlite 지원 추가파일 다운로드1
12144정성태2/13/202010546.NET Framework: 891. 실행 시에 메서드 가로채기 - CLR Injection: Runtime Method Replacer 개선 - 두 번째 이야기파일 다운로드1
12143정성태2/13/20208670.NET Framework: 890. 상황별 GetFunctionPointer 반환값 정리 - x64파일 다운로드1
12142정성태2/12/202010405.NET Framework: 889. C# 코드로 접근하는 MethodDesc, MethodTable파일 다운로드1
12141정성태2/10/20209999.NET Framework: 888. C# - ASP.NET Core 웹 응용 프로그램의 출력 가로채기 [2]파일 다운로드1
12140정성태2/10/20209823.NET Framework: 887. C# - ASP.NET 웹 응용 프로그램의 출력 가로채기파일 다운로드1
12139정성태2/9/202011202.NET Framework: 886. C# - Console 응용 프로그램에서 UI 스레드 구현 방법
12138정성태2/9/202013945.NET Framework: 885. C# - 닷넷 응용 프로그램에서 SQLite 사용 [6]파일 다운로드1
12137정성태2/9/20209164오류 유형: 592. [AhnLab] 경고 - 디버거 실행을 탐지했습니다.
12136정성태2/6/20209546Windows: 168. Windows + S(또는 Q)로 뜨는 작업 표시줄의 검색 바가 동작하지 않는 경우
12135정성태2/6/202013173개발 환경 구성: 468. Nuget 패키지의 로컬 보관 폴더를 옮기는 방법 [2]
12134정성태2/5/202013362.NET Framework: 884. eBEST XingAPI의 C# 래퍼 버전 - XingAPINet Nuget 패키지 [5]파일 다운로드1
12133정성태2/5/202010593디버깅 기술: 161. Windbg 환경에서 확인해 본 .NET 메서드 JIT 컴파일 전과 후 - 두 번째 이야기
12132정성태1/28/202012159.NET Framework: 883. C#으로 구현하는 Win32 API 후킹(예: Sleep 호출 가로채기)파일 다운로드1
12131정성태1/27/202012229개발 환경 구성: 467. LocaleEmulator를 이용해 유니코드를 지원하지 않는(한글이 깨지는) 프로그램을 실행하는 방법 [1]
12130정성태1/26/20209699VS.NET IDE: 142. Visual Studio에서 windbg의 "Open Executable..."처럼 EXE를 직접 열어 디버깅을 시작하는 방법
12129정성태1/26/202015289.NET Framework: 882. C# - 키움 Open API+ 사용 시 Registry 등록 없이 KHOpenAPI.ocx 사용하는 방법 [3]
12128정성태1/26/202010080오류 유형: 591. The code execution cannot proceed because mfc100.dll was not found. Reinstalling the program may fix this problem.
12127정성태1/25/20209949.NET Framework: 881. C# DLL에서 제공하는 Win32 export 함수의 내부 동작 방식(VT Fix up Table)파일 다운로드1
12126정성태1/25/202010733.NET Framework: 880. C# - PE 파일로부터 IMAGE_COR20_HEADER 및 VTableFixups 테이블 분석파일 다운로드1
... 46  47  48  49  50  51  52  53  54  55  56  57  58  [59]  60  ...