MSIX 문제 해결 가이드

이 가이드에서는 설치, 서명, 앱 설치 관리자 배달, 누락된 종속성 및 런타임 동작에서 발생하는 가장 일반적인 MSIX 오류에 대해 설명합니다. 각 섹션에는 증상, 근본 원인 및 해결 방법이 포함되어 있습니다.

배포 이벤트의 전체 로그를 보려면 이벤트 뷰어 열고 Applications and Services Logs → Microsoft → Windows → AppxDeployment-Server → Operational

팁 (조언)

통합 진단 집합의 경우 패키지를 배포하기 전에 Windows 앱 인증 키트를 실행합니다.

설치 오류

0x80070005 — 액세스 거부됨

증상: Add-AppxPackage 또는 앱 설치 관리자가 오류 코드 0x80070005로 실패합니다.

에 적용: Windows 10 이상, Windows 11

원인 및 수정:

원인 수정
패키지에 컴퓨터별 설치가 필요한 경우 권한 상승 없이 표준 사용자로 실행 관리자 권한으로 PowerShell을 실행합니다. 모든 사용자에 대해 설치하려면 Add-AppxProvisionedPackage을(를) Add-AppxPackage 대신 사용하세요.
패키지 파일을 차단하는 바이러스 백신 또는 보안 소프트웨어 .msix / .msixbundle 파일에 대한 실시간 검사를 일시적으로 비활성화하거나 제외를 추가합니다.
다른 사용자에 대해 준비되고 프로비전되지 않은 패키지 모든 사용자에 대해 프로비전하는 데 사용 Add-AppxProvisionedPackage
패키지에 대한 읽기 액세스를 차단하는 파일 시스템 ACL icacls을(를) 사용하여 패키지 파일의 사용 권한을 확인하고 설치 사용자에게 읽기 액세스 권한을 부여하십시오.

앱이 사용 중이므로 패키지 설치가 차단됨

증상: 패키지가 사용 중임을 나타내는 오류와 함께 업데이트 또는 다시 설치가 실패합니다. 이벤트 뷰어 배포 작업이 거부된 것을 볼 수 있습니다.

에 적용: Windows 10 이상, Windows 11

수정: 업데이트하기 전에 앱의 실행 중인 모든 인스턴스를 닫습니다. 앱이 백그라운드 서비스이거나 백그라운드 작업이 등록된 경우 다음 작업도 종료해야 할 수 있습니다.

Get-Process -Name "MyApp" | Stop-Process -Force
Add-AppxPackage -Path .\updated-app.msix

엔터프라이즈 배포의 경우 Intune 또는 구성 관리자 사용하여 유지 관리 기간 동안 업데이트를 예약하는 것이 좋습니다.

MinVersion 또는 아키텍처 불일치

Symptom: "이 버전의 Windows 호환되지 않으므로 패키지를 설치할 수 없습니다." 또는 "패키지가 이 컴퓨터에 적용되지 않습니다."와 같은 오류와 함께 설치가 실패합니다.

적용 대상: Windows 10 이상

원인 및 수정:

원인 수정
매니페스트의 패키지 MinVersion 가 OS 버전보다 높습니다. 설치된 OS 버전을 대상으로 하는 별도의 패키지를 빌드하거나 디바이스를 업데이트합니다.
아키텍처 불일치(예: x64 디바이스의 arm64 패키지) 올바른 아키텍처 변형을 빌드하고 배포합니다. 번들(.msixbundle)을 사용하여 한 파일에서 여러 아키텍처 제공
패키지는 호환성 검사 없이 Windows 11 전용 API를 대상으로 합니다. Windows 10 및 Windows 11 모두에 대한 TargetDeviceFamily 항목을 추가하거나 런타임 시 버전 확인으로 API 호출을 보호합니다.

메모

.msixbundle 파일을 혼합 아키텍처 환경에 배포할 때 사용합니다. 번들은 여러 아키텍처에 대한 패키지를 포함하고 있으며, Windows는 설치 시점에 올바른 패키지를 선택합니다.

Add-AppxPackage 성공했지만 시작 메뉴에서 앱이 없습니다.

증상: PowerShell은 성공을 보고하지만 앱은 시작 메뉴 또는 앱 목록에 표시되지 않습니다.

에 적용: Windows 10 이상, Windows 11

