Unity Crash Handler의 정체 — 그 프로세스가 뭐고 로그는 어디 있나

작업관리자에서 UnityCrashHandler64.exe를 처음 본 개발자는 대개 둘 중 하나를 묻습니다. "이거 내가 만든 게임에 왜 있지", "지워도 되나". 우선 이 파일 하나만으로 실행 방식이나 네트워크 동작을 단정하지 않는 것이 좋습니다.

이 프로세스가 뭔가

Unity의 현재 Windows IL2CPP 빌드 파일 문서는 UnityCrashHandler64.exe를 생성물 중 하나인 crash handler executable로 열거합니다. 즉 Windows Player 빌드 폴더에서 이 파일을 보는 일 자체는 예상 가능한 구성입니다. 다만 이 문서는 모든 Windows 백엔드·에디터에서의 이름, 실행 시점, 프로세스 간 통신 방식까지 정의하지는 않습니다. Unity의 Windows IL2CPP 빌드 파일 문서를 기준으로, 실제 배포물의 Unity 버전과 스크립팅 백엔드를 먼저 확인하세요.

작업관리자에 보인다면 먼저 확인할 것

문제 보고를 받을 때는 "항상 떠 있다"는 인상보다 관찰 가능한 사실을 남기는 편이 낫습니다. Player인지 Editor인지, Unity 버전·백엔드·빌드 번호가 무엇인지, 실행 파일이 해당 빌드 폴더의 파일인지, 종료·크래시 직후 어떤 로그와 크래시 폴더가 생성됐는지를 함께 기록하세요. 보안 제품이나 방화벽 경고가 있다면 그 경고만으로 이 실행 파일의 동작을 추론하지 말고, 조직의 보안 정책과 배포물의 서명·해시 검증 절차에 따라 별도로 확인해야 합니다.

크래시 산출물은 어디서 확인하나

이전 글에서 Editor와 Player의 크래시 산출물 위치를 구분해 정리했습니다. Windows Player에서는 UnityEngine.Windows.CrashReporting.crashReportFolder가 현재 실행에 할당된 크래시 리포트 폴더 경로를 제공합니다. Unity 문서는 기본 경로를 %TMP%\<CompanyName>\<ProductName>\Crashes로 설명하면서도, 시작 시 고유 경로가 할당된다고 명시합니다. 따라서 특정 파일명이나 폴더 안의 모든 산출물을 고정된 형식으로 가정하지 말고, CrashReporting.crashReportFolder 공식 문서로 실제 경로를 확인하는 편이 안전합니다.

Editor 크래시 파일의 기본 위치는 Unity 6.6 기준 %TMP%\Unity\Editor\Crashes이며 -crash-report-folder 인자로 바꿀 수 있습니다. 이는 Player 경로와 별개입니다. Unity 로그 파일 문서를 보고 어느 프로세스가 종료됐는지부터 구분하세요.

없애도 되나

일반적인 해결책으로 빌드 출력 파일을 임의 삭제하는 것은 권하지 않습니다. Unity 문서는 이 실행 파일의 제거를 위한 지원된 설정이나, 제거했을 때의 실행·리포팅 동작을 이 문서들에서 보장하지 않습니다. 삭제 뒤 게임이 정상 실행되는지, 어떤 크래시 정보가 남는지 역시 빌드·Unity 버전·재현 조건에 따라 따로 검증해야 합니다.

패키징을 바꿔야 한다면 원본 배포물과 정확한 빌드 정보를 보존하고, 수정한 후보는 격리된 테스트 환경에서 검증하세요. 특히 Windows IL2CPP 문서는 출시한 빌드마다 디버그 정보와 생성된 C++ 코드를 담은 백업 폴더를 보관하라고 안내합니다. 문제가 생겼을 때 비교할 원본이 있어야 원인을 좁힐 수 있습니다.

예외와 하드 크래시를 이분법으로 나누지 말 것

C# 예외면 로그, 네이티브 크래시면 핸들러처럼 고정해 판단하기는 어렵습니다. Windows IL2CPP에서는 Unity가 스크립트·어셈블리의 IL을 C++로 변환해 네이티브 바이너리를 만들며, GameAssembly.dll에는 IL2CPP 런타임과 스크립트 코드가 들어갑니다. 같은 문서가 SymbolMap을 지우면 예외의 호출 스택이 읽기 어려워질 수 있다고도 설명합니다. 따라서 언어만으로 크래시 산출물이나 스택트레이스의 형태를 예측하지 마세요.

대신 관찰된 증상에 맞춰 다음 순서로 자료를 모읍니다.

Crashes 폴더가 비어 있다고 해서 특정 종류의 크래시였다고 결론내릴 수도 없습니다. OS가 프로세스를 종료한 경우, 메모리 부족(OOM), 외부 종료 등은 별도의 시스템 진단과 리소스 기록이 필요할 수 있습니다. 로그·크래시 리포트·재현 영상은 서로 대체재가 아닙니다. 한 종류가 없다고 다른 종류의 실패 원인을 단정하지 말고, 시간과 빌드 번호를 맞춰 함께 보세요. 이 구분이 에러 모니터링과 QA 캡처가 보완 관계인 이유이기도 합니다.

정리

UnityCrashHandler64.exe는 Unity의 Windows IL2CPP 빌드 문서에 열거된 구성 파일입니다. 작업관리자에 보인 이름만으로 신뢰성·네트워크 동작·크래시 범위를 결론내리거나, 원인 확인 없이 파일을 삭제하지 마세요. 배포물의 출처와 버전을 확인하고, 해당 실행의 로그·크래시 폴더·디버그 정보를 함께 확보하는 쪽이 안전합니다.

크래시 리포트가 있어도 못 채우는 정보가 있습니다 — 크래시 직전에 게임이 어떤 상태였는가입니다. 스택트레이스는 어디서 죽었는지는 말해도 왜 그 상태에 이르렀는지는 말하지 않습니다. 다음 글에서 이 간극을 메우는 방법을 다룹니다.

저희 Rekon은 플레이 모드에서 사용자가 핫키를 눌렀을 때 직전 영상·로그·게임 상태를 캡처합니다. 이 수동 캡처는 즉시 종료되어 핫키를 누를 시간이 없는 크래시를 대신 처리하지 않으며, 그 경우에는 위의 크래시 리포트와 로그가 필요합니다. 반대로 캡처할 시간이 있는 이상 현상에서는 원인 조사에 필요한 시간축 맥락을 더할 수 있습니다.