업데이트 기록 화면에 "설치 오류 - 0x80070643" 이 빨갛게 남아 있으면, 다시 시도를 눌러도 같은 줄이 하나 더 생길 뿐인 경우가 많다. 이번 편을 쓰려고 내 PC 의 업데이트 기록을 9월 1일부터 두 달 넘게 뒤졌는데 0x80070643 은 한 건도 없었다. 대신 실패 기록 아홉 건이 전부 다른 코드였다. 이 차이가 0x80070643 을 이해하는 데 오히려 도움이 됐다.
1603 은 "설치 프로그램이 실패했다"는 말뿐이다
지난 편의 방법대로 쪼개면 0x80070643 은 실패, 영역 7(Win32), 번호 0x643 이다. 0x643 은 10진수로 1603, 이름은 ERROR_INSTALL_FAILURE 다. certutil -error 0x80070643 도 같은 답을 준다.
0x80070643 (WIN32: 1603 ERROR_INSTALL_FAILURE) -- 2147944003 (-2147023293)
오류 메시지 텍스트: 설치를 하는 동안 오류가 발생했습니다.
1603 은 Windows Installer(MSI)가 "설치 도중 치명적 오류가 나서 되돌렸다"고 할 때 돌려주는 번호다. 파일 복사가 막혔든, 설치 패키지 안의 사용자 지정 동작이 실패했든, 필요한 구성 요소 상태가 이상하든 바깥으로는 모두 1603 하나로 나온다. Windows 업데이트는 설치를 맡긴 쪽이 돌려준 결과를 HRESULT 로 감싸 기록하는 것으로 보여서, 업데이트 화면의 0x80070643 은 "안쪽 설치 프로그램이 실패했다"는 사실 외에는 아무것도 말해 주지 않는다. 진짜 원인은 그 설치 프로그램의 자체 로그에 있다.
직접 실행하는 MSI 라면 자세한 로그를 남기며 다시 설치해 보는 것이 가장 확실하다.
msiexec /i 설치파일.msi /l*v "%TEMP%\install.log"
로그에서 Return value 3 을 찾으면 그 바로 앞에 실패한 동작 이름이 있는 것이 MSI 로그를 읽는 흔한 방법이다. 업데이트를 통해 설치되는 것은 이렇게 직접 로그를 받기 어려워서, 아래처럼 어떤 업데이트였는지부터 보는 쪽이 현실적이다.
유명했던 사례 세 가지
0x80070643 이 검색어로 크게 늘었던 건 2024년 1월, Windows 10 의 복구 환경(WinRE) 업데이트 KB5034441 때였다. BitLocker 우회 취약점을 막는 수정을 복구 파티션 안에 넣는 업데이트였는데, 복구 파티션에 여유 공간이 250MB 정도 필요했고 모자란 PC 에서는 0x80070643 으로 실패했다. Microsoft 는 파티션 크기를 늘리는 수동 절차를 안내했고, 나중에는 원래 디스크 공간 부족(CBS_E_INSUFFICIENT_DISK_SPACE)이 표시되어야 할 상황이 오류 처리 문제로 0x80070643 으로 보였다고 설명한 것으로 알려져 있다. 막연한 1603 이 실제로는 "공간 부족"이었던 셈이다.
Microsoft Defender 의 맬웨어 방지 플랫폼 업데이트(KB4052623)도 0x80070643 으로 실패한다는 보고가 여러 번 있었던 것으로 알려져 있다. 다른 백신이 주 백신으로 설치되어 Defender 구성 요소가 제 상태가 아닐 때 이런 경우가 많다고 한다. .NET Framework 업데이트에서 나오는 0x80070643 은 기존 .NET 설치 상태가 손상된 경우가 흔한 원인으로 꼽히고, Microsoft 가 .NET Framework 복구 도구를 따로 배포하고 있다.
세 경우 모두 업데이트 이름을 보면 방향이 갈린다. 같은 코드라도 복구 환경이면 파티션 공간, Defender 면 백신 구성, .NET 이면 기존 설치 상태를 먼저 본다.
내 PC 업데이트 기록에서 확인한 것
먼저 많이들 쓰는 Get-HotFix 를 돌렸다.
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object HotFixID, Description, InstalledOn
나온 것은 여섯 개뿐이었다. 10월 보안 업데이트(KB5127648)와 .NET Framework 업데이트(KB5127694) 등 10월 13일 날짜 네 개, 그리고 3월과 4월 것 두 개다. 그런데 Windows 업데이트 클라이언트가 시스템 로그에 남기는 설치 성공 이벤트(19번)는 로그가 남아 있던 9월 1일부터만 세어도 452건이었다. Defender 보안 인텔리전스 업데이트만 127건, Defender 플랫폼 업데이트(KB4052623)가 4건, 나머지 대부분은 스토어 앱 갱신이었다. Get-HotFix 는 Windows 구성 요소 서비스로 설치되는 패키지만 보여 주고, Defender·스토어 앱처럼 다른 경로로 설치되는 업데이트는 목록에 없다. 0x80070643 이 자주 나오는 Defender 쪽 업데이트는 Get-HotFix 로는 아예 보이지 않는다는 뜻이다.
날짜도 조금 달랐다. 10월 보안 업데이트는 이벤트 로그상 10월 14일 08:28 에 설치됐는데 Get-HotFix 는 10월 13일로 보여 줬다. 시각 없이 날짜만 남기는 값이라 기준 시간대에 따라 하루가 밀린 것으로 보인다. 9월 보안 업데이트 두 개는 아예 목록에서 빠져 있었는데, 9월 30일 26H2 기능 업데이트 뒤 설치 로그(Setup)에 "Superseded → Absent", 즉 대체되어 정리됐다는 기록이 남아 있었다.
실패 기록은 20번 이벤트다. 코드가 부호 있는 10진수로 저장되어 있어서 16진수로 바꿔 꺼냈다.
Get-WinEvent -LogName System -FilterXPath "*[System[Provider[@Name='Microsoft-Windows-WindowsUpdateClient'] and (EventID=20)]]" |
ForEach-Object { [pscustomobject]@{
Time = $_.TimeCreated; Code = '0x{0:X8}' -f $_.Properties[0].Value; Update = $_.Properties[1].Value } }
아홉 건 모두 0x80073D02 였다. 휴대폰 연결, 스토어 같은 스토어 앱 갱신이었고, 풀면 15618 ERROR_PACKAGES_IN_USE, 앱이 실행 중이라 바꿀 수 없다는 뜻이다. 스토어 앱은 10월 18일에 이 코드로 실패한 뒤 20일에 다시 성공해 있었다. 앱을 닫아 두면 다음 시도에서 풀리는 종류다.
설치 프로그램 쪽도 봤다. 응용 프로그램 로그에 남은 Windows Installer 설치·변경·제거 결과 293건(10월 18일 이후)의 상태 값이 모두 0, 곧 성공이었다. 1603 이 한 번이라도 났다면 여기 상태 값으로 남는다. 복구 파티션은 관리자 권한 없이도 Get-Partition 으로 크기를 볼 수 있었고 949MB 였다. 그 안의 복구 환경 상태를 보는 reagentc /info 는 관리자 권한이 필요해서, 일반 권한에서는 지난 편에서 본 대로 오류 5로 끝났다.
0x80070643 을 만났을 때
순서는 단순하다. 업데이트 기록에서 실패한 항목의 이름을 먼저 본다. 다시 시작한 뒤 한 번 더 시도하고, 그래도 같으면 이름에 따라 갈린다. Defender 업데이트라면 다른 백신이 설치되어 있는지 보고, Windows 보안 앱에서 보호 업데이트를 직접 확인해 본다. Defender 자체의 동작은 MsMpEng 편에 정리해 두었다. .NET Framework 업데이트라면 Microsoft 의 .NET Framework 복구 도구를 Microsoft 사이트에서 받아 돌린다. 복구 환경 업데이트라면 해당 KB 문서의 안내를 먼저 읽는다. 파티션 크기를 바꾸는 절차는 디스크 구조를 건드리는 작업이라, 백업 없이 따라 할 일은 아니다.
시스템 파일 손상이 의심되면 관리자 권한 명령 프롬프트에서 sfc /scannow 와 DISM /Online /Cleanup-Image /RestoreHealth 로 점검할 수 있다. 레지스트리 정리 프로그램은 1603 의 원인을 고쳐 주지 않고, 설치 정보까지 지워 다음 설치를 더 어렵게 만들 수 있어서 권하지 않는다.
연재를 정리하면 다섯 편이 같은 이야기를 했다. 0xc0000022와 0x80070005 는 접근 거부, 0xc000007b와 VCRUNTIME140.dll은 DLL 이 맞지 않거나 없는 경우, 0x80070643 은 설치 프로그램 안쪽의 실패였다. 코드를 쪼개 읽고, 이벤트 로그에서 어디서 막혔는지 찾고, 시스템 폴더 전체가 아니라 그 지점만 손보는 것. 오류 창의 숫자가 막막해 보일 때 이 세 가지면 대부분 방향이 잡힌다.
2시즌에서는 이 PC 의 기록에 실제로 남아 있던 코드부터 이어서 연다. 첫 편은 스토어 앱 업데이트가 걸리던 0x80073D02 (11월 18일 공개) 다.