일반적인 원인:

  • 사용자별 및 컴퓨터별 설치: Add-AppxPackage 현재 사용자에 대해서만 설치됩니다. 관리자 권한으로 실행 중이지만 다른 사용자에게 필요한 앱인 경우, 대신 Add-AppxProvisionedPackage 를 사용하십시오.
  • 패키지가 등록되었지만 타일이 고정되지 않음: 앱이 설치되었지만 시작 메뉴가 새로 고쳐지지 않았습니다. 로그아웃하고 다시 로그인하거나 설정 → 앱을 확인하여 설치를 확인합니다.
  • 매니페스트에 시작 메뉴 항목이 없습니다. 요소에 <Application>AppxManifest.xml 유효한 VisualElements항목이 Square150x150Logo 포함되어 있는지 확인합니다.
  • 중복된 패키지 패밀리 이름 충돌: 앱의 최신 버전 또는 이전 버전이 동일한 패키지 패밀리 이름으로 이미 설치되어 있는 경우 새 설치가 자동으로 대체될 수 있습니다. Get-AppxPackage -Name "YourPackageFamilyName"와 확인합니다.

서명 및 인증서 오류

메모

자세한 SignTool 오류 코드 및 플래그는 SignTool에 대한 알려진 문제 및 문제 해결을 참조하세요.

신뢰할 수 없는 인증서(0x800B0109)

증상: "인증서 체인이 처리되었지만 트러스트 공급자가 신뢰하지 않는 루트 인증서에서 종료되었습니다."라는 오류 0x800B0109 와 함께 설치가 실패합니다.

에 적용: Windows 10 이상, Windows 11

원인: 패키지에 서명하는 데 사용되는 인증서가 디바이스의 신뢰할 수 있는 인증서 저장소에 없습니다. 이는 자체 서명된 인증서를 개발에 사용할 때 일반적입니다.

수정: 서명 인증서를 디바이스의 로컬 컴퓨터 → 신뢰할 수 있는 사용자 저장소로 가져옵니다(현재 사용자 저장소가 아님 ) 앱 설치 관리자는 컴퓨터 저장소만 확인합니다.

# Export the certificate from the package first (if needed)
$cert = (Get-AuthenticodeSignature -FilePath .\app.msix).SignerCertificate
Export-Certificate -Cert $cert -FilePath .\app-cert.cer

# Import into Trusted People (requires administrator rights)
Import-Certificate -FilePath .\app-cert.cer -CertStoreLocation Cert:\LocalMachine\TrustedPeople

중요합니다

인증서가 루트 CA가 아닌 경우 서명 인증서를 신뢰할 수 있는 루트 인증 기관 저장소로 가져오지 마세요. 신뢰할 수 없는 자체 서명된 인증서를 가져오면 디바이스의 보안 태세가 약화됩니다.

프로덕션 앱의 경우 신뢰할 수 있는 CA 또는 Azure 아티팩트 서명(이전의 신뢰할 수 있는 서명) 인증서를 사용합니다. 이 인증서는 기본적으로 Windows 10 버전 1809 이상에서 신뢰할 수 있는 Microsoft ID 확인 루트 인증 기관에 연결되며 Windows 11.

Publisher 이름 불일치(0x8007000B, 이벤트 ID 150)

Symptom: 0x8007000B SignTool이 실패하고 이벤트 뷰어(AppxPackagingOM 작업 로그)는 Event ID 150를 표시합니다.

error 0x8007000B: The app manifest publisher name (CN=Contoso) must match
the subject name of the signing certificate (CN=Contoso, C=US).

에 적용: Windows 10 이상, Windows 11

원인: AppxManifest.xmlPublisher 속성은 서명 인증서의 주체 이름과 정확히 일치해야 하며, 모든 고유 이름 필드가 동일한 순서로 포함되어야 합니다.

수정 사항:

  1. 인증서에서 정확한 주체 이름을 가져옵니다.

    (Get-Item Cert:\CurrentUser\My\THUMBPRINT).Subject
    # Example output: CN=Contoso, C=US
    
  2. 정확히 일치하도록 업데이트 AppxManifest.xml :

    <Identity Name="Contoso.MyApp"
              Publisher="CN=Contoso, C=US"
              ... />
    
  3. MakeAppx.exe로 다시 패키지화하고 다시 서명합니다.

