COM 컴포넌트나 OCX / ActiveX 개발에서 빠지기 쉬운 것 - Visual Studio의 32bit / 64bit, 등록, 관리자 권한의 덫을 정리

COM 컴포넌트나 OCX / ActiveX의 안건은 코드 그 자체보다 실행 환경·등록·호스트·권한의 경계에서 빠지기 쉽습니다.

흔한 증상은 이런 것들입니다.

• 빌드는 통과하는데 기동하면 0x80040154.
• 자기 개발기에서는 동작하는데 다른 PC에서는 동작하지 않는다.
• 실행 시에는 동작하는데 Visual Studio의 Designer만 죽는다.
• 관리자로 기동하면 동작하는데 일반 권한에서는 망가진다.
• regsvr32를 두드리고 있는데 왜인지 고쳐지지 않는다.

이쯤은 개별 버그라기보다 COM의 전제가 어딘가에서 맞물리지 않은 상태입니다.

COM / ActiveX / OCX의 말 자체를 먼저 정리하고 싶다면, 우선 COM / ActiveX / OCX란 무엇인가 - 차이와 관계를 모아서 해설을 읽으면 전체상을 잡기 쉽습니다.
이 글에서는 그 다음 단계로서 실제로 어디서 막히기 쉬운가를 Visual Studio의 비트 수나 관리자 권한 주변까지 포함해 정리합니다.

1. 먼저 결론

먼저 실무에서 효과가 있는 표현으로 하면 이렇습니다.

1. COM / OCX / ActiveX의 트러블은 코드의 로직보다 bitness(32bit / 64bit)·등록 대상·호스트·권한의 불일치에서 일어나는 경우가 많습니다.
2. Visual Studio 2022는 64bit 프로세스이므로, 옛날에는 통했던 32bit 전제의 설계 시 연계가 그대로는 망가집니다.¹²
3. regsvr32는 뭐든지 등록하는 마법의 커맨드가 아닙니다. 네이티브의 in-proc COM 서버(DLL / OCX)용입니다. .NET Framework를 COM 공개한다면 Regasm.exe, .NET 5+ / .NET 6+ / .NET 8+에서는 생성된 .comhost.dll을 등록하는 흐름이 됩니다.³⁴⁵⁶
4. 「관리자로 동작하면 OK」는 위험합니다. per-user 등록으로 우연히 보이고 있다, 또는 본래 인스톨러가 할 등록을 개발기에서만 손으로 끝내고 있다는 경우가 꽤 있습니다.³⁷⁸

즉, COM / OCX / ActiveX를 다룰 때는 우선 이 4축으로 보는 것이 안전합니다.

• 어느 프로세스가 호스트하는가
• 그 프로세스는 32bit인가 64bit인가
• 어디에 등록되어 있는가(HKCU / HKLM, 32bit view / 64bit view)
• 그 조작이나 실행에 관리자 권한이 필요한가

2. 증상에서 역추적하면 대체로 이렇게 보인다

0x80040154는 공식으로는 REGDB_E_CLASSNOTREG로 문자 그대로 Class not registered입니다.⁹
또한 regsvr32의 0x80070005는 공식에서도 관리자 권한이 없고 레지스트리나 System32에 쓸 수 없는 케이스로 설명되어 있습니다.¹⁰

여기서 중요한 것은 에러 이름을 그대로 너무 믿지 않는 것입니다.
예를 들어 Class not registered는 「완전히 미등록」이라고는 할 수 없고, 다른 레지스트리 view에 등록되어 있다, 그 사용자에게만 보이는 장소에 등록되어 있다는 것만으로도 일어납니다.¹¹⁷

3. Visual Studio의 비트 수로 빠진다

3.1. Visual Studio 2022는 64bit가 됐다

여기는 지금의 COM / ActiveX 개발에서 가장 빠지기 쉬운 점입니다.

Visual Studio 2022는 devenv.exe가 64bit only입니다.¹
그래서 WinForms의 설계 시 체험에서는 Visual Studio 측이 32bit 컴포넌트를 직접 로드할 수 없습니다. Microsoft도 Visual Studio 2022는 64bit 프로세스이므로 32bit의 .NET / COM / ActiveX 컴포넌트를 로드할 수 없다고 명기하고 있습니다.²

즉 옛날은 이랬던 것이,

• 프로젝트는 x86
• 참조 대상의 ActiveX도 x86
• Visual Studio 자체도 32bit

라는 전제로 그럭저럭 성립했었는데, VS2022에서는

• 실행 시의 앱은 x86으로 동작할 수 있다
• 하지만 Designer는 64bit의 Visual Studio 측에서 동작한다

