- Published on
Azure VM 0xc000000e 부팅 실패 즉시 복구 가이드
- Authors
- Name
- 스타차일드
- https://x.com/ETFBITX
서버가 갑자기 재부팅되더니 Windows가 올라오지 않고 0xc000000e(부팅 구성 데이터/부팅 장치 접근 불가 계열)로 멈춘다면, 운영 관점에서 중요한 건 “원인 분석”보다 서비스를 최대한 빨리 정상화하는 것입니다. 이 글은 Azure에서 Windows VM이 0xc000000e로 부팅 실패할 때, 가장 빠르게 복구 가능한 경로를 우선순위로 정리한 실전 가이드입니다.
> 전제: 대상은 Azure IaaS Windows VM(Gen1/Gen2 혼재 가능). 복구 과정에서 디스크를 분리/마운트하므로, 스냅샷/백업을 먼저 확보하는 것을 강하게 권장합니다.
0xc000000e가 의미하는 것(현상 → 원인 분류)
0xc000000e는 보통 아래 범주 중 하나로 수렴합니다.
- BCD(부팅 구성 데이터) 손상/누락: 업데이트/드라이버 설치/디스크 오류 이후 흔함
- EFI System Partition(ESP) 또는 시스템 예약 파티션 문제: Gen2(UEFI)에서 ESP 손상/드라이브 문자 꼬임
- OS 디스크/컨트롤러/드라이버 불일치: 스토리지 드라이버 문제, 디스크 연결 문제
- 부팅 장치 경로 변경: 디스크 복제/스냅샷 복원/파티션 구조 변경 후
Azure에서는 콘솔 화면을 직접 보기 어렵기 때문에, 진단은 대개:
- Boot diagnostics 스크린샷, 2) Serial Console(SAC), 3) OS 디스크를 다른 VM에 붙여 오프라인 복구 의 조합으로 합니다.
즉시 복구 전략(가장 빠른 순서)
운영에서의 “즉시 복구”는 보통 다음 3단계 중 하나로 귀결됩니다.
- 스냅샷에서 신속 롤백(가장 빠름)
- OS 디스크를 복구 VM에 붙여 BCD/EFI 재생성(가장 범용)
- Serial Console로 부트 로더 복구(가능할 때만 빠름)
장애가 장기화되면 로그를 더 보겠지만, 지금은 “부팅을 살리는 것”이 최우선입니다.
0단계: 안전장치(스냅샷/복구 지점 만들기)
복구 작업은 디스크의 부트 섹터/BCD를 건드릴 수 있습니다. 먼저 스냅샷을 떠서 되돌릴 수 있게 만듭니다.
Azure CLI로 OS 디스크 스냅샷
# 변수
RG="prod-rg"
VM="win-prod-01"
SNAP="${VM}-osdisk-snap-$(date +%Y%m%d%H%M)"
# OS 디스크 ID 조회
OSDISK_ID=$(az vm show -g "$RG" -n "$VM" --query "storageProfile.osDisk.managedDisk.id" -o tsv)
# 스냅샷 생성
az snapshot create -g "$RG" -n "$SNAP" --source "$OSDISK_ID"
> 이미 Azure Backup(Recovery Services Vault)를 사용 중이면, 복구 지점에서 새 디스크를 만들어 붙이는 방식이 더 안전할 수 있습니다.
1단계: Boot diagnostics로 “어느 계열인지” 30초 진단
Azure Portal → VM → Boot diagnostics에서 스크린샷을 확인합니다.
- “\Boot\BCD missing” / “The Boot Configuration Data file is missing” → BCD/EFI 복구 루트
- “INACCESSIBLE_BOOT_DEVICE”와 함께 0xc000000e → 스토리지 드라이버/컨트롤러/디스크 연결 가능성
- “No bootable device” → 부트 파티션/EFI 파티션 인식 문제
이 단계는 정밀 진단이 아니라, 다음 액션(오프라인 복구 vs 롤백)을 결정하는 용도입니다.
2단계(가장 범용): OS 디스크를 복구 VM에 붙여 오프라인 복구
Serial Console이 막혀 있거나, 화면만 보고는 답이 안 나올 때 가장 성공률이 높습니다.
절차 개요
- 장애 VM Stop(Deallocate)
- OS 디스크 Detach(또는 스냅샷에서 복제 디스크 생성)
- 동일 지역/동일 세대의 복구용 Windows VM에 OS 디스크를 데이터 디스크로 Attach
- 복구 VM에서 Disk Management/PowerShell로 파티션 확인
- BCDBoot/Bootrec로 BCD/EFI 재생성
- 원래 VM에 OS 디스크 재부착 후 부팅
> 운영에서는 “원본 OS 디스크를 직접 만지는 것”보다, 스냅샷에서 복제 OS 디스크를 만들어 교체하는 편이 안전합니다.
스냅샷 → 새 Managed Disk 생성(권장)
RG="prod-rg"
SNAP="win-prod-01-osdisk-snap-202602231200"
NEWDISK="win-prod-01-osdisk-repair"
SNAP_ID=$(az snapshot show -g "$RG" -n "$SNAP" --query id -o tsv)
az disk create -g "$RG" -n "$NEWDISK" --source "$SNAP_ID" --sku Premium_LRS
이 새 디스크를 복구 VM에 붙여 작업하고, 성공하면 장애 VM의 OS 디스크로 교체합니다.
3단계: 복구 VM에서 파티션/부트 모드(Gen1 vs Gen2) 확인
복구 VM에 디스크를 붙인 뒤, Gen1(BIOS/MBR) 인지 Gen2(UEFI/GPT) 인지에 따라 명령이 달라집니다.
PowerShell로 디스크/파티션 타입 확인
Get-Disk | Select Number, FriendlyName, PartitionStyle, OperationalStatus, Size
Get-Partition -DiskNumber 2 | Select PartitionNumber, DriveLetter, Type, Size
PartitionStyle = GPT이고 작은 EFI(System) 파티션이 보이면 → Gen2(UEFI) 가능성 높음PartitionStyle = MBR이고 System Reserved(100~500MB) 파티션이 보이면 → Gen1(BIOS) 가능성 높음
4단계: Gen2(UEFI/GPT)에서 ESP + BCD 재생성(가장 흔한 성공 루트)
Gen2에서 0xc000000e가 뜨는 케이스는 ESP(대개 100MB~260MB)가 손상되었거나, BCD가 깨진 경우가 많습니다.
4-1) EFI 파티션에 드라이브 문자 할당
EFI 파티션은 기본적으로 드라이브 문자가 없을 수 있습니다. diskpart로 문자를 할당합니다.
diskpart
list disk
select disk 2
list vol
select vol <EFI로 보이는 볼륨 번호>
assign letter=S
exit
OS 파티션(Windows 폴더가 있는 곳)도 문자를 확인합니다(예: W:).
4-2) BCDBoot로 EFI 부트 파일/BCD 생성
bcdboot W:\Windows /s S: /f UEFI
W:는 Windows가 설치된 파티션S:는 EFI 파티션
4-3) BCD 내용 확인(선택)
bcdedit /store S:\EFI\Microsoft\Boot\BCD /enum all
이후 디스크를 원래 VM에 붙이고 부팅을 시도합니다.
5단계: Gen1(BIOS/MBR)에서 Bootrec로 BCD/MBR 복구
Gen1은 시스템 예약 파티션 + 활성 파티션 개념이 중요합니다.
5-1) 시스템 예약/OS 파티션 확인 및 활성화(필요 시)
diskpart
list disk
select disk 2
list part
select part <System Reserved 또는 부팅 파티션>
active
exit
5-2) Bootrec 실행
bootrec /fixmbr
bootrec /fixboot
bootrec /scanos
bootrec /rebuildbcd
/fixboot에서 Access is denied가 나는 경우가 있는데, 그때는 시스템 파티션에 문자를 할당하고 bcdboot로 우회하는 편이 더 안정적입니다.
bcdboot W:\Windows /s S: /f BIOS
6단계: “부팅은 되는데 곧바로 재부팅/블루스크린”일 때(드라이버/업데이트 롤백)
BCD를 복구해도 부팅 직후 실패한다면, 최근 변경(Windows Update, 드라이버, 안티바이러스, 디스크 필터 드라이버)이 원인일 수 있습니다.
오프라인 상태에서 다음을 시도합니다.
6-1) WinRE 대신 오프라인 레지스트리로 SafeBoot 강제(고급)
복구 VM에서 오프라인 레지스트리를 로드해 Safe Mode 부팅을 유도할 수 있습니다.
# 예: OS 볼륨이 W: 라고 가정
reg load HKLM\OFFLINE_SYSTEM W:\Windows\System32\config\SYSTEM
# SafeBoot 옵션을 BCD에 주는 방식이 일반적이지만,
# 레지스트리 기반 튜닝은 환경마다 달라 여기서는 로드/언로드만 예시로 둡니다.
reg unload HKLM\OFFLINE_SYSTEM
6-2) 최근 설치 업데이트 제거(오프라인 DISM)
dism /image:W:\ /get-packages | findstr /i "Package_for_RollupFix"
dism /image:W:\ /remove-package /packagename:<패키지명>
> 패키지 제거는 시간이 걸리고 리스크가 있으므로, 즉시 복구가 목표라면 스냅샷 롤백이 더 빠를 수 있습니다.
7단계: Azure에서 자주 놓치는 체크포인트
VM 세대/펌웨어 불일치
Gen2 디스크를 Gen1 VM에 붙이거나(또는 반대) 하면 부팅이 실패합니다. 복구 VM/대상 VM의 세대가 맞는지 확인하세요.
Secure Boot/Trusted Launch 영향
Trusted Launch(보안 부팅) 환경에서 부트 체인이 깨지면 더 민감하게 실패할 수 있습니다. 복구 후 설정을 원복해야 할 수 있습니다.
디스크 암호화(ADE/PMK/CMK)
암호화된 OS 디스크는 다른 VM에 붙였을 때 접근이 제한될 수 있습니다. 이 경우는 키/권한/복구 절차가 별도로 필요합니다.
8단계: 재발 방지(운영 관점)
0xc000000e는 “한 번 고치고 끝”이 아니라, 다시 발생할 수 있는 유형입니다. 운영에서 최소한 아래를 권장합니다.
- 정기 OS 디스크 스냅샷 자동화(업데이트 전후)
- Azure Backup으로 애플리케이션 일관성 백업(가능하면)
- 변경 작업(드라이버/보안 에이전트/업데이트) 전 롤백 플랜 문서화
- 부팅 장애 대응 Runbook을 만들어 야간에도 동일 품질로 처리
장애 대응 Runbook을 만들 때는, 다른 인프라 장애 복구 글처럼 “증상 → 즉시 조치 → 원인 분기 → 복구 명령” 형태가 가장 효과적입니다. 예를 들어 네트워크 계층 장애에서의 노드 복구 흐름은 K8s NodeNotReady - CNI 플러그인 장애 복구 가이드처럼 체크리스트화가 핵심이고, IaC로 변경이 들어간 환경이라면 타임아웃/적용 실패 같은 맥락도 함께 보는 게 좋습니다(Terraform apply 멈춤 - AzureRM 120초 타임아웃).
장애 시나리오별 “가장 빠른” 선택지 요약
- 최근 변경 전 시점이 명확(업데이트/배포 직후) → 스냅샷/백업으로 롤백이 최단
- 원인 불명 + 즉시 복구 필요 → 복구 VM에 디스크 붙여 BCDBoot/Bootrec
- Serial Console 가능 + 단순 BCD 문제 → 콘솔에서 부트 복구가 더 빠를 수 있음
마무리: 복구의 핵심은 BCDBoot 한 줄을 정확히 치는 것
Azure Windows VM의 0xc000000e는 대부분 “OS는 멀쩡한데 부트 체인만 깨짐”인 경우가 많습니다. 이때 가장 성공률이 높은 접근은:
- 스냅샷 확보
- 복구 VM에 OS 디스크 연결
- Gen2면
bcdboot W:\Windows /s S: /f UEFI - Gen1이면 Bootrec/BCDBoot 조합
여기까지가 ‘즉시 복구’의 최소 단위입니다. 다음 단계로는 왜 BCD/ESP가 깨졌는지(업데이트, 디스크 오류, 에이전트 충돌)를 추적해 재발을 줄이면 됩니다.