# camera24 미디어 재생 장애 및 10월 26일 복구 이력

- 조사일: 2026-11-01 KST. 상태: 읽기 전용 조사·근거 보존 완료, 복구 조치 미실행.
- 공유 대상: Web 담당자 및 i-VPM Plus 미디어 앱 담당자.
- 범위: 현재 camera24 재생 실패와 2026-10-26 복구 이력. AI 엔진 개선이나 기존 6개 ERROR 전체의 원인 통합 판정은 범위 밖이다.
- 읽는 순서: 이 보고서 → [기계용 근거 요약](evidence_summary.json) → [보존 파일 지문](preservation_index.json).

## 1. 결론

현재 재생 실패를 가장 직접적으로 설명하는 원인은 **Web PC의 미디어 앱 `IVPMPlus.exe`가 실행되지 않는 것**이다. Web 앱·nginx·Docker 자체는 실행 중이지만, REC-01 미디어 제어와 영상 공급 포트가 열려 있지 않다. Web 로그도 camera24에 `STREAM_NOT_READY / REC_STREAM_UNAVAILABLE`을 기록한다.

**2026-10-31 23:35:51에 IVPMPlus.exe 충돌이 기록됐고, 10월 25일에도 같은 관측상 충돌 서명이 있었다.** 다만 동일 서명만으로 내부 버그나 Chrome 메모리 누수를 확정할 수 없다. 보존한 crash dump의 .NET 예외 종류·메시지·stack 분석이 남아 있다.

10월 26일에는 오전이 아니라 **13:33경 미디어 앱이 새로 실행되고 REC 연결이 회복**된 근거가 있다. 누가 어떤 버튼/명령으로 실행했는지는 확인되지 않았다. PC 재부팅이나 Web Docker 재시작으로 복구했다는 근거는 확인되지 않았다.

## 2. 구성과 실패 위치

```text
브라우저 → nginx HTTPS → Web 앱
                         ├─ DB의 camera24 → REC-01 설정
                         ├─ REC-01 미디어 제어 연결: 실패
                         └─ 영상 준비 확인: REC_STREAM_UNAVAILABLE

같은 Web PC의 IVPMPlus.exe → RTSP/HTTP/RTC 영상 공급
        현재 프로세스 없음, 관련 listen/bind 없음
```

Web 소스의 `RecManagedConfiguration`은 활성 REC의 DB 설정을 읽고, `RecConnectionManager`가 제어 연결·동기화·ready를 관리한다. 조사에서는 env 기본값만 추정하지 않고 DB의 camera24/REC-01 연결과 실제 Web 로그를 대조했다. UI 영상 공급이 막힌 문제이므로 R5의 bbox 색상이나 행동 threshold 조정으로 해결할 단계가 아니다.

| 구성요소 | 확인 상태 | 해석 범위 |
| --- | --- | --- |
| Web 앱·Redis·DB Docker | 3개 running, Oct23 시작, restart count 0 | 현재 미디어 앱과 별개로 살아 있음 |
| nginx HTTPS 443 / Web 앱 9090 | TCP 연결 성공 | HTTP 화면·미디어 재생 전체 정상까지 뜻하지 않음 |
| IVPMPlus.exe | 현재 프로세스 0개 | 영상 공급 담당 앱 부재 |
| REC 제어 27000 / RTSP 8555 / HTTP 8888 | listen 없음, TCP probe 각 약 1.5초 timeout | 실제 REC 설정 대상의 연결 불가 |
| RTC UDP 8000 | 로컬 endpoint 없음 | 미디어 bind 부재; UDP 영상 품질 시험은 아님 |
| camera24 | REC-01 할당, AI 활성, Web에서 stream unavailable | AI Start보다 앞선 미디어 준비 단계 문제 |

## 3. 사건별 시간선

모든 표의 시각은 KST다. 원본 Docker 로그의 `Z`는 UTC이므로 +9시간을 적용한다. 호스트 간 시계 동기화는 검증하지 않았으므로 초 단위 차이로 인과 순서를 확정하지 않는다.

