Windows Update: 설치 중 0x80070005 (E_ACCESSDENIED)

안녕하세요, BlueByte입니다. Windows 업데이트를 설치하면 한참 돌다가 0x80070005로 롤백되고, Windows Update는 문제가 발생했다고만 말합니다. 업데이트가 손상된 게 아닙니다 — 0x80070005는 E_ACCESSDENIED, 그냥 "접근 거부"이며, 서비싱 스택이 접근 권한이 없는 파일·폴더·레지스트리 키를 건드리려다 막힌 것입니다. 오늘은 이 코드가 뜻하는 것, 원인이 되는 권한 공백, CBS.log로 무엇이 거부됐는지 정확히 읽는 법, 원인별 해결, 그리고 예방까지 하나씩 짚어보겠습니다.

0x80070005 (E_ACCESSDENIED)가 알려주는 것

0x80070005는 E_ACCESSDENIED("general access denied error")에 해당하는 Windows HRESULT입니다. Windows Update 중에 이 코드가 나오면 페이로드 다운로드는 정상이었고, 실패는 component-based servicing(CBS) 엔진이 필요한 무언가를 읽거나 쓰지 못한 데 있습니다. CBS.log에는 이렇게 남습니다:

Error   CBS   Failed to create file. [HRESULT = 0x80070005 - E_ACCESSDENIED]
Error   CBS   Failed to internally open package. [HRESULT = 0x80070005 - E_ACCESSDENIED]

이건 잘못된 업데이트가 아니라 이 컴퓨터의 권한 문제입니다. Windows를 다시 설치할 필요는 없습니다 — 서비싱 스택이 닿지 못한 대상을 찾아, 원래 필요한 접근 권한을 되돌려주면 됩니다.

업데이트가 접근을 잃는 지점 — 권한 공백들

Microsoft 안내에 따르면 서비싱 중 0x80070005는 다음 중 하나에서 옵니다:

• TrustedInstaller 서비스 계정이 권한을 잃음 — %windir%\WinSxS(컴포넌트 저장소)나 %windir%\SoftwareDistribution에 대해.
• 레지스트리 하위 키 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing의 권한이 잘못됨.
• 제3자 백신·보안 도구가 CBS가 사용 중인 업데이트 파일·폴더를 잠금.
• SYSTEM 계정이 %windir%에 Full Control이 없음.
• 그룹 정책 설정이나 관리 에이전트가 시스템 디렉터리 쓰기를 제한함.

(%windir%는 Windows 폴더 — 기본값은 C:\Windows입니다.) 다섯 가지 모두 결국 같은 이야기입니다: 업데이트는 시스템 계정으로 실행되는데, 무언가 ACL을 바꿔 그 계정이 꼭 써야 할 곳에 더는 쓰지 못하게 된 것입니다.

무엇을 바꾸기 전에 CBS.log에서 정확한 거부부터 찾기

무작정 권한을 초기화하지 말고 로그부터 읽어 올바른 대상을 고치세요. 서비싱 로그는 %windir%\logs\CBS에 있습니다. 가장 최근 CBS.log를 열어 , error를 검색하고, 실패한 설치의 타임스탬프와 맞춰 보세요. 동시에 읽기 쉬운 Windows Update 로그가 필요하면 관리자 PowerShell에서 만드세요:

Get-WindowsUpdateLog

그 출력에서 0x80070005를 검색합니다. 오류 바로 위 줄이 대개 거부된 파일이나 레지스트리 키를 알려줍니다 — 그게 권한을 되돌려줄 대상입니다.

먼저 컴포넌트 저장소 권한을 초기화하기

가장 흔한 원인은 컴포넌트 저장소의 ACL이 깨진 것이라 여기부터 시작합니다. 관리자 명령 프롬프트에서 상속 권한을 초기화하고 TrustedInstaller가 저장소를 소유하도록 확인하세요:

icacls "%windir%\WinSxS" /reset /t /c /q
icacls "%windir%\SoftwareDistribution" /reset /t /c /q
icacls "%windir%\WinSxS" /setowner "NT SERVICE\TrustedInstaller" /t /c /q

