FlClash 0.8.96이 실행되지 않을 때 해결하는 방법

이 글은 Windows에서 FlClash 0.8.96을 설치한 뒤 전혀 실행되지 않는다는 최근 두 가지 보고를 다룹니다. 첫 번째는 MSVCP140.dll 또는 VCRUNTIME140.dll 누락 팝업이 바로 나타나는 경우입니다. 보고 원문에는 VCRUNTIME_1.dll도 적혀 있지만, 정확한 파일명은 이 PC의 팝업을 기준으로 확인해야 합니다.

두 번째는 화면은 열리지만 코어 실행에 실패하면서 DesktopCoreFailure가 표시되는 경우입니다. 둘 다 설치가 손상된 것처럼 보이지만 실제 점검 경로는 다릅니다.

공식 issue #2370에는 Windows 11 25H2에서 v0.8.96 설치 후 나타난 DLL 팝업이 기록되어 있고, issue #2367에는 Smart App Control의 코어 차단과 Code Integrity 이벤트 3077 및 3089가 기록되어 있습니다.

두 보고 모두 이 글의 게시 시점까지 유지 관리자의 확인을 받지 못했습니다. 여기서는 증상 근거로만 사용하며, v0.8.96에 동일한 설치 결함이 있다고 확인된 것처럼 설명하지 않습니다.

FlClash가 이미 실행되고 노드 Timeout, TUN 연결 끊김 또는 구독 실패만 발생한다면 이 글의 범위가 아닙니다. DLL 팝업이나 Code Integrity 근거가 없는데 런타임 설치, 보안 기능 해제, 클라이언트 재설치를 한꺼번에 진행하지 마세요.

팝업이 반복되는 FlClash를 먼저 종료하고 연이어 덮어 설치하지 마세요. Windows 버전, 시스템 종류, FlClash 설치 파일명, 첫 팝업 또는 DesktopCoreFailure 화면을 기록합니다. v0.8.96 공식 Release에는 Windows amd64 및 arm64 설치 파일과 압축 파일이 모두 있으므로, 파일명으로 실제 설치한 항목을 확인할 수 있습니다.

이전에 시스템 프록시나 TUN을 켰다면 먼저 Windows 네트워크 설정에서 시스템 프록시를 끄고 일반 웹페이지에 직접 연결되는지 확인하세요. 클라이언트가 실행되지 않는데 로컬 프록시를 계속 켜 두면 실행 오류와 PC 전체의 연결 끊김을 구분하기 어려워집니다. Profile, 구독 또는 앱 데이터 디렉터리는 삭제하지 마세요. 두 점검 경로 모두 사용자 설정을 먼저 초기화할 필요가 없습니다.

팝업에 MSVCP140.dll, VCRUNTIME140.dll 또는 같은 종류의 v14 런타임 파일이 명확히 표시될 때만 이 경로로 진행하세요. Microsoft는 이러한 파일을 Visual C++ v14 Redistributable과 함께 배포합니다.

Microsoft 공식 페이지는 장기간 유지되는 x64, x86 및 ARM64 다운로드 링크를 제공합니다. 현재 FlClash Windows Release의 자산 대상은 amd64와 arm64이므로, 보통 공식 자산 대상과 일치하는 x64 또는 ARM64 런타임을 먼저 설치하세요. 공식 안내나 의존성 검사에서 32비트 구성 요소가 명확히 확인될 때만 x86을 고려합니다.

amd64 설치 파일은 Microsoft x64 런타임에 대응하고 arm64 설치 파일은 ARM64 런타임을 사용할 수 있습니다. Microsoft는 현재 x64 설치 파일에 x64와 ARM64 바이너리가 함께 포함된다고 설명하지만, 가장 쉽게 확인하는 방법은 여전히 FlClash 설치 파일의 아키텍처와 런타임 다운로드 항목을 일치시키는 것입니다.

DLL 팝업은 없지만 화면에 DesktopCoreFailure가 표시된다면 먼저 Windows 보안을 열어 ‘앱 및 브라우저 컨트롤’의 Smart App Control 상태를 확인하세요.

켜져 있다는 사실만으로 차단을 입증할 수는 없습니다. 오류 발생 시간과 Microsoft-Windows-CodeIntegrity/Operational 로그의 이벤트도 일치시켜야 합니다.