는 꼬임이 일어납니다.
그 결과 실행 시에는 살아 있는데 Designer만 떨어지는 꽤 불쾌한 상태가 됩니다.²

3.2. AnyCPU로 했다고 해결된다고는 할 수 없다

이것도 흔한 오해입니다.

AnyCPU는 의존 대상까지 중립이 되는 마법이 아닙니다.
Microsoft의 설명에서도 AnyCPU로 보이는 컴포넌트여도, 그 앞에서 32bit 고정의 COM / ActiveX를 참조하고 있다면 Visual Studio 2022의 설계 시에는 문제가 된다고 되어 있습니다.²

그래서 AnyCPU로 해도 에러가 사라지지 않을 때는,

• 그 어셈블리의 앞에 32bit 네이티브 의존이 없는가
• ActiveX / OCX가 x86 고정이 아닌가
• Designer 시에만 로드되는 코드가 없는가

를 의심하는 편이 빠릅니다.

3.3. System32와 SysWOW64의 덫

Windows x64에서는 이름의 인상과 실태가 어긋나 있으므로 혼란스럽기 쉽습니다.

Microsoft Learn에서는 x64 Windows 상의 %windir%\System32는 64bit 애플리케이션용으로 설명되어 있습니다. 32bit 측은 WOW64의 파일시스템 리다이렉터에 의해 다른 장소로 유도됩니다.¹²
레지스트리도 마찬가지로, WOW64의 레지스트리 리다이렉터가 32bit / 64bit에 다른 논리 view를 보입니다.¹¹

그래서 손으로 구분할 때는 어느 비트 수의 regsvr32를 쓰고 있는가를 명시하는 편이 안전합니다.

# 64bit DLL / OCX를 등록하고 싶은 경우
C:\Windows\System32\regsvr32.exe vendor.ocx

# x64 Windows 상에서 32bit DLL / OCX를 등록하고 싶은 경우
C:\Windows\SysWOW64\regsvr32.exe vendor.ocx

이 덫의 짜증나는 점은 잘못된 쪽에 등록하면 등록한 셈인데 목적 프로세스에서 보이지 않는 점입니다.
결과적으로,

• regsvr32는 성공했다
• 하지만 앱에서는 0x80040154
• 레지스트리를 보면 있는 것처럼 보인다
• 하지만 보고 있는 것은 다른 view

라는 상태가 됩니다.¹¹¹³

3.4. regsvr32로 뭐든지 등록할 수 있는 것은 아니다

여기도 꽤 오해되기 쉽습니다.

네이티브의 in-proc COM 서버는 통상 DllRegisterServer / DllUnregisterServer를 익스포트해 자기 등록을 서포트합니다.³
regsvr32는 그런 DLL / OCX에 대해 쓰는 도구입니다.⁴

한편으로 .NET Framework의 어셈블리를 COM에서 쓰고 싶은 경우는 기본은 Regasm.exe입니다. Microsoft Learn에서도 COM에서 사용할 어셈블리의 등록에는 Regasm.exe를 쓴다고 설명되어 있습니다.⁵¹⁴

또한 .NET 5+ / .NET 6+ / .NET 8+의 COM 공개에서는 조금 사정이 바뀌며, <EnableComHosting>true</EnableComHosting>을 설정해 빌드하면 *.comhost.dll이 생성되고 그것을 regsvr32로 등록합니다.⁶

즉 대략 나누면 이렇습니다.

이 차이를 섞으면 흔한 것이,

• 매니지드 DLL에 regsvr32를 건다
• 당연히 DllRegisterServer가 찾아지지 않는다
• 그래서 「DLL이 망가져 있다」고 오해한다

는 패턴입니다.

타입 라이브러리가 필요한 세계(VBA / VB6 / 일부의 조기 바인딩 상대)에서는, 더욱이 TLB의 생성과 등록도 별개 문제가 됩니다. .NET Framework에서는 Regasm.exe /tlb로 타입 라이브러리를 생성·등록할 수 있고, Microsoft도 「형의 등록」과 「타입 라이브러리의 등록」은 별도 활동이라고 설명하고 있습니다.¹⁵

4. 관리자 권한으로 빠진다

4.1. post-build에서 등록하고 있어 관리자에서만 성공한다

Visual Studio의 C++ 빌드에서는 build event나 custom build step에서 regsvr32.exe를 호출하는 것 자체는 평범하게 할 수 있습니다. Microsoft Learn에서도 post-build event의 예로 regsvr32.exe에 의한 등록이 들어져 있습니다.¹⁶

다만 할 수 있는 것과 안전한 것은 별개입니다.

