BlueByte
0xc000007bFixed

Windows: The application was unable to start correctly (0xc000007b)

작성 Haneul Seo2026년 9월 14일 업데이트9 min

안녕하세요, BlueByte입니다. 앱을 더블클릭하면 Windows가 The application was unable to start correctly (0xc000007b) 제목의 창과 OK 버튼 하나만 띄우고, 누르면 그냥 닫힙니다. 아무것도 실행되지 않죠. 코드는 알쏭달쏭해 보이지만 Windows는 정확히 말하고 있습니다. 0xc000007b는 NTSTATUS 값 STATUS_INVALID_IMAGE_FORMAT이고, Microsoft는 이를 {Bad Image} ... is either not designed to run on Windows or it contains an error로 문서화합니다. 오늘은 이 뜻, 진짜 문제 파일을 찾는 법, 원인별로 실행할 수 있는 명령으로 고치는 법, 그리고 다음 앱에서 안 겪도록 예방하는 법까지 하나씩 짚어보겠습니다.

"unable to start correctly (0xc000007b)"가 실제로 뜻하는 것

이 대화상자는 보통 앱 이름을 담고 있으며, 특정 .dll을 지목하는 별도의 Bad Image 창이 먼저 뜨기도 합니다:

The application was unable to start correctly (0xc000007b).
Click OK to close the application.

내부적으로는 Windows 로더가 실행 파일이나 DLL을 메모리에 매핑하려다 이 프로세스에 대해 이미지 형식이 유효하지 않다고 판단한 것입니다. 실무에서 이는 거의 항상 아키텍처(비트 수) 불일치입니다 — 32비트 프로세스가 64비트 DLL을 불러오려 했거나 그 반대죠. 이미지는 실재하는 파일이며, 단지 이를 불러오는 프로세스에게 형태가 틀렸을 뿐입니다.

대개 비트 수(bitness) 불일치가 원인인 이유

이 "유효하지 않은 이미지" 오류는 몇 가지 구체적 원인에서 나옵니다:

  • 비트 수가 틀린 DLL — 압도적으로 흔합니다: 32비트 앱이 (PATH나 자기 폴더에서) 64비트 DLL 사본을 만나거나, 64비트 앱이 32비트 사본을 만납니다. 로더가 형식을 거부합니다.
  • 누락되거나 오래된 Visual C++ Redistributable — 앱이 MSVC 런타임을 필요로 하는데 아키텍처가 맞는 redist가 없습니다.
  • 손상된 시스템 파일 — 시스템 DLL이 망가져, 멀쩡한 앱이 결국 유효하지 않은 이미지를 불러오게 됩니다.
  • 손상되거나 덜 복사된 앱 설치 — DLL이 복사 중 잘렸습니다.
  • 드물게: 오래된 게임이 기대하는 DirectX나 .NET 구성 요소 누락.

앱이 32비트인지 64비트인지 확인하기

무언가를 바꾸기 전에 문제 파일부터 찾습니다. Bad Image 창이 .dll을 지목했다면 그게 용의자입니다. 아니라면 이벤트 뷰어를 열고 응용 프로그램 로그를 읽으세요:

eventvwr.msc  →  Windows Logs  →  Application

일치하는 Application Error 항목이 오류를 일으킨 모듈 — 이미지가 유효하지 않았던 DLL — 을 지목합니다. 앱 자체의 비트 수는 설치 폴더가 강한 힌트입니다: 32비트 앱은 보통 C:\Program Files (x86), 64비트 앱은 C:\Program Files 아래에 있습니다. 이를 문제 DLL과 대조하세요 — 32비트 앱이 64비트 DLL을 끌어들이는(또는 그 반대) 것이 바로 오류가 지적하는 불일치입니다.

맞는 Visual C++ Redistributable 설치하기

이것이 가장 효과가 큰 해결입니다. 64비트 Windows는 32비트와 64비트 앱을 모두 실행하므로, 두 아키텍처를 다 설치하세요 — 32비트 앱용 x86 redist와 64비트 앱용 x64 redist입니다. Microsoft의 영구 링크는 항상 최신 v14를 가리키며, 이는 Visual Studio 2015부터 2026까지로 빌드한 앱을 포함합니다:

x86: https://aka.ms/vc14/vc_redist.x86.exe
x64: https://aka.ms/vc14/vc_redist.x64.exe

원하면 조용히 설치할 수 있습니다:

.\vc_redist.x64.exe /install /quiet /norestart
.\vc_redist.x86.exe /install /quiet /norestart

Microsoft 문서는 redistributable 아키텍처가 앱의 아키텍처와 일치해야 한다고 분명히 밝히며, 64비트 기기는 흔히 둘 다를 나란히 설치해야 합니다. 재부팅한 뒤 앱을 다시 실행하세요.

SFC와 DISM으로 손상된 시스템 파일 복구하기

시스템 DLL이 문제의 이미지라면 먼저 구성 요소 저장소를, 그다음 파일을 복구합니다. Microsoft의 안내는 빠른 점검에 sfc /scannow, 더 깊은 점검에 DISM /Cleanup-Image를 쓰라는 것입니다. 관리자 권한 명령 프롬프트에서:

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

