dotnet/maui · error · Exception

Category discovery run did not complete successfully

Error message

Category discovery run did not complete successfully

What it means

Thrown in the packaged Controls test path when LaunchPackagedAndWait returns false for the category-discovery invocation (the app is launched with a -1 index to enumerate test categories). A false return means the packaged app either failed to activate/launch or did not exit within the 120-second timeout, so discovery never completed.

Source

Thrown at eng/devices/windows.cake:497

					Warning($"Failed to install dependency (exit code {depExit}): {dep}");
				}
			} catch {
				Warning($"Failed to install dependency: {dep}");
			}
		}

		// Install the DeviceTests app
		var installExit = InstallAppxPackage(msixPath);
		if (installExit != 0) {
			throw new Exception($"Failed to install app MSIX (exit code {installExit}): {msixPath}");
		}

		if (isControlsProjectTestRun)
		{
			// Start the app once to trigger the discovery of the test categories; we wait
			// for the actual app process to exit, then read the categories file.
			if (!LaunchPackagedAndWait($"\"{testResultsFile}\" \"-1\"", "category discovery", 120)) {
				throw new Exception("Category discovery run did not complete successfully");
			}

			if (!FileExists(testsToRunFile)) {
				throw new Exception("Test categories file was not created during discovery phase");
			}

			var expectedCategories = System.IO.File.ReadAllLines(testsToRunFile);
			var filteredCategories = FilterCategories(expectedCategories);
			
			if (filteredCategories.Length == 0) {
				Information("No categories to run after applying filter. Skipping test execution.");
				return;
			}
			
			Information($"Will run {filteredCategories.Length} filtered categories out of {expectedCategories.Length} total");

			for (int i = 0; i < filteredCategories.Length; i++)
			{

View on GitHub (pinned to f377ff1c5e)

Solutions

Launch the packaged app manually (or via the app's activation) and read any crash/Event Viewer entry to find the startup exception.
Check LaunchPackagedAndWait's own logging for whether it was a launch failure or a timeout, then raise the timeout or fix the crash accordingly.
Ensure all dependency MSIX frameworks installed successfully (review the dependency Warning lines); a missing framework causes immediate activation failure.
Re-run GenerateMsixCert and rebuild if the package signature/registration is suspect; unregister and reinstall the package.

Defensive patterns

Strategy: try-catch

Validate before calling

// Before the discovery run, verify the package is registered and dependencies installed
if (!IsPackageRegistered(PACKAGEID))
    throw new Exception($"Package {PACKAGEID} not registered; install failed earlier.");

Try / catch

try { if (!LaunchPackagedAndWait(args, "discovery", 120)) throw new Exception("Discovery launch/timeout — check activation and dependencies."); }
catch (Exception ex) { Error($"Discovery failed: {ex.Message}"); throw; }

Prevention

Confirm all dependency frameworks installed before launching the packaged app.
Capture Event Viewer app-crash entries when discovery fails to pinpoint the startup exception.
Keep the discovery timeout generous on slow CI runners.

When it happens

Trigger: The packaged WinUI app crashes on startup (e.g. missing runtime, unhandled init exception); app activation fails because the package family is not registered correctly; the discovery run exceeds the 120s timeout on a slow machine; the app hangs waiting for user input or a missing dependency.

Common situations: First launch after a fresh build where dependency installation was skipped/warned; a code change introducing a startup crash; slow CI runner hitting the 120s cap; package registration left in a bad state by a prior failed run.

Related errors

AI-assisted analysis of dotnet/maui@f377ff1c5e (2026-08-13). Data as JSON: /api/errors/2f711d14fb57a572. Report an issue: GitHub.