C/C++ 프로젝트에 /clr 옵션 적용으로 인한 COM 개체 사용 오류
참, 재미있는 현상이 팀원으로부터 보고되었습니다. 소스 코드는 단일 파일에 아래와 같이 아주 간단한 구조의 C/C++ 콘솔 프로젝트였습니다.
#include "stdafx.h"
#include <vector>
#include <iostream>
using namespace std;
int _tmain(int argc, _TCHAR* argv[])
{
... [중간 생략] ...
HRESULT hr = ::CoInitialize(NULL);
IMyObject* pMyObject = NULL;
hr = ::CoCreateInstance(CLSID_MyObject, NULL, CLSCTX_INPROC_SERVER, IID_IMyObject,
(PVOID *)&pMyObject);
tagMyStruct testParam;
hr = pMyObject->CallMethod(&testParam);
CComBSTR bstrError;
pISARRoute->get_ErrorMessage(&bstrError);
... [중간생략] ...
::CoUninitialize();
return 0;
}
위의 코드는 정상동작했습니다. 하지만, 아래와 같이 CLR 지원 옵션 "/clr"을 주기만 하면 프로그램이 "Access violation" 예외를 발생하며 다운되었습니다.
[그림 1: /clr 빌드 옵션]
"/clr" 적용 후, CoCreateInstance는 정상적으로 되었는데, CallMethod 호출의 hr 반환값이 "-2147352568"으로 나왔습니다. 이 값을 "Error Lookup"으로 확인해 보면 "0x80020008: Bad variable type"으로 나옵니다.
그리곤, get_ErrorMessage 메서드 호출에서 아래와 같은 디버그 출력문을 끝으로 프로그램이 종료되었습니다.
First-chance exception at 0x10001d2e in TestCpp.exe: 0xC0000005: Access violation reading location 0xfab8d088.
Windows has triggered a breakpoint in TestCpp.exe.
오호... 이런 신기한 일이!
단지, "/clr" 옵션만 주었을 뿐인데 이렇게 프로그램이 오동작을 해버렸습니다.
경험상, 이렇게 "Bad variable type"이 나오는 경우중의 하나가 바로 "마샬링" 문제였던 것을 상기시켜서 확실히 하기 위해 CoInitialize의 반환값을 확인해 보았습니다.
HRESULT hr = ::CoInitialize(NULL);
// hr == -2147417850
// == 0x80010106
// == Cannot change thread mode after it is set.
그렇군요. 답이 나왔습니다. /clr 적용으로 인해 STA로 초기화되지 못했던 것입니다. 그러고 보니, 일반적인 C# 프로그램은 기본값이 MTA였고, WinForm의 경우에 STA를 적용하기 위해 Main 함수에 "[STAThread]" 특성을 적용하던 것이 생각났습니다.
아하... 그렇다면 C/C++ 콘솔 응용 프로그램 역시 /clr 옵션 때문에 기본값이 MTA로 바뀌었다는 것이고 결국 위와 같은 결과가 발생했다는 것으로 정리가 됩니다.
원칙이 그러하다면... STA로 바꾸는 방법 역시 마찬가지가 아닐까 싶어서 아래와 같이 특성을 적용해 보았습니다.
[System::STAThreadAttribute]
int _tmain(int argc, _TCHAR* argv[])
{
... [중간 생략] ...
}
정말 되네요. ^^;
[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]