Background
winappcli 0.6.1 has two winapp run options the extension never surfaces:
--debug-output — winapp attaches itself as the debugger. Streams OutputDebugString and first-chance exceptions inline, filtering framework noise (WinUI, COM, DirectX internal traces) from the console while writing everything to a log file. On crash it captures a minidump and analyzes it automatically: managed (.NET) crashes yield exception type, message, and a stack with source file and line numbers resolved from PDBs in the build output; native (C++/WinRT) crashes yield module names and offsets. For WinUI it additionally runs automatic stowed-exception triage, decoding the 0xC000027B exception and the native Microsoft.UI.Xaml → CXcpDispatcher → CoreMessagingXP → CLR host dispatch chain that ordinary stacks lose.--symbols — downloads PDBs from the Microsoft public symbol server for real native function names, plus the OS symbols (combase.dll) the stowed-exception decode needs. Only meaningful with --debug-output.
See winappcli docs/debugging.md ("Scenario E").
Why this needs its own design decision
This is an alternative workflow, not an option on the existing one:
- Windows permits one debugger per process, so winapp's diagnostics and VS Code's breakpoints are mutually exclusive by construction.
- The CLI forbids
--debug-output with --json, which WinAppDebugAdapterFactory depends on to parse the launched PID.
So it cannot be bolted onto the existing launch-and-attach path. It answers "why did my app crash?", whereas the current adapter answers "let me step through my code" — and the WinUI triage specifically targets the case where breakpoints are useless because the stack has already unwound.
Options to decide between
- (A) Advanced palette command only — expose the toggles in a
winapp run options prompt; reject them in resolveDebugConfiguration with a pointer to that command. Simplest, no adapter changes, but leaves WinUI crash triage behind a palette flow users won't find when their app just crashed under F5.
- (B) A non-attach "diagnostics" debug mode — e.g.
"attach": false / "mode": "diagnostics" on the winapp debug type. The adapter skips --json/PID parsing and the child debug session entirely, streams stdout to the WinApp output channel, and ends the session when the process exits. Gives WinUI developers a "crash-triage F5". Costs a real adapter branch and a second set of docs.
Prerequisite
Tracked as a follow-up to the winapp run project-mode work. That work introduces src/run-options.ts with WinAppRunOptions (already including debugOutput/symbols fields) and validateRunOptions (already encoding the --debug-output + --json and --debug-output + --no-launch conflicts), so this issue should be a UI-surface change only.
Background
winappcli 0.6.1 has two
winapp runoptions the extension never surfaces:--debug-output— winapp attaches itself as the debugger. StreamsOutputDebugStringand first-chance exceptions inline, filtering framework noise (WinUI, COM, DirectX internal traces) from the console while writing everything to a log file. On crash it captures a minidump and analyzes it automatically: managed (.NET) crashes yield exception type, message, and a stack with source file and line numbers resolved from PDBs in the build output; native (C++/WinRT) crashes yield module names and offsets. For WinUI it additionally runs automatic stowed-exception triage, decoding the0xC000027Bexception and the nativeMicrosoft.UI.Xaml → CXcpDispatcher → CoreMessagingXP → CLR hostdispatch chain that ordinary stacks lose.--symbols— downloads PDBs from the Microsoft public symbol server for real native function names, plus the OS symbols (combase.dll) the stowed-exception decode needs. Only meaningful with--debug-output.See winappcli
docs/debugging.md("Scenario E").Why this needs its own design decision
This is an alternative workflow, not an option on the existing one:
--debug-outputwith--json, whichWinAppDebugAdapterFactorydepends on to parse the launched PID.So it cannot be bolted onto the existing launch-and-attach path. It answers "why did my app crash?", whereas the current adapter answers "let me step through my code" — and the WinUI triage specifically targets the case where breakpoints are useless because the stack has already unwound.
Options to decide between
winapp runoptions prompt; reject them inresolveDebugConfigurationwith a pointer to that command. Simplest, no adapter changes, but leaves WinUI crash triage behind a palette flow users won't find when their app just crashed under F5."attach": false/"mode": "diagnostics"on thewinappdebug type. The adapter skips--json/PID parsing and the child debug session entirely, streams stdout to the WinApp output channel, and ends the session when the process exits. Gives WinUI developers a "crash-triage F5". Costs a real adapter branch and a second set of docs.Prerequisite
Tracked as a follow-up to the
winapp runproject-mode work. That work introducessrc/run-options.tswithWinAppRunOptions(already includingdebugOutput/symbolsfields) andvalidateRunOptions(already encoding the--debug-output+--jsonand--debug-output+--no-launchconflicts), so this issue should be a UI-surface change only.