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

비밀번호

댓글 작성자
 




1  2  3  [4]  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13879정성태2/5/20255266오류 유형: 946. Ubuntu - N: Updating from such a repository can't be done securely, and is therefore disabled by default.
13878정성태2/3/20255243오류 유형: 945. Windows - 최대 절전 모드 시 DRIVER_POWER_STATE_FAILURE 발생 (pacer.sys)
13877정성태1/25/20254481닷넷: 2315. C# - PCI 장치 열거 (레지스트리, SetupAPI)파일 다운로드1
13876정성태1/25/20255522닷넷: 2314. C# - ProcessStartInfo 타입의 Arguments와 ArgumentList파일 다운로드1
13875정성태1/24/20254100스크립트: 69. 파이썬 - multiprocessing 패키지의 spawn 모드로 동작하는 uvicorn의 workers
13874정성태1/24/20255318스크립트: 68. 파이썬 - multiprocessing Pool의 기본 프로세스 시작 모드(spawn, fork)
13873정성태1/23/20253939디버깅 기술: 217. WinDbg - PCI 장치 열거파일 다운로드1
13872정성태1/23/20253555오류 유형: 944. WinDbg - 원격 커널 디버깅이 연결은 되지만 Break (Ctrl + Break) 키를 눌러도 멈추지 않는 현상
13871정성태1/22/20254050Windows: 278. Windows - 윈도우를 다른 모니터 화면으로 이동시키는 단축키 (Window + Shift + 화살표)
13870정성태1/18/20254924개발 환경 구성: 741. WinDbg - 네트워크 커널 디버깅이 가능한 NIC 카드 지원 확대
13869정성태1/18/20254256개발 환경 구성: 740. WinDbg - _NT_SYMBOL_PATH 환경 변수에 설정한 경로로 심벌 파일을 다운로드하지 않는 경우
13868정성태1/17/20253884Windows: 277. Hyper-V - Windows 11 VM의 Enhanced Session 모드로 로그인을 할 수 없는 문제
13867정성태1/17/20255395오류 유형: 943. Hyper-V에 Windows 11 설치 시 "This PC doesn't currently meet Windows 11 system requirements" 오류
13866정성태1/16/20255605개발 환경 구성: 739. Windows 10부터 바뀐 device driver 서명 방법
13865정성태1/15/20255167오류 유형: 942. C# - .NET Framework 4.5.2 이하의 버전에서 HttpWebRequest로 https 호출 시 "System.Net.WebException" 예외 발생
13864정성태1/15/20255158Linux: 114. eBPF를 위해 필요한 SELinux 보안 정책
13863정성태1/14/20254066Linux: 113. Linux - 프로세스를 위한 전용 SELinux 보안 문맥 지정
13862정성태1/13/20254581Linux: 112. Linux - 데몬을 위한 SELinux 보안 정책 설정
13861정성태1/11/20254681Windows: 276. 명령행에서 원격 서비스를 동기/비동기로 시작/중지
13860정성태1/10/20254349디버깅 기술: 216. WinDbg - 2가지 유형의 식 평가 방법(MASM, C++)
13859정성태1/9/20255123디버깅 기술: 215. Windbg - syscall 이후 실행되는 KiSystemCall64 함수 및 SSDT 디버깅
13858정성태1/8/20255118개발 환경 구성: 738. PowerShell - 원격 호출 시 "powershell.exe"가 아닌 "pwsh.exe" 환경으로 명령어를 실행하는 방법
13857정성태1/7/20255401C/C++: 187. Golang - 콘솔 응용 프로그램을 Linux 데몬 서비스를 지원하도록 변경파일 다운로드1
13856정성태1/6/20254312디버깅 기술: 214. Windbg - syscall 단계까지의 Win32 API 호출 (예: Sleep)
13855정성태12/28/20245958오류 유형: 941. Golang - os.StartProcess() 사용 시 오류 정리
13854정성태12/27/20245848C/C++: 186. Golang - 콘솔 응용 프로그램을 NT 서비스를 지원하도록 변경파일 다운로드1
1  2  3  [4]  5  6  7  8  9  10  11  12  13  14  15  ...