팁 (조언)

Azure 아티팩트 서명(이전의 신뢰할 수 있는 서명)을 사용하는 경우 매니페스트의 게시자 값은 인증서 프로필의 사용자 이름 필드 아래 Azure 포털에 있는 확인된 ID와 일치해야 합니다.

앱 설치 관리자 및 웹 배포 오류

.appinstaller 파일의 스키마 버전 불일치

증상: 앱 설치 관리자가 잘못된 파일 또는 지원되지 않는 스키마에 대한 일반적인 오류와 함께 파일을 구문 분석하거나 처리 .appinstaller 하지 못합니다.

적용 대상: Windows 10 이상(버전별 - 테이블 참조)

Cause: Uri 루트 요소의 <AppInstaller> 특성은 설치된 버전의 Windows 지원하지 않는 스키마 버전을 지정합니다.

Windows 릴리스별 스키마 버전

Windows 버전 지원되는 최소 스키마 버전
Windows 10 버전 1709 1.0.0.0
Windows 10 버전 1803 1.1.0.0
Windows 10 버전 1809 1.2.0.0
Windows 10 버전 1903 이상, Windows 11 1.3.0.0, 1.4.0.0, 1.5.0.0

수정: 파일의 스키마 URI .appinstaller 를 가장 낮은 지원 OS에 필요한 최소 버전으로 설정합니다.

<?xml version="1.0" encoding="utf-8"?>
<AppInstaller Uri="https://example.com/app.appinstaller"
              Version="1.0.0.0"
              xmlns="http://schemas.microsoft.com/appx/appinstaller/2017">

이전 Windows 10 버전을 지원해야 하는 경우 최신 스키마 버전을 사용하지 마십시오.

잘못된 MIME 형식으로 제공되거나 콘텐츠 길이가 누락된 파일

증상: HTTP/HTTPS 엔드포인트에서 설치할 때 앱 설치 관리자가 실패합니다. 오류는 ("알 수 없는 오류") 또는 "앱 설치 실패"와 같은 0x80072F76 일반적인 오류일 수 있습니다.

적용 대상: Windows 10 이상

원인: 웹 서버가 잘못된 .msix 헤더로 .msixbundle, .appinstaller또는 Content-Type 파일을 처리하거나 헤더를 생략하고 있습니다Content-Length.

수정: 올바른 MIME 형식으로 MSIX 관련 파일을 제공하도록 웹 서버를 구성합니다.

파일 확장명 필수 MIME 형식
.msix application/msix
.msixbundle application/msixbundle
.appinstaller application/appinstaller
.appx application/appx
.appxbundle application/appxbundle

또한 모든 응답에 유효한 Content-Length 헤더가 포함되어 있는지 확인합니다. 이 헤더는 두 요청 모두 GETHEAD 에 적용됩니다.

IIS의 경우 에 MIME 형식 매핑을 추가합니다 web.config. Azure Static Web Apps 또는 GitHub Pages의 경우 이러한 확장에 대한 MIME 형식에는 명시적 구성 또는 사용자 지정 호스팅 솔루션이 필요할 수 있습니다.

누락된 종속성

프레임워크 패키지가 설치되지 않음(VCLibs, .NET, Windows 앱 SDK)

Symptom: 앱이 성공적으로 설치되지만 시작 시 충돌하거나 Microsoft.VCLibs, Microsoft.WindowsAppRuntime 또는 Microsoft.NET.Native 같은 패키지 패밀리 이름을 참조하는 종속성 오류로 설치에 실패합니다.

에 적용: Windows 10 이상, Windows 11

공통 프레임워크 및 이를 가져올 위치:

프레임워크 필요한 경우 출처
VCLibs(x64/x86/arm64) 앱에서 C++ 런타임 사용 Microsoft Store(자동 설치) 또는 direct download
.NET 8 데스크톱 런타임 앱이 .NET 8을 대상으로 합니다. Windows 앱 SDK에 포함되어 있거나 직접 다운로드
Windows 앱 SDK(WinAppSDK) 앱은 WinUI 3 또는 기타 WinAppSDK API를 사용합니다. GitHub에서의 Windows 앱 SDK 릴리스

개발용 수정: Add-AppxPackage를 통한 로컬 설치 시, -DependencyPackages 매개 변수를 추가하거나 먼저 프레임워크 패키지를 설치합니다.