| 사례 | 시각 | 확인 사실과 근거 |
| --- | --- | --- |
| MEDIA-20261025 | 10/25 21:44:14.860 | Application Error 1000, record 295671: IVPMPlus.exe 2.0.1.2, PID 37748 충돌 |
| 같은 사례 | 10/25 21:45:39.407 | WER 1001, record 295672. 해당 PID dump가 남아 있음 |
| 다음 날 오전 | 10/26 08:00~13:00 | 보존한 Web 로그에서 REC 연결 실패·영상 준비 실패 확인; 복구 완료 근거 없음 |
| 복구 | 10/26 13:33:16.468 | 후속 충돌 기록의 ProcessCreationTime에서 PID 12452 실행 시각 확인 |
| 복구 | 10/26 13:33:23.060 | DB SERVER_LOG record 53202: `REC_STARTED`, `Streaming(REC) started.` |
| 복구 | 10/26 13:33:23.903~25.205 | Web `media_control_upgrade_succeeded` → sync 성공 → `media_control_ready` |
| 후속 연결 | 10/26 13:37:36.973 부근 | 일시 재연결 후 다시 ready. 첫 복구와 구분 |
| MEDIA-20261031 | 10/31 23:35:19~28 | 일시 unavailable 뒤 제어 연결/ready 및 camera24 STARTED 기록. 이 앞선 단절을 후속 crash 자체와 혼동하지 않음 |
| 같은 사례 | 10/31 23:35:50.142 | 기존 AI 분석 기록: camera24 RTSP `server closed the connection` 및 EOS. 이번에는 AI 엔진 재실행 없이 기존 근거 재사용 |
| 같은 사례 | 10/31 23:35:51.277 | Application Error 1000, record 296590: PID 12452 충돌 |
| 같은 사례 | 10/31 23:36:57.242 | WER 1001, record 296591. 해당 PID dump가 남아 있음 |
| 현재 | 11/01 12시대 | 미디어 앱·관련 listener 없음, REC 연결 실패와 camera24 unavailable 반복 |

PID 12452는 기존 10월 28일 모니터링 자료에도 존재한다. 앱 실행 시각과 10월 26일 REC 복구 기록이 맞물린다. 관측된 parent는 explorer이지만, 이것으로 특정 작업자나 정확한 실행 방법을 확정하지 않는다. OS LastBootUpTime은 9월 10일로 조회됐고 nginx/컨테이너 시작 시각도 10월 26일 이전이다.

## 4. 확정된 것과 미확정인 것

| 판단 | 상태 |
| --- | --- |
| 현재 REC 서비스 연결 불가와 미디어 앱 부재 | 직접 확인 |
| 두 날짜의 IVPMPlus.exe 충돌 기록 | 직접 확인 |
| 10/26 13:33경 앱 실행 후 REC 연결 회복 | 여러 기록으로 교차 확인; 실제 브라우저 재생 당시 화면은 미보유 |
| 두 충돌의 앱 버전·module·exception·offset 동일 | 직접 확인. 같은 내부 버그라는 증명은 아님 |
| 정확한 .NET 예외 종류, 문제 함수, 메모리 누수 여부 | 미확정. dump 분석 필요 |
| Chrome 또는 AI R5 변경이 충돌을 유발 | 근거 부족. 이 충돌은 Nov1 R5 현장 반영보다 앞선 기록 |
| 네트워크·브라우저의 다른 문제가 전혀 없음 | 보장하지 않음. 미디어 복구 후 실제 재생 확인 필요 |

