WAIT — Single-maintainer risk — review before adopting

• Last commit today
• 5 active contributors
• GPL-3.0 licensed
• CI configured
• ⚠ Single-maintainer risk — top contributor 88% of recent commits
• ⚠ GPL-3.0 is copyleft — check downstream compatibility
• ⚠ No test directory detected

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

ExHyperV is a WPF-based graphical management tool for Microsoft Hyper-V that exposes advanced virtualization features (VM networking, storage, GPU passthrough, nested virtualization) through a modern sci-fi-themed UI built on WPF-UI. It abstracts complex WMI queries and HCS API calls into intuitive dialogs, letting non-expert users configure enterprise Hyper-V capabilities without PowerShell. Single monolithic WPF application: /src contains App.xaml (entry point), Assets/ (distro logos and icons for Linux guest detection), and likely ViewModels, Views, and Models directories for MVVM pattern. CI/CD via GitHub Actions in .github/workflows/ handles kernel asset builds and automated publishing.

Windows system administrators and Hyper-V power users who need to configure advanced VM features (GPU assignment, nested virtualization, SR-IOV) but prefer a graphical interface over PowerShell scripts. Also developers running Hyper-V labs on Windows machines.

Actively developed (multiple GitHub Actions workflows, recent publishing pipeline) but marked as having 'untested scenarios or bugs' per README — treat as beta-grade. Single maintainer (Justsenger) increases sustainability risk. ~869K LOC of C# suggests substantial feature scope, but no public test coverage metrics visible.

Single-point-of-failure maintainer model (Justsenger as sole author visible). No test files in the top-60 structure suggests limited automated test coverage. Tight coupling to Windows/Hyper-V APIs means breaking OS updates could require rapid patches. Dependency on WPF-UI framework means upstream UI framework issues propagate directly.

Active CI/CD pipeline: build-kernel-assets.yml, main.yml (likely test/build), and publish.yml indicate ongoing release automation. update_script_index.yml suggests dynamic script or feature catalog updates. Community channels (Telegram, QQ Group) actively managed.

Clone the repository:

git clone https://github.com/Justsenger/ExHyperV.git
cd ExHyperV

Open src/ in Visual Studio 2019+ and build the solution. Requires Windows with Hyper-V enabled and .NET Framework 4.7+ or .NET Core runtime.

Daily commands: In Visual Studio: Build > Build Solution, then Debug > Start Debugging (F5). Requires admin privileges. No command-line entry point visible — GUI-only application.

• src/App.xaml.cs — Entry point and main application initialization; essential for understanding app lifecycle and core setup.
• src/App.xaml — Root application XAML definition with resource dictionaries and global styling; defines UI framework structure.
• src/ExHyperV.csproj — Project configuration and dependency manifest; required to build and understand framework/library versions.
• src/Converters/OsTypeToImageConverter.cs — Core data binding converter for OS type resolution; demonstrates the converter pattern used throughout the UI layer.
• src/Config.xml — Application configuration and settings; governs runtime behavior for Hyper-V management features.
• src/Assets/pci.ids — PCI device database; essential reference for hardware identification and GPU/device mapping features.