# Install VCLibs dependency first
Add-AppxPackage -Path .\Microsoft.VCLibs.x64.14.00.Desktop.appx

# Then install your app
Add-AppxPackage -Path .\MyApp.msix

배포 수정: 스토어 외부에 배포하는 경우 다음의 .appinstaller 파일에 프레임워크 패키지를 <Dependencies> 포함합니다.

<Dependencies>
  <Package Name="Microsoft.VCLibs.140.00.UWPDesktop"
           Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US"
           Version="14.0.30704.0"
           Uri="https://aka.ms/Microsoft.VCLibs.x64.14.00.Desktop.appx"
           ProcessorArchitecture="x64"/>
</Dependencies>

메모

Microsoft Store 통해 배포하는 경우 프레임워크 종속성이 자동으로 다운로드되고 설치됩니다. 수동 종속성 관리는 테스트용 로드 및 엔터프라이즈 배포에만 필요합니다.

CI/CD에서 SignTool을 찾을 수 없음

Symptom: CI/CD 파이프라인(GitHub Actions, Azure DevOps)이 'signtool' is not recognized as an internal or external command 또는 SignTool.exe: not found 같은 오류와 함께 실패합니다.

에 적용: Windows 10 이상, Windows 11(서명 컴퓨터)

Cause: SignTool은 Windows SDK의 일부이며 기본적으로 표준 CI 실행기 이미지에 포함되지 않습니다.

Fixes:

Option 1 - 파이프라인에 Windows SDK 설치(GitHub Actions):

- name: Install Windows SDK
  run: |
    winget install --id Microsoft.WindowsSDK.10.0.22621 --accept-source-agreements --accept-package-agreements

옵션 2 - WinApp CLI 사용 (MSIX 서명에 가장 간단함):

- name: Install WinApp CLI
  run: winget install -e --id Microsoft.WinAppCLI --source winget --accept-source-agreements
- name: Sign MSIX
  run: winapp sign output\MyApp.msix --cert ${{ secrets.CERT_THUMBPRINT }}

Option 3 - Azure 아티팩트 서명 사용(프로덕션에 권장):

- name: Sign with Azure Artifact Signing
  uses: azure/trusted-signing-action@v0
  with:
    azure-tenant-id: ${{ secrets.AZURE_TENANT_ID }}
    azure-client-id: ${{ secrets.AZURE_CLIENT_ID }}
    azure-client-secret: ${{ secrets.AZURE_CLIENT_SECRET }}
    endpoint: ${{ secrets.AZURE_ARTIFACT_SIGNING_ENDPOINT }}
    trusted-signing-account-name: ${{ secrets.AZURE_CODE_SIGNING_NAME }}
    certificate-profile-name: ${{ secrets.AZURE_CERT_PROFILE_NAME }}
    files-folder: ${{ github.workspace }}\output
    files-folder-filter: msix

메모

GitHub 작업의 이름은 azure/trusted-signing-action(이전 서비스 이름)입니다. 아티팩트 서명으로의 리브랜딩에 관계없이 공식적인 작업입니다.

CI/CD 서명 설정의 전체 연습은 MSIX 패키지 서명 - 엔드투엔드 가이드를 참조하세요.

런타임 및 가상화 동작

MSIX 패키지는 경량 앱 컨테이너 내에서 실행됩니다. 버그로 보이는 일부 동작은 실제로 의도적으로 수행됩니다. 컨테이너는 파일 및 레지스트리 작업을 가로채 시스템의 나머지 부분을 보호합니다.

파일 쓰기가 사라지는 이유(VFS 파일 리디렉션)

증상: 앱은 런타임 시와 같은 C:\Program Files\MyApp\config.ini 경로에 파일을 작성하지만 파일이 표시되지 않습니다. 앱은 값을 올바르게 다시 읽지만 다른 프로세스 또는 사용자에게는 표시되지 않습니다.

에 적용: Windows 10 이상, Windows 11

설명: MSIX는 VFS(가상 파일 시스템) 리디렉션을 사용합니다. 보호된 시스템 경로에 대한 쓰기는 자동으로 사용자별 컨테이너로 리디렉션됩니다.

%LocalAppData%\Packages\<PackageFamilyName>\LocalCache\Local\VFS\