표준 사용자로 regsvr32를 실행하면 레지스트리나 System32에 쓸 수 없어 0x80070005가 될 수 있습니다. Microsoft의 KB에서도 그 원인은 관리자 권한이 없는 것이라고 정리되어 있습니다.¹⁰

여기서 일어나기 쉬운 것은,

• Visual Studio를 통상 권한으로 기동하면 build는 통과
• 하지만 post-build의 등록만 실패
• 실패 로그를 놓친다
• 직전의 오래된 등록이 남아 있으므로 손 근처에서는 우연히 동작
• 클린 환경에서는 당연히 동작하지 않는다

는 사고입니다.

이런 프로젝트에서는 빌드와 등록을 나누는 것이 기본입니다.

• 빌드는 바이너리를 만들 뿐
• 등록은 명시적인 install step / script / installer로 수행
• CI에서는 「등록을 요하는 step」을 build와 별도 잡으로 한다

이 분리만으로도 꽤 사고가 줄어듭니다.

4.2. per-user 등록과 per-machine 등록을 섞으면 망가진다

COM은 HKCR을 본다는 암기 방식만으로는 여기서 막힙니다.

실제로는 Microsoft Learn에 있는 대로 COM은 HKEY_CURRENT_USER\Software\Classes를 먼저 보고, 그 후에 컴퓨터 전체의 정보를 다룹니다.³
또한 HKEY_CLASSES_ROOT는 HKLM\Software\Classes와 HKCU\Software\Classes의 merged view입니다.⁷¹⁷

즉,

• 개발자 A의 사용자로 수동 등록했다
• A의 계정에서는 동작한다
• 개발자 B에서는 동작하지 않는다
• 서비스 계정에서도 동작하지 않는다
• 관리자로 동작시키면 동작이 바뀐다

는 것이 평범하게 일어납니다.

또한 Microsoft는 관리자 권한을 필요로 하는 애플리케이션은 의존 COM 객체를 인스톨 시에 per-machine의 COM 구성 스토어에 등록해야 한다고 하고 있습니다.⁸⁷

그래서 개발 현장에서는 다음 구별을 분명히 해야 합니다.

• 자기 사용자만으로 쓰는 개발용 등록인가
• 그 머신의 전 사용자로 쓰는 운영 등록인가
• 서비스나 승격 앱이 참조하는 등록인가

이것을 애매하게 두면 「왜 관리자에서만 동작한다」, 「Explorer 확장에서는 동작하는데 서비스에서는 동작하지 않는다」 같은 이야기가 됩니다.

4.3. Visual Studio를 상시 「관리자로 실행」으로 하는 것은 해결이 아니다

필요한 장면이 있는 것은 사실입니다.
다만 Visual Studio를 상시 관리자로 기동해 두면 본래 인스톨러나 등록 스크립트로 해결해야 할 문제를 IDE 측의 승격으로 숨겨 버리는 경우가 있습니다.

또한 Visual Studio 자체도 승격 시에는 per-user extension의 취급이 바뀝니다. Microsoft Learn에서도 Visual Studio를 elevated로 동작시키면 per-user extensions가 무효화된다는 설정이 있다고 설명되어 있습니다.¹⁸

그래서 운용으로서는,

• 평소의 개발은 통상 권한
• 등록이 필요한 step만 명시적으로 승격한 Developer Command Prompt / PowerShell / installer에서 수행
• 「관리자에서만 재현된다」라면 그 전제 자체를 사양으로 정리

쪽이 나중에 곤란해지지 않습니다.

5. ActiveX / OCX 고유로 빠지는 것

5.1. 설계 시 라이선스와 실행 시 라이선스가 별개

OCX / ActiveX에서 수수하게 까다로운 것이 라이선스입니다.

특히 오래된 ActiveX 컨트롤에서는 design-time license와 run-time license가 나뉘어 있는 경우가 있습니다. MFC의 ActiveX 문서에서도 라이선스 파일이나 라이선스 키에 의해 design-time / run-time을 나누는 구조가 설명되어 있습니다.¹⁹²⁰

이 세계에서는,

• 실행 시에는 쓸 수 있다
• 하지만 폼에 붙이려 하면 「라이선스가 없다」
• 개발기 A에서는 붙일 수 있다
• 개발기 B에서는 붙일 수 없다

는 일이 일어납니다.

「이 컴포넌트는 라이선스가 찾아지지 않는다」, 「적절한 라이선스가 없다」라는 에러는 옛날의 ActiveX에서는 드물지 않습니다.²¹

5.2. WinForms에 올린 시점에 이미 래퍼가 들어가 있다