• App.xaml.cs & App.xaml (WPF, C#, XAML) — Application initialization, global resource registration, entry point logic.
  • Failure mode: App fails to launch; global styles unavailable; all views fail to render.
• Converter classes (src/Converters/) (C#, IValueConverter interface) — Transform model data to UI-consumable formats (visibility, images, text); enable declarative binding.
  • Failure mode: UI elements fail

Add a new OS/GPU type asset and converter mapping

1. Add PNG image for new OS/GPU to src/Assets/ (e.g., MyOS.png) (src/Assets/)
2. Create or extend a converter class in src/Converters/ that returns the image path based on type enum (src/Converters/OsTypeToImageConverter.cs)
3. Reference the converter in XAML bindings to display the image in the UI (src/App.xaml)
4. Update images.json if the new asset represents a full OS definition (images.json)

Add a new configuration option

1. Define the new setting in src/Config.xml with appropriate XML element and attributes (src/Config.xml)
2. Create or extend a converter in src/Converters/ if the setting value needs UI transformation (e.g., enum-to-bool) (src/Converters/EnumToBoolConverter.cs)
3. Bind the XAML control to the configuration value using the converter (src/App.xaml)

Add a new value converter for custom data transformation

1. Create a new C# file in src/Converters/ implementing IValueConverter interface (src/Converters/)
2. Implement Convert() and ConvertBack() methods for your transformation logic (src/Converters/BooleanToVisibilityConverter.cs)
3. Register the converter as a resource in src/App.xaml with an x:Key (src/App.xaml)
4. Reference the converter in XAML bindings using {StaticResource ConverterName} (src/App.xaml)

Update CI/CD pipeline for new build artifact

1. Define new build step or artifact in .github/workflows/main.yml (.github/workflows/main.yml)
2. If publishing a release, add upload step in .github/workflows/publish.yml (.github/workflows/publish.yml)
3. Update .github/workflows/update_script_index.yml if the artifact affects script indexing (.github/workflows/update_script_index.yml)

• WPF (Windows Presentation Foundation) — Desktop UI framework for Windows; native Hyper-V integration and management console access; XAML-based declarative UI.
• C# / .NET Framework — Windows-native language with direct Hyper-V API access; mature ecosystem for system administration tools.
• XAML — Declarative markup for data binding and UI composition; reduces code-behind complexity.
• IValueConverter pattern — Clean separation between model data and UI representation; enables reusable transformation logic.
• GitHub Actions — CI/CD automation for builds, kernel asset compilation, and release publishing.

• Windows-only (WPF-based) application

  • Why: Direct Hyper-V API access and native Windows integration; simpler deployment on Windows systems.
  • Consequence: Excludes macOS and Linux users; requires Windows 10/11 + Hyper-V support. Linux library support (src/Linux/lib/) suggests consideration for cross-platform GPU passthrough scenarios, but core app is Windows-only.

• XML-based configuration over database

  • Why: Lightweight, human-readable, no external dependencies, easy version control.
  • Consequence: Scales poorly for complex hierarchical settings; no transactional guarantees; manual parsing required.

• Asset-driven OS/GPU identification (images.json + PNG assets)

  • Why: Intuitive visual UI; distributed static assets; no runtime API calls needed.
  • Consequence: Requires manual asset updates for new OS/GPU support; metadata split across JSON, XML, and file system.

• Cross-platform support (non-Windows Hyper-V management)
• Authentication/authorization layer (assumes trusted Hyper-V host access)
• Real-time monitoring dashboard or metrics collection
• Linux GUI management (Linux docs suggest CLI/backend focus only)

Admin privilege requirement: Application will not launch or function without Run as Administrator on Windows. Hyper-V-specific: Feature toggles may silently fail if Hyper-V is not installed or enabled (dism /online /enable-feature /featurename:Microsoft-Hyper-V). WPF framework: Requires Visual Studio to build; no .NET CLI support visible. Localization: Mixed Chinese/English culture detection — system locale may affect UI language, no manual override visible in file list.

• Windows Management Instrumentation (WMI) — ExHyperV queries Hyper-V configuration and state exclusively via WMI classes (Msvm_VirtualSystemManagementService, Msvm_ComputerSystem); understanding WMI class hierarchies is mandatory for feature development
• Hyper-V Host Compute Service (HCS) API — README mentions HCS as complement to WMI for advanced VM control (GPU assignment, nested hypervisor); lower-level than WMI for performance-critical paths
• GPU Passthrough / SR-IOV (Single-Root I/O Virtualization) — Core feature visible in img/WDDM.png; requires understanding device assignment, IOMMU, and WDDM driver interaction — key selling point of this tool over basic Hyper-V Manager
• MVVM (Model-View-ViewModel) Pattern — ExHyperV uses MVVM via WPF (xaml.cs code-behind structure); developers must understand binding, DependencyProperty, and INotifyPropertyChanged to modify UI logic correctly
• Nested Virtualization — ExHyperV exposes nested VM (Hyper-V-in-Hyper-V) configuration; requires understanding CPU flag passthrough and generation-2 VM constraints
• XAML (EXtensible Application Markup Language) — App.xaml and all UI files use XAML syntax; modifying layouts, theming, and view definitions requires XAML fluency beyond typical C# coding
• Dynamic Theme Switching (Light/Dark Mode) — README highlights automatic dark/light theme switching via WPF-UI; implementation likely in App.xaml resources and theme composition, critical for user experience polish

• MicrosoftDocs/Virtualization-Documentation — Official Microsoft Hyper-V and HCS API documentation referenced in README; canonical source for WMI class definitions
• lepoco/wpfui — WPF-UI framework that powers ExHyperV's modern dark/light themed UI; understanding this is critical for UI feature additions
• Justsenger/HyperV-WMI-Documentation — Companion repo by same author documenting Hyper-V WMI classes; essential reference for extending VM configuration features
• proxmox/pve-manager — Alternative open-source hypervisor UI; shows how other projects expose advanced VM features in a graphical interface
• microsoft/hyperv-samples — Official Microsoft C# and PowerShell samples for Hyper-V WMI/HCS; code reference for correct VM query patterns

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive documentation for Linux driver mapping in doc/drivermapping.md

The repo has doc/Linux.md and doc/drivermapping.md listed but the drivermapping.md file appears to be incomplete or missing detailed content. Given that ExHyperV manages Hyper-V features including Linux VMs, this document should detail how drivers map between different Linux distributions (ArchLinux, CentOS, Debian, Ubuntu, etc.) shown in src/Assets/. This directly supports users configuring VMs and would reduce support burden.

• [ ] Review src/Assets/ directory to identify all supported Linux distributions
• [ ] Document driver mapping strategies for each distribution listed (ArchLinux, CentOS, Debian, Fedora, LinuxMint, Manjaro, NixOS, Ubuntu, Deepin)
• [ ] Add troubleshooting section for common driver installation issues on Hyper-V
• [ ] Include examples and links to official driver sources per distribution
• [ ] Add table of contents and cross-references to doc/Linux.md

Create GitHub Action workflow to validate images.json schema and asset references

The repo has images.json at root level and extensive assets in src/Assets/ (vendor logos, distribution icons, banners). Currently there are 4 workflows in .github/workflows/ but none validate that images.json properly references existing asset files. This prevents broken image references and inconsistent asset management as the project grows.

• [ ] Create .github/workflows/validate-assets.yml workflow
• [ ] Add JSON schema validation for images.json format
• [ ] Add step to verify all asset paths in images.json exist in src/Assets/
• [ ] Add step to identify orphaned asset files not referenced in images.json
• [ ] Configure workflow to run on pull requests modifying images.json or src/Assets/

Add infrastructure documentation for hardware GPU driver support in doc/

The src/Assets/ directory contains GPU vendor logos (AMD.png, Intel.png, NVIDIA.png, Intel-IrisXe.png, Inter-ARC.png, Qualcomm.png, Silicon.png) suggesting the tool manages GPU driver scenarios, but there's no corresponding documentation. Create doc/GPU-Support.md to document which GPUs are supported, driver requirements per vendor, and Hyper-V GPU passthrough configuration—this is critical for users trying to use advanced GPU features.

• [ ] Create doc/GPU-Support.md with supported GPU vendors and models
• [ ] Document driver download links and installation procedures for each vendor (NVIDIA, AMD, Intel, Qualcomm)
• [ ] Add troubleshooting section for GPU passthrough and WDDM configuration (WDDM.png assets exist but undocumented)
• [ ] Create hardware requirements table for each GPU family
• [ ] Add cross-references to existing img/WDDM.png and img/WDDM_cn.png

• Add unit tests for WMI query builders: Create src/Tests/HyperV/WmiQueryTests.cs to validate PowerShell-equivalent queries before sending to WMI, currently no test coverage visible
• Document GPU passthrough setup in doc/GPU-Passthrough.md: README mentions GPU features (seen in img/WDDM.png) but no step-by-step guide exists; add a companion doc with prerequisites and validation steps
• Implement missing Linux distro detection icons: Add distro logos (Ubuntu, RHEL, openSUSE) to src/Assets/ — currently only ~8 icons exist but images.json likely references more

The ExHyperV project is a WPF-based Hyper-V management tool with moderate security concerns. The main issues are the inability to verify dependency security (no manifest provided), potential input validation risks in a privileged management application, and configuration file handling. The codebase structure itself appears well-organized with proper separation of concerns (converters, assets, etc.). Critical recommendations: (1) Provide and audit dependency manifests, (2) Implement comprehensive input validation and sanitization given the privileged nature of the application, (3) Secure any sensitive configuration data using encryption, and (4) Conduct a security review of all Windows API and Hyper-V API interactions. No evidence of hardcoded secrets or obvious injection vulnerabilities was found in the file structure analysis, but deeper code review is needed.

• Medium · Missing Dependency Vulnerability Analysis — Repository root - missing dependency manifest. No package dependency file (package.json, packages.config, .csproj, etc.) was provided for analysis. This prevents identification of known vulnerable dependencies. The project appears to be a C# WPF application but dependency information is incomplete. Fix: Ensure all dependency files are present and run regular security scans using tools like NuGet Auditor, Snyk, or OWASP Dependency-Check to identify and remediate vulnerable dependencies.
• Medium · Potential Unsafe Windows API Usage — src/ - particularly any interop or native code. As a Hyper-V management tool working with Windows virtualization, the codebase likely uses Windows APIs and elevated privileges. Without reviewing the actual source code, there's risk of improper API usage, privilege escalation, or unsafe interop calls. Fix: Conduct a security review of all Windows API calls, ensure proper error handling, validate all inputs before passing to APIs, and follow Microsoft's security best practices for Windows application development.
• Medium · WPF Application Input Validation Risk — src/App.xaml.cs and related view-model/code-behind files. WPF applications processing user input (especially for VM configuration, network settings, storage paths) could be vulnerable to injection attacks if inputs are not properly validated before being used in commands or system calls. Fix: Implement strict input validation for all user-provided data, use parameterized APIs for system commands, avoid string concatenation for command construction, and sanitize all inputs used in Hyper-V API calls.
• Low · Configuration File Security — src/Config.xml. The presence of src/Config.xml suggests configuration data storage. If this file contains sensitive information (credentials, API keys, or connection strings), it could pose a security risk. Fix: Never store sensitive data in plain text configuration files. Use Windows DPAPI (Data Protection API) for encrypting sensitive configuration, store credentials in Windows Credential Manager, or use secure vaults. Implement file-level access controls.
• Low · PCI IDs File Source Validation — src/Assets/pci.ids. The src/Assets/pci.ids file appears to be from a third-party source (likely pciids.sourceforge.net). Without verification of integrity, there's a low risk of supply chain attack. Fix: Verify the integrity of third-party data files using checksums or signatures. Document the source and version. Consider implementing update verification mechanisms if this file is auto-updated.
• Low · External CDN Resource in README — README.md - badge/image URL. The README contains a reference to an external CDN (aged-moon-0505.shalingye.workers.dev) for download badges. While low severity, this introduces a third-party dependency that could be compromised. Fix: Use static GitHub-based badge services or self-hosted alternatives. Avoid external CDNs for critical project information when possible.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/Justsenger/ExHyperV shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live Justsenger/ExHyperV repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Justsenger/ExHyperV.

What it runs against: a local clone of Justsenger/ExHyperV — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in Justsenger/ExHyperV | Confirms the artifact applies here, not a fork | | 2 | License is still GPL-3.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of Justsenger/ExHyperV. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/Justsenger/ExHyperV.git
#   cd ExHyperV
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of Justsenger/ExHyperV and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "Justsenger/ExHyperV(\\.git)?\\b" \\
  && ok "origin remote is Justsenger/ExHyperV" \\
  || miss "origin remote is not Justsenger/ExHyperV (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(GPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"GPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is GPL-3.0" \\
  || miss "license drift — was GPL-3.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "src/App.xaml.cs" \\
  && ok "src/App.xaml.cs" \\
  || miss "missing critical file: src/App.xaml.cs"
test -f "src/App.xaml" \\
  && ok "src/App.xaml" \\
  || miss "missing critical file: src/App.xaml"
test -f "src/ExHyperV.csproj" \\
  && ok "src/ExHyperV.csproj" \\
  || miss "missing critical file: src/ExHyperV.csproj"
test -f "src/Converters/OsTypeToImageConverter.cs" \\
  && ok "src/Converters/OsTypeToImageConverter.cs" \\
  || miss "missing critical file: src/Converters/OsTypeToImageConverter.cs"
test -f "src/Config.xml" \\
  && ok "src/Config.xml" \\
  || miss "missing critical file: src/Config.xml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/Justsenger/ExHyperV"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.