이는 기본적으로 수행되므로 MSIX 앱이 공유 시스템 위치를 수정하지 못하게 하여 제거를 지원합니다.

옵션:

  • 대신 앱 데이터 폴더를 사용합니다: 유지해야 하는 사용자별 데이터를 ApplicationData.Current.LocalFolder (WinRT) 또는 %LocalAppData%\Packages\<PFN>\LocalState\에 작성합니다.
  • AppData\Roaming를 사용하여 디바이스 간에 로밍해야 하는 데이터를 위한 경우
  • VFS 컨테이너를 검사 하여 리디렉션된 파일을 확인합니다. %LocalAppData%\Packages\<PackageFamilyName>\LocalCache\

가상화된 경로에 대한 자세한 내용은 MSIX 컨테이너의 런타임 문제 해결을 참조하세요.

레지스트리 쓰기가 사라지는 이유(레지스트리 가상화)

증상: 앱은 런타임에 HKEY_LOCAL_MACHINE\Software\MyApp\에 값을 씁니다. 그러나 해당 값은 다른 프로세스에 표시되지 않고 재설치 후에도 유지되지 않습니다.

에 적용: Windows 10 이상, Windows 11

설명: MSIX는 쓰기를 HKLM\Software 가로채서 시스템의 나머지 부분과 격리된 패키지별 레지스트리 하이브로 리디렉션합니다. 제거하면 하이브가 삭제됩니다.

옵션:

  • HKEY_CURRENT_USER\Software\<AppName>에 사용자별 설정을 작성합니다. 이 설정들은 가상화되지 않고 지속됩니다.
  • 구조적 설정 스토리지에 Windows ApplicationData API 사용합니다.
  • AppxManifest.xml <Extensions> / 메커니즘을 사용하여 사용자 또는 프로세스 간에 공유해야 하는 레지스트리 항목을 선언합니다.

MSIX 컨테이너 동작에 대한 자세한 내용을 보려면 패키징된 데스크톱 앱이 Windows에서 어떻게 실행되는지 이해하기를 참조하세요.

Windows 10의 MSIX 제한사항

일부 MSIX 기능에는 Windows 11 또는 특정 Windows 10 버전이 필요합니다. Windows 10 디바이스에 배포하는 경우 다음 사항에 유의하세요.

Windows 10 버전 2004(빌드 19041) 이상이 필요한 기능

특징 최소 버전
자동 업데이트 2021 스키마(ShowPrompt, UpdateBlocksActivation) Windows 10 2004 (19041)
패키지 무결성 적용(uap10:PackageIntegrity) Windows 10 2004 (19041)
앱 설치 관리자 자동 복구 Windows 10 2004 (19041)
신뢰할 수 있는 앱 패키지 설치에는 별도의 사이드로딩 정책 토글이 없습니다. 현재 요구 사항에 대해서는 개발을 위해 디바이스 사용을 활성화를 참조하세요. Windows 10 2004 (19041)

Windows 11 필요한 기능

특징 Notes
전체 패키징이 없는 스파스 패키지 식별자 Windows 11 필요
외부 위치가 있는 패키지되지 않은 앱에 대한 MSIX 지원(전체 플랫폼 지원) Windows 11 일부 API가 향상되었습니다.
컴퓨터별 MSIX 설치 성능 향상 Windows 11 최적화

버전 1709보다 오래된 디바이스 Windows 10

MSIX는 1709 이전의 Windows 10 버전에서 기본적으로 지원되지 않습니다(Fall Creators Update). 이러한 디바이스에 MSIX 패키지를 배포하려면 하위 수준 Windows 10 버전에 대한 호환성 계층을 제공하는 MSIX Core를 사용합니다.

매니페스트 확장

일부 AppxManifest.xml 네임스페이스 확장은 Windows 11 전용입니다. Windows 10 대상으로 하는 패키지에 선언하면 패키징 중에 스키마 유효성 검사가 실패하거나 설치 중에 거부될 수 있습니다. 각 확장에 나열된 앱 패키지 매니페스트 스키마 참조를 확인하십시오.

디버깅 팁

특정 Windows 10 빌드에서 사용할 수 있는 MSIX 기능을 확인하려면 OS 버전별 기능 가용성을 나열하는 MSIX 기능 및 지원되는 플랫폼 페이지를 확인합니다.