대략 이런 출력이 나옵니다:

[==========================100.0%==========================]
The restore operation completed successfully.
...
Windows Resource Protection found corrupt files and successfully repaired them.

DISM을 먼저 돌리고 — 이것이 SFC가 정상 파일을 가져오는 저장소를 복구합니다 — 그다음 SFC를 돌리세요. DISM이 소스 파일을 받으려 Windows Update에 닿지 못하면, Microsoft의 Repair a Windows image 안내대로 /Source: 인자를 붙이세요.

앱을 재설치하거나 맞는 비트 수의 DLL로 되돌리기

이벤트 뷰어가 앱과 함께 배포되는 DLL을 지목했다면, 그 사본이 손상됐거나 비트 수가 틀린 것입니다 — 앱을 깨끗이 재설치하세요: 제거하고, 남은 폴더를 지운 뒤, 원본 다운로드나 미디어로 다시 설치합니다. 지목된 DLL이 누군가 C:\Windows\System32나 앱 폴더에 손으로 복사해 둔 공용 DLL이라면, 그 임시 사본을 지워 로더가 올바른 사본으로 돌아가게 하세요.

실행되지 않던 32비트 게임, 처음부터 끝까지

오래된 32비트 게임이 실행 시 0xc000007b를 냈고, xinput1_3.dll을 지목한 Bad Image 창이 먼저 떴습니다. 이벤트 뷰어의 Application Error가 xinput1_3.dll을 오류 모듈로 확인해 주었습니다. 게임 폴더에는 예전의 "missing dll" 팝업을 없애려 누군가 붙여 넣은 그 DLL의 64비트 사본이 있었습니다. 두 Visual C++ redist를 모두 설치해도 변화가 없었고, 게임 폴더의 임시 64비트 xinput1_3.dll을 지우자 게임이 실행됐습니다 — Windows가 올바른 시스템 사본으로 돌아갔기 때문입니다. 근본 원인은 손으로 복사한 DLL로 인한 비트 수 불일치였습니다.

실행되는지 확인하고 재발 막기

앱을 실행해 보고 이벤트 뷰어에 새 Application Error가 없는지 확인해 고침을 검증하세요. 재발을 막으려면: 두 Visual C++ redist를 최신으로 유지하고, missing-dll 팝업을 잠재우려 폴더 사이로 DLL을 손으로 복사하지 말며, 앱은 아무 DLL 다운로드 사이트가 아니라 제작사에서 설치하세요 — 그런 사이트가 비트 수 틀린 파일의 흔한 출처입니다.

0xc0000135·0x80070005와 어떻게 다른가

0xc0000135(STATUS_DLL_NOT_FOUND)는 필요한 DLL이 아예 없다는 뜻으로, 대개 .NET이나 런타임 누락이지 비트 수 불일치가 아닙니다. 0x80070005는 ACCESS_DENIED, 즉 권한 문제이지 이미지 문제가 아닙니다. 0xc000007b는 이미지 형식이 유효하지 않다는 뜻으로, 부재나 권한이 아니라 아키텍처나 손상을 가리킵니다.

관련 질문

정말 x86과 x64 redistributable을 둘 다 설치해야 하나요?

64비트 Windows에서 32비트와 64비트 앱을 모두 실행한다면 그렇습니다. 두 패키지는 나란히 설치되며 각자의 아키텍처를 담당합니다. x64만 설치하면 32비트 앱이 런타임 없이 남아, 이 오류의 흔한 원인이 됩니다.

SFC가 아무것도 못 찾았는데 앱은 여전히 실패합니다.

그렇다면 문제의 이미지는 시스템 파일이 아니라 앱 자체의 DLL이거나 누락된 redist입니다. 앱을 깨끗이 재설치하고, 아키텍처가 맞는 Visual C++ Redistributable이 설치돼 있는지 확인하세요.

Bad Image 창이 특정 .dll을 지목합니다. 그걸로 뭘 해야 하나요?

지목된 그 파일이 유효하지 않은 이미지입니다. 어느 폴더(앱 폴더, System32, 또는 PATH)에 있는지 찾고, 비트 수가 앱과 맞는지 확인하세요. 거기에 있는 비트 수 틀린·손상된 사본이 고칠 대상입니다.

0xc000007b가 바이러스인가요?

그 자체로는 아닙니다 — 악성코드가 아니라 로더 오류입니다. 다만 다운로드 사이트에서 받은 비트 수 틀린 DLL은 악성코드를 품을 수 있으니, 검색 결과가 아니라 제작사에서 파일을 교체하세요.

Windows를 재설치하면 고쳐지나요?

거의 필요 없습니다. redistributable 설치, SFC/DISM 복구, 앱 깨끗한 재설치로 흔한 원인은 해결됩니다. Windows 초기화는 SFC/DISM이 복구 불가능한 이미지를 보고할 때로 미뤄 두세요.

참고 자료

Haneul Seo

Infrastructure engineer · 10+ years running Linux fleets

같은 카테고리 다른 글