WinForms에서 ActiveX를 쓸 때 Windows Forms는 ActiveX를 그대로 호스트하고 있는 것이 아닙니다.
Microsoft Learn의 Aximp.exe 문서에 있는 대로, ActiveX Control Importer는 COM 타입 라이브러리에서 WinForms용의 래퍼를 생성하고, 그것을 AxHost 기반의 컨트롤로서 다룹니다.²²²³

즉 문제는 1층이 아니라,

1. 원래의 OCX / ActiveX 본체
2. 타입 라이브러리
3. 생성된 interop / wrapper
4. WinForms Designer / runtime

의 복수 층으로 나뉩니다.

그래서,

• 벤더 OCX를 교체했더니 이벤트 시그니처가 바뀌었다
• 참조의 다시 붙이기로 wrapper가 재생성되어 차분이 대량으로 나왔다
• 개발기마다 interop의 생성 결과가 미묘하게 다르다

같은 것이 일어납니다.

Choose Toolbox Items에 표시됐으니까 안심, 이 아닙니다.
Designer가 올릴 수 있는가, 실행 시에 이벤트가 오는가, 배포처에서 wrapper째 성립하는가는 따로따로 보는 편이 안전합니다.

5.3. STA / MTA와 메시지 루프를 가볍게 보면 굳는다

COM은 쓰는 스레드마다 CoInitializeEx로 초기화할 필요가 있습니다. Microsoft Learn에서도 COM을 쓰는 각 스레드는 개별로 CoInitializeEx를 호출할 필요가 있다고 명기되어 있습니다.²⁴

또한 STA(single-threaded apartment)에서는 메시지 루프가 필요합니다.²⁴²⁵

특히 UI 계의 OCX / ActiveX는 STA 전제가 많으므로,

• UI 스레드에서는 동작
• Task.Run이나 ThreadPool에 던지면 굳는다
• 이벤트가 돌아오지 않는다
• 가끔만 재현

이라는 짜증나는 불량이 됩니다.

또한 STA에서는 인터페이스 포인터를 그대로 다른 스레드에 복사해서는 안 된다, 필요하다면 마샬링한다, 는 전제도 있습니다.²⁴²⁵

이런 종류의 불량은 0x80040154만큼 친절하지 않고 굳는다·돌아오지 않는다·가끔 떨어진다로만 보이므로, 레지스트리계 트러블과 같은 정도로 시간을 먹습니다.

6. 현장에서 효과가 있는 구분 순서

실무에서는 처음부터 깊이 추궁하기보다 다음 순서로 자르는 편이 빠릅니다.

6.1. 우선 「어느 프로세스가 몇 bit인가」를 고정한다

처음에 보는 것은 여기입니다.

• 호스트는 무엇인가(Visual Studio Designer / 자체 앱 / Office / Access / Explorer / 브라우저 호환 환경)
• 그 호스트는 32bit인가 64bit인가
• 대상의 DLL / OCX는 32bit인가 64bit인가
• 그것은 in-proc인가 out-of-proc인가

여기가 애매한 채로 레지스트리를 보기 시작하면, 대체로 길을 잃습니다.

6.2. 다음으로 「등록의 종류」를 확인한다

다음으로 봐야 하는 것은 무엇을 무엇으로 등록하는 것이 올바른가입니다.

• 네이티브 DLL / OCX → regsvr32
• .NET Framework COM 공개 → Regasm.exe
• .NET 5+ / 6+ / 8+ COM 공개 → .comhost.dll
• 애초에 self-registration을 갖지 않는 DLL → regsvr32가 아니다

이 분류만으로도 꽤 많은 오폭을 막을 수 있습니다.

6.3. 그 후에 「어디에 등록됐는가」를 본다

보는 장소는 단순한 HKCR로는 부족합니다.

• HKCU\Software\Classes
• HKLM\Software\Classes
• 필요하다면 32bit / 64bit의 registry view
• 대상의 ProgID / CLSID / TypeLib
• InprocServer32 / LocalServer32
• ThreadingModel
• 참조 대상 DLL의 실체 패스

HKCR에는 있다만으로는 불충분하고, 누구로부터, 어느 bitness에서, 어느 view를 보고 있는가까지 갖춰야 비로소 의미가 있습니다.⁷¹¹

6.4. 마지막으로 「권한으로 숨겨져 있지 않은가」를 본다

마지막으로 문제가 정말로 권한인지, 아니면 권한에 의해 다른 등록이 보이고 있을 뿐인가를 확인합니다.

• 표준 사용자 / 관리자에서 동작이 바뀌는가
• Visual Studio를 승격하면 무엇이 바뀌는가
• 서비스 계정이나 다른 사용자에서도 재현하는가
• 인스톨러를 통한 클린 환경에서도 성립하는가