/reset는 기본 상속 ACL을 되돌리고, /t는 하위 트리까지 재귀하며, /c는 오류를 만나도 계속하고, /q는 조용히 진행합니다. 컴퓨터를 재시작하고 업데이트를 다시 시도하세요. 많은 경우 이것만으로 0x80070005가 사라집니다 — 서비싱 스택이 다시 저장소에 쓸 수 있게 되기 때문입니다.

권한만으로 안 되면 업데이트 스택을 다시 세우기

ACL 초기화 후에도 오류가 남으면 업데이트 캐시를 비우고 저장소를 복구합니다. 서비스를 멈추고, 캐시 폴더 두 개를 이름 바꿔 Windows가 다시 만들게 한 뒤, 서비스를 다시 시작하세요:

net stop wuauserv
net stop bits
net stop cryptSvc
ren %windir%\SoftwareDistribution SoftwareDistribution.old
ren %windir%\System32\catroot2 catroot2.old
net start cryptSvc
net start bits
net start wuauserv

이어서 컴포넌트 저장소를 복구하고 시스템 파일을 검사합니다:

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

DISM은 새 컴포넌트 페이로드를 가져오고(기본 소스로 Windows Update를 사용) sfc는 보호된 시스템 파일을 다시 검사합니다. 재시작한 뒤 업데이트를 한 번 더 시도하세요.

실제 사례: 저장소를 붙잡고 있던 백신 필터 드라이버

한 파일 서버가 월간 누적 업데이트를 받지 못합니다 — 매번 0x80070005에서 끝납니다. CBS.log에는 SoftwareDistribution 아래 파일에 대해 Failed to create file ... E_ACCESSDENIED가 보입니다. ACL 초기화가 듣지 않는데, 이는 권한이 아니라 잠금을 가리킵니다. 파일 시스템 필터 드라이버를 나열해 봅니다:

fltmc

목록에 제3자 백신 필터가 나타납니다. 실시간 보호를 잠시 끄고 그 드라이버를 unload합니다:

fltmc unload <DriverName>

다음 업데이트 실행은 깔끔하게 설치됩니다. 보안 도구가 CBS가 교체하려던 업데이트 파일을 열어 붙잡고 있었고, 그 거부는 사실 잠금이 모습을 바꾼 것이었습니다.

업데이트가 설치되고 로그가 깨끗한지 확인하기

설정 ▸ Windows Update에서 다시 시도하세요. 설치됨에 도달하거나(또는 마무리 재시작을 요청하면), 가장 최근 CBS.log를 다시 열어 E_ACCESSDENIED를 검색합니다 — 깔끔한 실행은 새 0x80070005 줄을 남기지 않습니다. 업데이트가 설치됐고 로그에 새 거부가 없다는 두 가지가 맞으면 이상 없음입니다.

0x80070005가 다시 오지 않게 하기

%windir%, WinSxS, 레지스트리 CBS 키의 ACL과 소유권은 기본값 그대로 두세요 — 대부분은 선의로 "시스템을 강화한다"는 스크립트가 SYSTEM이나 TrustedInstaller 접근을 벗겨낸 데서 시작됩니다. 보안 도구가 잠금을 일으켰다면 업데이트 폴더를 예외에 추가해 서비싱 중 붙잡지 않게 하세요. 그리고 시스템 디렉터리 권한을 바꾸는 그룹 정책이 있다면 점검하세요 — 무해해 보이는 정책이 이후 모든 업데이트를 조용히 막을 수 있습니다.

0x80246017·0x80070020과 다른 점

0x80070005는 서비싱 계정이 ACL에 막혀 거부되는 것입니다. 0x80246017(WU_E_DM_UNAUTHORIZED_LOCAL_USER)은 다릅니다 — 거기서는 로그인한 사용자가 업데이트를 내려받을 권한이 없고, 해결은 ACL이 아니라 로컬 관리자로 실행하는 것입니다. 0x80070020(ERROR_SHARING_VIOLATION)은 권한 거부가 아니라 다른 프로세스가 파일을 열어 잠근 것이라, Process Monitor로 추적해 해당 프로세스를 멈춥니다. 로그에 E_ACCESSDENIED가 있으면 권한 공백이니 ACL을 초기화하고, sharing violation이라 하면 잠금을 쫓으세요.