Start request repeated too quicklyFixed

systemd: Start request repeated too quickly

systemd는 StartLimitIntervalSec(기본 10초) 안에 StartLimitBurst(기본 5회)보다 많이 시작된 유닛의 시작을 거부하며, Restart=도 이 제한에 포함됩니다. 기본 RestartSec 100ms로는 크래시하는 서비스가 1초도 안 되어 다섯 번을 소진합니다. 저널에서 진짜 크래시를 찾아 고치고, reset-failed를 실행한 뒤, RestartSec로 재시작에 여유를 주세요.

systemd
Too many authentication failuresFixed

SSH: Received disconnect ... Too many authentication failures

agent가 서버가 허용하는 것보다 많은 키를 내밀고 있습니다. sshd가 들여다보는 공개키 하나하나가 MaxAuthTries 시도를 한 번씩 소모하고 — 기본 6회, 하드닝된 호스트에서는 3회인 경우가 많습니다 — 정작 맞는 키는 차례가 오기 전에 연결이 끊깁니다. IdentitiesOnly=yes와 명시적 IdentityFile로 키 하나를 고정하면 시도 횟수가 1로 떨어집니다.

OpenSSH
1722Fixed

Active Directory: 복제가 error 1722(The RPC server is unavailable)로 실패

RPC는 하위 계층이 연결에 실패했을 때 1722(0x6ba, RPC_S_SERVER_UNAVAILABLE)를 보고합니다. 따라서 진짜 원인은 RPC 자신이 아니라 DNS, 차단된 포트, 두 도메인 컨트롤러 중 한쪽의 호스트 설정입니다. repadmin이 어느 파트너가 실패하는지 알려주고, dcdiag /test:dns가 이름 해석을 배제하며, Test-NetConnection과 동적 포트 범위가 방화벽 문제를 가릅니다. 가장 흔한 실수는 TCP 135만 허용하고 49152–65535는 막아 둔 규칙입니다.

Windows Server Active Directory
Windows Server RDSFixed

Windows Server RDS: The remote session was disconnected because there are no Remote Desktop License Servers available to provide a license

120일 RD Licensing 유예 기간이 끝났는데 세션 호스트가 쓸 수 있는 라이선스 서버가 없어 세션을 거부하는 상황입니다. GetGracePeriodDays 의 DaysLeft 가 0 이고 SpecifiedLSList 가 비어 있으면 몇 초 만에 확인됩니다. 해결은 활성화된 라이선스 서버와, 호스트 버전을 감당할 만큼 새 CAL 입니다. 2019 CAL 은 2022 세션 호스트를 서비스하지 못합니다. 여기에 배포 또는 Licensing 정책 설정과 두 서버 사이의 RPC 포트 개방이 따라옵니다.

Windows Server RDS
0x80070035 / Event ID 31017Workaround

Windows 11: NAS 공유 폴더를 열 때 "조직의 보안 정책이 인증되지 않은 게스트 액세스를 차단" (0x80070035)

Windows 10 Enterprise/Education/Pro for Workstations, Windows 11 Pro, Windows Server 2019 이후의 SMB 클라이언트는 기본적으로 게스트 로그온을 거부하고, Windows 11 24H2 Enterprise/Pro/Education 은 게스트 세션이 할 수 없는 SMB 서명까지 요구합니다. 그래서 게스트 접근만 제공하는 NAS 공유는 'block unauthenticated guest access' 대화상자, Error code 0x80070035, 또는 System error 3227320323 으로 실패하고, SmbClient/Security 로그에 Event ID 31017 'Rejected an insecure guest logon' 이 남습니다. Microsoft 가 권하는 해결은 NAS 에 실제 계정을 만들고 펌웨어에서 서명을 지원하게 하는 것입니다. Set-SmbClientConfiguration -EnableInsecureGuestLogons $true(24H2 는 -RequireSecuritySignature $false 까지)는 비상구이며, 그 클라이언트의 서명과 암호화를 포기하는 대가가 있습니다.

Windows (SMB client)
E: Could not get lock /var/lib/dpkg/lock-frontendFixed

Ubuntu/Debian: E: Could not get lock /var/lib/dpkg/lock-frontend — 누가 쥐고 있고 어떻게 기다리는지

다른 패키지 관리자, 대개 부팅 때 persistent systemd 타이머로 발화한 Ubuntu 의 unattended-upgrades 가 여러분의 apt-get 이 도는 동안 dpkg 프런트엔드 락을 쥐고 있는 것입니다. Ubuntu 는 apt 바이너리에만 binary::apt::DPkg::Lock::Timeout "120" 을 실어 두어서 apt-get 은 즉시 포기하고 apt 는 기다립니다. 메시지의 PID 를 읽고, 실행이 끝나게 두거나 apt-get 에 -o DPkg::Lock::Timeout=<초> 를 주고, dpkg --configure -a 는 실제로 중단된 실행 뒤에만 쓰고, 락 파일은 절대 지우지 마세요. 보유자가 종료하면 커널이 푸는 fcntl 락입니다.

APT (Ubuntu/Debian)