Microsoft 문서에 따르면 이벤트 3077은 강제 정책이 실제로 차단한 파일을 기록하고, 이벤트 3089는 서명 정보를 제공합니다. 먼저 3077로 차단된 파일을 확인한 다음 Correlation ActivityID로 같은 판정에 연결된 하나 이상의 3089를 찾으세요.

시간이 가깝다는 이유만으로 판단하면 다른 소프트웨어의 서명 이벤트를 잘못 대응시킬 수 있습니다. #2367 보고에서는 두 종류의 이벤트가 모두 FlClash 코어 프로그램을 가리킵니다.

로그에 해당 경로와 ActivityID가 없다면 DesktopCoreFailure를 Smart App Control 때문이라고 자동으로 판단하지 마세요.

Microsoft의 현재 설명에 따르면 Smart App Control에는 개별 앱을 허용하는 스위치가 없으며, 일반 Defender 제외 항목도 Code Integrity의 신뢰 판정을 대신할 수 없습니다. 3077을 확인한 뒤 디렉터리 제외 항목을 반복해서 추가하거나 타사 재패키징 사이트에서 이른바 잠금 해제 코어를 찾지 마세요.

더 안전한 순서는 공식 설치 파일, 3077 및 같은 ActivityID에 속한 3089의 민감 정보 제거 근거를 먼저 보관해 FlClash에 제보한 뒤, 프로젝트가 검증 가능한 서명이나 평판 상태가 명확한 새 공식 빌드를 이미 제공했는지 확인하는 것입니다.

기다리는 동안 이 PC에서 이전에 실제로 실행된 공식 FlClash 버전으로 돌아가거나, 유지 관리 중이고 출처를 확인할 수 있는 다른 클라이언트를 임시로 사용할 수 있습니다. 이전 버전도 계속 차단된다면 반복적인 다운그레이드를 중단하세요.

Smart App Control 전체를 끄면 시스템 수준의 보호가 낮아지며 FlClash만 영향을 받는 것이 아닙니다. Microsoft FAQ의 재활성화 조건도 최근 변경된 적이 있으므로 이 글에서는 기능 해제를 고정된 해결 절차로 제시하지 않습니다. 반드시 필요하다면 현재 PC의 Windows 버전에 해당하는 공식 안내를 먼저 읽고 기기 전체에 미치는 영향을 이해한 뒤 직접 결정하세요.

DLL 경로를 마친 뒤 FlClash를 다시 실행해 기존 팝업이 사라지고 화면과 코어가 모두 정상적으로 로드되는지 확인하세요. Smart App Control 경로를 마친 뒤에는 DesktopCoreFailure가 사라졌는지와 이번 실행 시간 근처에 FlClash 코어를 가리키는 새 3077이 없는지를 함께 확인해야 합니다. 창이 열리는 것만으로는 완료가 아니며 코어와 설정도 성공적으로 로드되어야 합니다.

처음 복구할 때는 TUN을 끈 상태로 유지하고 기존 Profile에서 사용 가능한 것으로 확인된 노드를 선택한 뒤 시스템 프록시를 켜 일반 HTTPS 요청을 한 번 완료하세요. 이렇게 하면 ‘프로그램이 다시 실행됨’과 ‘네트워크 설정도 계속 사용 가능함’을 따로 검증할 수 있습니다.

런타임을 복구한 뒤에도 같은 DLL 팝업이 나타난다면 먼저 ‘설치된 앱’에서 Microsoft Visual C++ v14 Redistributable의 아키텍처를 확인하세요. 표시 이름은 버전에 따라 달라질 수 있으므로, 확인한 뒤 Repair를 다시 실행합니다.

그다음 FlClash v0.8.96 공식 Release에서 시스템과 일치하는 설치 파일을 다시 다운로드하세요. 같은 아키텍처의 공식 압축 파일로 비교 테스트해 문제가 설치 과정에서만 발생하는지도 판단할 수 있습니다.

압축 파일에서도 같은 DLL 오류가 발생하면 FlClash를 반복해서 덮어쓰지 말고 런타임을 계속 확인하세요. DLL 오류가 사라진 대신 DesktopCoreFailure가 나타났다면 다른 경로로 넘어간 것이므로 Code Integrity 이벤트를 확인해야 합니다. Smart App Control 차단이 계속되는 상태에서 신뢰 상태가 바뀌지 않은 동일한 파일을 재설치해도 보통 결과는 달라지지 않습니다.