이 글을 3줄로 요약하면
· 0x800f0831의 정식 이름은 CBS_E_STORE_CORRUPTION입니다. 인터넷이 아니라 구성 요소 저장소 문제입니다.
· 업데이트를 조립하는 데 필요한 이전 패키지의 매니페스트가 없거나 깨졌을 때 나오는 코드입니다.
· 원인은 네 갈래입니다. 판별표에서 자기 증상을 찾아 해당 섹션부터 처리하면 순서가 줄어듭니다.
0x800f0831은 정확히 무슨 뜻인가
이름이 가리키는 위치를 알면, 손대지 않아도 될 곳을 먼저 걸러낼 수 있습니다.
0x800f0831의 내부 코드명은 CBS_E_STORE_CORRUPTION입니다. 여기서 CBS는 구성 요소 기반 서비스(Component Based Servicing), 즉 윈도우가 업데이트를 설치할 때 부품을 조립하는 담당 엔진을 말합니다. 이 코드는 그 엔진이 "조립에 필요한 부품 목록을 찾지 못했다"고 보고한 상태입니다.
Microsoft 문서는 원인을 한 줄로 정리해 둡니다. 지금 설치하려는 업데이트가 이전에 설치된 어떤 패키지의 매니페스트 파일을 필요로 하는데, 그 파일이 없거나 손상됐다는 것입니다. 매니페스트는 "이 패키지에 어떤 파일이 어떤 버전으로 들어 있다"를 적어 둔 설명서에 해당합니다.
누적 업데이트는 이전 상태 위에 차이만 얹는 방식으로 설치됩니다. 그래서 기준이 되는 이전 패키지의 설명서가 사라지면, 다운로드가 100% 끝난 뒤 설치 단계에서 롤백됩니다. 다운로드는 되는데 마지막에 되돌아가는 패턴이 이 코드의 전형적인 모습입니다.
이 구조 때문에 흔히 하는 조치들이 잘 듣지 않습니다. 공유기를 재부팅하거나, 백신을 끄거나, 업데이트를 몇 번 더 눌러 보는 것은 네트워크 계열 오류에 쓰는 방법입니다. 0x800f0831은 파일이 이미 내려온 뒤 내 PC 안에서 나는 오류라 접근 방향이 다릅니다.
비슷해 보이지만 다른 코드와 헷갈리지 않기
0x8024402c·0x80072F8F처럼 연결·인증서 계열 코드는 다운로드 단계에서 멈춥니다. 반면 0x800f0831은 설치 단계에서 롤백됩니다. 업데이트 기록에 어느 단계에서 실패했는지가 남으니 먼저 확인하는 편이 빠릅니다.
증상으로 원인 좁히기
같은 코드라도 실패하는 지점이 다릅니다. 자기 상황과 가장 가까운 줄을 먼저 봅니다.
| 증상 | 유력한 원인 | 먼저 볼 항목 |
|---|---|---|
| 여러 누적 업데이트가 전부 같은 코드로 롤백된다 | 구성 요소 저장소 손상 | 원인 A → DISM 복구 |
| 업데이트뿐 아니라 일부 기능·앱도 함께 오작동한다 | 시스템 파일 손상이 먼저 있다 | 원인 B → sfc 검사 |
| 다운로드 0%에서 멈추거나 같은 파일을 계속 다시 받는다 | 업데이트 캐시 이상 | 원인 C → 캐시 초기화 |
| 다른 업데이트는 되는데 특정 KB 하나만 계속 실패한다 | 그 KB의 선행 패키지 누락 | 원인 D → 카탈로그 수동 설치 |
| .NET Framework 3.5나 언어 팩 같은 선택적 기능 설치에서 뜬다 | 복구 원본을 못 찾는 상태 | 원인 D → 원본 지정 |
| DISM을 돌려도 같은 코드가 그대로 반복된다 | 누락 패키지를 특정해야 하는 단계 | 진단 → CBS.log 확인 |
해당하는 줄이 두 개 이상이면 위쪽 원인부터 처리합니다. 저장소가 깨진 상태에서는 아래 단계들이 모두 같은 지점에서 다시 막히기 때문입니다.
원인 A구성 요소 저장소에 선행 패키지가 없다
코드 이름 그대로의 원인입니다. 여러 업데이트가 동시에 실패한다면 여기부터 봅니다.
구성 요소 저장소는 C:\Windows\WinSxS 폴더입니다. 윈도우가 지금까지 설치한 모든 부품과 그 설명서가 쌓여 있는 곳이라, 여기가 흔들리면 이후 업데이트는 전부 같은 자리에서 멈춥니다.
Microsoft 문서가 이 오류에 제시하는 첫 번째 방법도 DISM으로 저장소를 점검하고 복구하는 것입니다. 순서가 중요합니다. 먼저 검사해서 손상 여부를 확인하고, 그다음 온라인에서 정상 파일을 받아 복구합니다.
1저장소 상태를 먼저 검사한다
시작 버튼을 우클릭해 터미널(관리자)로 연 뒤 입력합니다. "구성 요소 저장소가 복구 가능합니다"가 나오면 아래 3번이 효과를 볼 확률이 높습니다.
2손상 표시가 남아 있는지 확인한다
이 명령은 검사를 새로 하지 않고 이미 기록된 손상 표시만 읽습니다. 그래서 몇 초 만에 끝납니다.
3온라인 원본으로 저장소를 복구한다
10~20분 걸립니다. 20%와 40% 부근에서 오래 멈춘 것처럼 보여도 정상이니 창을 닫지 않습니다. "복원 작업을 완료했습니다"가 성공 신호입니다.
4복구된 저장소를 기준으로 시스템 파일을 맞춘다
DISM이 먼저, sfc가 나중입니다. sfc는 저장소의 정상 파일을 원본으로 삼아 복사하므로, 저장소를 고치기 전에 돌리면 고칠 원본 자체가 없습니다.
네 단계가 끝나면 재부팅하고 업데이트를 다시 시도합니다. 이 지점에서 해결되는 경우가 가장 많습니다.
DISM이 100%에서 끝났다고 다 복구된 것은 아닙니다
진행률이 끝까지 가도 마지막 줄에 오류 0x800f081f가 붙는 경우가 있습니다. 이건 "복구할 원본 파일을 못 구했다"는 뜻이라, 아래 원인 D의 원본 지정 방법으로 넘어가야 합니다.
이 방법이 안 통하는 경우
DISM이 정상 완료됐는데도 같은 코드로 롤백된다면, 저장소 전반이 아니라 특정 패키지 하나가 비어 있는 상태입니다. 7번 진단 섹션에서 CBS.log를 열어 어떤 패키지인지 이름을 확인한 뒤 원인 D로 갑니다.
원인 B시스템 파일 쪽이 먼저 깨져 있다
업데이트 말고 다른 기능도 함께 이상하다면 이쪽을 먼저 정리해야 합니다.
저장소가 아니라 실제로 쓰이는 시스템 파일이 손상된 경우도 같은 코드로 이어집니다. 업데이트는 설치 과정에서 기존 파일을 교체하는데, 교체 대상 파일이 이미 비정상이면 검증 단계에서 멈추기 때문입니다.
1시스템 파일 검사를 끝까지 돌린다
"확인 100% 완료"까지 5~15분 걸립니다. 결과 문구를 그대로 읽는 것이 중요합니다.
| sfc 결과 문구 | 뜻 | 다음 행동 |
|---|---|---|
| 위반 사항을 발견하지 못했습니다 | 시스템 파일은 정상 | 원인 C로 이동 |
| 손상된 파일을 찾았고 복구했습니다 | 복구 성공 | 재부팅 후 업데이트 재시도 |
| 일부를 복구할 수 없습니다 | 저장소 원본도 손상 | 원인 A의 DISM을 먼저 실행 |
세 번째 결과가 나왔다면 sfc를 반복해도 소용이 없습니다. 복사해 올 원본이 없는 상태라 DISM → sfc 순서로 다시 돌아가야 합니다.
이 방법이 안 통하는 경우
sfc가 "위반 사항을 발견하지 못했습니다"로 끝나는데 업데이트만 계속 실패한다면, 시스템 파일은 문제가 아닙니다. 캐시 쪽을 보는 원인 C로 넘어갑니다.
원인 C업데이트 캐시가 잘못된 상태로 남아 있다
같은 파일을 계속 다시 받거나 진행률이 초반에서 되돌아갈 때 해당합니다.
윈도우는 받은 업데이트 파일을 C:\Windows\SoftwareDistribution에 임시로 쌓고, 서명 검증에 쓰는 정보는 C:\Windows\System32\catroot2에 둡니다. 두 폴더 중 하나가 어중간하게 남으면 새 시도도 그 파일을 재사용하다 같은 지점에서 실패합니다.
1먼저 내장 문제 해결사를 돌린다
설정 → 시스템 → 문제 해결 → 기타 문제 해결사에서 Windows Update 항목의 실행을 누릅니다. 서비스 상태와 권한 정도의 가벼운 문제는 여기서 정리됩니다. 실행 창(Win + R)에 ms-settings:troubleshoot을 넣으면 바로 이동합니다.
2관련 서비스를 잠시 멈춘다
net stop cryptSvc
net stop bits
net stop msiserver
터미널(관리자)에서 한 줄씩 실행합니다. 폴더가 사용 중이면 이름을 바꿀 수 없어 이 단계가 필요합니다.
3캐시 폴더 두 개의 이름을 바꾼다
ren C:\Windows\System32\catroot2 catroot2.old
지우지 않고 이름만 바꿉니다. 문제가 없으면 나중에 .old 폴더를 삭제하면 되고, 이상이 생기면 되돌릴 수 있습니다.
4서비스를 다시 켜고 재부팅한다
net start cryptSvc
net start bits
net start msiserver
재부팅 후 업데이트를 다시 확인하면 파일을 처음부터 새로 받습니다. 첫 확인이 평소보다 오래 걸리는 것은 정상입니다.
개인 파일과는 무관한 폴더입니다
SoftwareDistribution과 catroot2는 업데이트 작업용 임시 폴더입니다. 문서·사진·설치된 프로그램과는 관계가 없고, 다음 업데이트 때 윈도우가 알아서 다시 만듭니다.
이 방법이 안 통하는 경우
캐시를 비운 뒤에도 같은 KB에서만 같은 코드가 반복된다면 캐시 문제가 아니라 그 업데이트의 선행 패키지가 빠진 상태입니다. 원인 D로 넘어갑니다. 서비스 중지 명령에서 "액세스가 거부되었습니다"가 나오면 창이 관리자 권한이 아닌 것이니 창부터 다시 엽니다.
원인 D특정 KB·선택적 기능에서만 실패한다
다른 업데이트는 잘 되는데 하나만 계속 실패하는 유형입니다.
이 경우는 저장소 전체가 아니라 그 업데이트가 기준으로 삼는 패키지 하나가 없는 상태입니다. Microsoft 문서도 DISM 복구가 통하지 않을 때의 방법으로 업데이트 카탈로그에서 해당 패키지를 직접 받아 설치하는 것을 제시합니다.
1실패한 KB 번호를 정확히 적어 둔다
설정 → Windows 업데이트 → 업데이트 기록에서 실패로 표시된 항목의 KB 번호와 오류 코드를 함께 확인합니다. 이 번호가 다음 단계의 검색어가 됩니다.
2내 윈도우 버전과 아키텍처를 확인한다
설정 → 시스템 → 정보에서 에디션·버전·시스템 종류를 봅니다. 카탈로그에는 같은 KB라도 버전별·아키텍처별 파일이 따로 있어, 맞지 않는 파일을 받으면 "이 업데이트는 이 컴퓨터에 적용되지 않습니다"가 뜹니다.
3카탈로그에서 받아 수동 설치한다
Microsoft 업데이트 카탈로그(catalog.update.microsoft.com)에서 KB 번호로 검색해 내 버전에 맞는 .msu 파일을 받아 실행합니다. 캐시 조립 과정을 건너뛰기 때문에 같은 코드를 피해 갈 수 있습니다.
4선택적 기능이라면 복구 원본을 직접 지정한다
.NET Framework 3.5나 언어 팩처럼 선택적 기능 설치에서 이 코드가 뜰 때 쓰는 방법입니다. 내 빌드와 같은 버전의 윈도우 ISO를 마운트한 뒤, 그 드라이브 문자를 위 명령의 E: 자리에 넣습니다.
ISO는 반드시 지금 설치된 버전과 같아야 합니다
빌드가 다른 ISO를 원본으로 지정하면 복구가 진행되다 다시 실패합니다. 설정 → 시스템 → 정보의 "OS 빌드"를 확인하고 같은 버전을 준비합니다.
이 방법이 안 통하는 경우
수동 설치한 .msu조차 같은 코드로 실패한다면 저장소 손상이 남아 있다는 뜻입니다. 7번 진단으로 누락 패키지를 확인하고, 그래도 해결되지 않으면 개인 파일을 유지한 채 윈도우를 덮어씌우는 제자리 복구 설치가 마지막 선택지입니다.
누락된 패키지를 정확히 찾아내는 법
추측으로 조치를 반복하는 대신, 로그에 적힌 패키지 이름을 직접 읽습니다.
CBS 엔진은 실패한 이유를 C:\Windows\Logs\CBS\CBS.log에 남깁니다. Microsoft 문서는 이 오류를 진단할 때 이 로그에서 특정 문구를 찾으라고 안내합니다. 그 문구에 누락된 패키지 이름이 그대로 적혀 있습니다.
1로그에서 손상 표시 줄만 뽑아낸다
터미널(관리자)에서 실행합니다. 로그 전체를 읽을 필요 없이 필요한 줄만 나옵니다.
2패키지 이름이 들어간 줄을 찾는다
Microsoft 문서가 예로 드는 줄은 "Store corruption, manifest missing for package" 뒤에 패키지 이름이 붙는 형태입니다. 그 이름이 지금 빠져 있는 부품입니다.
문서가 함께 제시하는 다른 줄도 같은 사건을 가리킵니다. Failed to resolve package, Mark store corruption flag because of package, Failed to execute execution chain 뒤에 각각 0x800f0831이 붙습니다. 이 줄들에 공통으로 등장하는 패키지 이름이 원인입니다.
3로그가 너무 길면 파일로 뽑아 연다
바탕화면에 텍스트 파일로 저장한 뒤 메모장으로 엽니다. 로그가 이미 넘어갔다면 같은 폴더의 CbsPersist_로 시작하는 파일도 함께 봅니다.
4찾아낸 이름으로 카탈로그를 검색한다
패키지 이름 안에는 대개 KB 번호가 들어 있습니다. 그 번호를 업데이트 카탈로그에서 검색해 받아 설치하면, 빠진 부품을 다시 채워 넣는 것과 같은 효과가 납니다.
조치 전후를 비교할 수 있게 시각을 적어 둡니다
CBS.log는 시간순으로 계속 덧붙습니다. 조치를 한 시각을 메모해 두면, 다시 실패했을 때 그 이후에 새로 생긴 줄만 보면 되므로 판단이 빨라집니다.
자주 묻는 질문
이 오류를 처리할 때 판단이 갈리는 지점만 모았습니다.
Q.SoftwareDistribution 폴더 이름을 바꿔도 안전한가요?
A.업데이트 임시 캐시라 이름을 바꾸면 윈도우가 새로 만듭니다. 개인 파일이나 설치된 프로그램과는 무관합니다. 다만 서비스를 멈추지 않은 상태에서는 사용 중이라 이름이 바뀌지 않으니 순서를 지켜야 합니다.
Q.DISM에서 "원본 파일을 찾을 수 없습니다"가 나옵니다.
A.온라인에서 복구 원본을 받아오지 못한 상태입니다. 연결을 유선으로 바꿔 재시도하거나, 같은 빌드의 윈도우 ISO를 마운트해 /Source 옵션으로 지정합니다. 원인 D의 4번 명령이 그 형태입니다.
Q.sfc와 DISM 중 무엇을 먼저 돌려야 하나요?
A.저장소 손상이 의심되는 이 오류에서는 DISM이 먼저입니다. sfc는 저장소의 정상 파일을 원본 삼아 복사하는 도구라, 저장소가 깨진 상태에서 먼저 돌리면 "일부를 복구할 수 없습니다"로 끝나기 쉽습니다.
Q.업데이트 하나만 계속 실패하는데 그냥 건너뛰어도 되나요?
A.보안 패치라면 권장하기 어렵습니다. 누적 업데이트는 이전 내용을 포함하므로, 더 최신 누적 업데이트를 카탈로그에서 받아 설치하면 밀린 항목까지 함께 반영되는 경우가 많습니다.
Q.백신을 끄거나 인터넷을 바꾸면 해결되나요?
A.0x800f0831은 파일을 이미 받은 뒤 설치 단계에서 나는 코드라 두 조치의 효과가 크지 않습니다. 다만 DISM이 온라인 원본을 받아야 할 때는 연결 상태가 영향을 주므로, 그 단계에서만 유선 연결이 도움이 됩니다.
Q.제자리 복구 설치를 하면 프로그램이 지워지나요?
A.설치 미디어를 실행할 때 "개인 파일 및 앱 유지"를 선택하면 파일과 프로그램은 남고 시스템 구성 요소만 새로 깔립니다. 시간이 오래 걸리는 방법이라 앞의 네 원인을 모두 확인한 뒤 선택합니다.
함께 보면 좋은 글
업데이트 오류 코드가 다르게 뜬다면 아래 글에서 코드별로 확인하세요.
윈도우11 업데이트 안 될 때, 저는 이 순서로 뚫었습니다 (0x800f0922 오류 완전 정리, 2026년 최신) 같은 설치 단계 실패인데 코드가 0x800f0922로 뜰 때 봅니다 · 눌러서 확인하기 → 윈도우 업데이트 오류 0x80070002, 저는 이 순서로 해결했습니다 (2026년 최신) 파일을 찾지 못해 실패하는 계열의 코드입니다 · 눌러서 확인하기 → 윈도우 업데이트 오류 0x8024402c 해결법, 저는 이 순서로 뚫었습니다 (2026년 최신) 다운로드 단계에서 멈추는 연결 계열 코드와 비교할 때 봅니다 · 눌러서 확인하기 →참고 문서 · Microsoft Learn — 업데이트 설치 시 0x800f0831 오류 / Microsoft Learn — Windows 설치 오류 0x800f0831 문제 해결