충돌 공통값은 `KERNELBASE.dll`, 예외 `0xe0434352`, offset `0x00000000000c41ca`다. 이 코드는 CLR/.NET 예외 범주를 나타내며, Windows DLL 손상이나 OutOfMemory를 특정하지 않는다. [Microsoft 설명](https://learn.microsoft.com/en-us/shows/inside/e0434352)

WER Report ID는 각각 `484f33e0-0bc6-4eb6-b2be-05e1a352fdbb`, `c75c983e-7b1c-4a71-aa02-4b438bebd6a8`이다. 관리형 예외의 실제 내용은 dump에서 예외 객체와 stack을 확인해야 한다. [dotnet 공식 dump 분석 예](https://github.com/dotnet/diagnostics/blob/main/documentation/sos_printexception_walkthrough.md)

## 5. Chrome·자원 관련 기록

- 이번 전후 비교에서 Chrome 8개 PID·시작 시각, nginx 2개 PID·시작 시각, 컨테이너 3개의 ID/image/시작 시각/restart count가 유지됐다. 탭 새로고침·종료·캐시 초기화를 하지 않았다.
- 현재 RAM 여유는 약 8GiB다. 현재 여유만으로 과거 충돌 시점의 메모리 압박 여부를 판단하지 않는다.
- 기존 ChromeMonitor 10/28 11:57~14:41의 1,051행에서 Chrome private commit 최대 3,000MiB, 시스템 free RAM 최소 2,928.1MiB가 기록돼 있다. 10/31 충돌 시점과는 다르므로 누수 원인으로 연결하지 않는다.
- 별도의 10/29~10/30 Chrome 메모리 기록과 프로세스 세부 CSV도 보존했다. command line 등이 들어 있는 원본은 공유 ZIP에서 제외했다.
- DB 로그의 STORAGE_WARNING·DB_WRITE_SLOW는 보존한 부가 신호다. 현재 확인한 디스크 여유만으로 해당 경고를 부정하거나, 반대로 crash 원인이라고 단정하지 않는다.

## 6. 보존 자료와 비밀정보 경계

| 자료 | 보존/검증 |
| --- | --- |
| Windows crash 이벤트 4건의 원문 XML, WER 보고서 2개 | 보호 폴더 사본 및 SHA256 대조 |
| 10/26 오전·13:30~13:40, 10/31 23:30~23:40 Web 로그 | 시간 제한 원문 보존, test 전송 지문 대조 |
| 기존 Chrome 모니터 CSV·수집 script | 원본 유지, 보호 폴더 사본 SHA256 대조 |
| `IVPMPlus.exe.37748.dmp` | 139,120,023 bytes, 10/25 생성. Windows 보호 폴더에만 사본 보존 |
| `IVPMPlus.exe.12452.dmp` | 98,583,769 bytes, 10/31 생성. Windows 보호 폴더에만 사본 보존 |
| 현재 프로세스·listener·DB 선택 조회·실제 source/설정 근거 | test 접근 제한 영역에 보존 |

처음 확인한 WER Temp의 임시 minidump는 없어졌지만, 별도 사용자 CrashDumps 폴더에서 위 두 dump를 찾았다. 따라서 **분석용 dump 자체가 유실됐다고 결론 내리지 않는다.** 두 사본은 원본과 SHA256이 같고 원본 크기·mtime도 유지됐다. 새 dump 생성이나 레지스트리 변경은 하지 않았다.

이 공유 묶음에는 마스킹된 보고서·선별 로그·지문만 있다. dump에는 메모리 속 인증정보가 포함될 수 있으므로 일반 채팅/메일에 첨부하지 말고 승인된 제한 경로로 담당자에게 전달해야 한다. 실제 보호 경로는 작업자의 비공개 manifest에 남겼다.

## 7. 해결안과 담당 범위

1. **우선 복구안, 별도 승인 필요:** 기존 운영자 실행 방식으로 IVPMPlus만 다시 실행한다. PC 재부팅, Chrome 초기화, Web Docker 재시작은 첫 조치로 권하지 않는다. 과거에도 앱 실행 후 REC가 ready로 회복된 근거가 있다. 재실행은 임시 복구이지 crash 원인 수정이 아니다.
2. **복구 후 필수 확인:** REC 제어 연결·sync·ready와 camera24의 실제 브라우저 재생을 확인한다. Web이 저장된 Start를 재요청하므로 미디어 회복 후 AI 채널/알람도 다시 움직일 수 있다. 같은 채널에 별도 Start를 중복 주입하지 않는다.
3. **원인 수정, 미디어 앱 담당:** 보존한 두 dump와 동일 버전 binary 지문으로 예외 type/message, inner exception, 관리형/native stack을 분석한다. 요청·저장소·영상 stream·시간 제한 처리 중 어느 경로인지 근거가 나오기 전에는 원인을 정하지 않는다.
4. **재발 관측, Web 담당:** REC disconnected와 AI 오류를 구분해 안내하고 camera/run·REC 연결 generation·wall-clock을 함께 남긴다. 현재 Web의 `REC_STREAM_UNAVAILABLE` 차단 근거는 유효하다. 앱 생존과 제어/stream readiness를 별도 지표로 확인한다.
5. **자동 복구는 후속 설계:** dump 보존 후 제한 횟수·backoff·중복 실행 방지·실패 알림이 있는 미디어 앱 감시를 검토한다. GUI 앱의 사용자 session·인증 상태를 고려해야 하므로 무조건 Windows service로 바꾸지 않는다. 기존 dump 수집이 있으니 설정을 덮어쓰기 전에 먼저 확인한다. [Microsoft의 per-app LocalDumps 계약](https://learn.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps)

현재 조사에서 실행한 것은 SSH 조회, bounded TCP connect, 읽기 전용 DB transaction, 로그·기존 dump 사본 보존뿐이다. 미디어/Chrome/nginx/Docker/AI Runtime 변경, Start/Stop, 실제 복구는 하지 않았다. 브라우저 재생 정상화나 Web 연계 완료를 주장하지 않는다.

## 8. 조사 한계와 후속 재개

- 초기 `docker logs --tail` 조합은 과거 구간을 충분히 포함하지 못했다. 이를 부정 근거로 사용하지 않고, `--since/--until` 구간의 no-tail 수집으로 보완했다.
- nginx의 현재 access log는 method/status 중심이며 요청 path가 없어 미디어 실행 주체를 특정할 수 없다. stock config 대신 실제 `nginx-runtime/manager.conf`를 확인했다.
- 원본 dump는 보존했지만 debugger를 설치하거나 dump 내용을 분석하지 않았다. 다음 원인 분석의 우선 자료다.
- 이 조사용 SSH는 서비스가 아닌 임시 프로세스다. 파일·키·설정은 디스크에 남지만 재부팅 후 자동 연결되는 반영구 세팅은 아니다. 현재는 후속 조사/복구 결정을 위해 `RETAIN`하며 자동 시작 등록이나 방화벽 확대는 하지 않는다.
- 후속 요청은 `보존한 근거를 유지하고 IVPMPlus만 복구` 또는 `복구하지 않고 두 crash dump를 추가 분석`으로 구분할 수 있다. 어느 쪽도 이번 조사에서 자동 실행하지 않았다.