개발기 1대에서만 보고 있으면 여기는 정말 잘못 봅니다.

7. 먼저 정해 두면 사고가 줄어드는 운영

COM / ActiveX / OCX의 개발이나 보수에서는 구현 테크닉보다 운영의 결정 방식 쪽이 효과가 있는 경우가 있습니다.

7.1. 먼저 bitness 방침을 정한다

처음에 이것을 정합니다.

• x86 고정으로 갈 것인가
• x64를 정으로 할 것인가
• 양대응할 것인가
• 그 부품은 in-proc가 아니면 안 되는가

특히 벤더 OCX가 x86 고정이라면, 거기를 무시하고 앱만 x64화해도 나중에 막힙니다.
이 주제는 더 큰 구성의 이야기로서 32bit 앱에서 64bit DLL을 호출하는 방법 - COM 브리지가 도움이 되는 케이스 스터디도 관련합니다.

7.2. 등록 전략을 정한다

등록도 임기응변으로 하지 않는 편이 좋습니다.

• 머신 전체에서 쓴다 → installer로 per-machine 등록
• 그 사용자만으로 쓴다 → per-user를 의도적으로 쓴다
• 자기 앱만으로 닫는다 → registration-free COM을 검토
• 개발용으로만 필요 → 명시적인 dev setup script에 가둔다

registration-free COM은 레지스트리가 아니라 manifest로 액티브화 정보를 가질 수 있으므로, 등록 지옥을 줄이는 수단으로서 유효합니다. Win32 측의 registration-free COM도 .NET 측의 RegFree COM도 공식 설명이 있습니다.²⁶⁶²⁷

7.3. 생성물을 source control의 밖에 너무 두지 않는다

OCX / ActiveX 계에서 흔한 것이 의존물의 산일입니다.

• OCX 본체
• 의존 DLL
• TLB
• .lic
• interop DLL
• AxHost wrapper
• 등록 스크립트
• 샘플 호스트

이쯤이 사람의 로컬에만 있으면 몇 달 후에 확실히 사고가 납니다.

최소한,

• 어느 버전을 전제로 하는가
• 무엇을 어느 순서로 넣는가
• 어느 커맨드로 등록하는가
• x86 / x64 중 어느 쪽 용인가

는 코드와 같은 장소에 남기는 편이 안전합니다.

8. 이런 상담은 상성이 좋다

이 주제는 갑자기 전면 개수에 들어가기 전의 구분과 방침 정리만으로도 가치가 나오기 쉽습니다.

예를 들어 다음 같은 상담은 꽤 상성이 좋습니다.

• 0x80040154나 0x80070005의 원인을 bitness / 등록 / 권한으로 나누어 정리하고 싶다
• Visual Studio 2022로 올렸더니 Designer가 망가졌으므로 어디까지 구할 수 있는지 보고 싶다
• 벤더 OCX를 남긴 채 주변을 .NET이나 C#에 치우치고 싶다
• x86 고정 자산을 어디까지 연명하고 어디부터 bridge / wrap / replace할지 정하고 싶다
• 수작업 regsvr32 의존을 그만두고 install / deploy를 재설계하고 싶다

교체한다·감싼다·남긴다의 판단 자체는 ActiveX / OCX를 지금 어떻게 다룰까 - 남긴다·감싼다·교체한다 판단표도 같이 읽으면 정리하기 쉽습니다.

9. 정리

COM 컴포넌트나 OCX / ActiveX 개발에서 빠질 때, 원인은 대체로 다음 4가지입니다.

1. bitness가 맞물려 있지 않다
2. 등록 방법이 틀려 있다
3. 등록 스코프(HKCU / HKLM, 32bit / 64bit view)가 어긋나 있다
4. 권한으로 우연히 보이고 있을 뿐인 상태를 정상이라고 생각하고 있다

Visual Studio 2022의 64bit화로 옛날의 「왠지 동작하고 있었다」는 설계는 꽤 표면화되기 쉬워졌습니다.¹²
그래서야말로 COM / OCX / ActiveX를 건드릴 때는 먼저 코드를 쓰기 전에 환경의 전제를 맞추는 것이 지름길입니다.

regsvr32를 몇 번 두드리는가보다,

• 어느 프로세스가 호스트하고 있는가
• 그 프로세스는 몇 bit인가
• 어디에 등록해야 하는가
• 그 등록은 정말로 관리자 전제인가
• Designer와 runtime을 나누어 보고 있는가

를 정리하는 편이 훨씬 빠르게 풀립니다.

참고

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.