Proposal: an opt-in, support-requested "Collect Diagnostics" tool for hard-to-diagnose reports

[HetCreep]

The problem

WD writes a transcript to Logs/, but it's effectively hidden, and it records the narration (Write-Host "Removing X"), not the failures — the actual error detail goes to Write-Verbose (e.g. RemoveApps.ps1, ApplyRegistryRegFile.ps1), which the transcript doesn't capture ($VerbosePreference is never set to Continue), and there's no surrounding system context. So reports end up vague, and the bug-report template's required Steps to reproduce is exactly where it breaks down — reporters who can't articulate the problem give vague or unknown steps (e.g. "I don't know which uninstalled app is causing it").

The principle

Handed a WD problem, a maintainer goes and inspects a known set of things: the registry state of the affected feature, WD's own footprint on it (the .reg files applied + the registry backup + the chosen preset + the transcript), the timing, the relevant Windows Event logs, System Restore history, and basic system state. The idea is a tool that automates that exact inspection list — so the person who hit the problem doesn't have to be the debugger; they run one thing and you get a debugger's-eye-view bundle.

What it would capture (= what a debugger would inspect)

• WD footprint — the applied .reg set / chosen preset (LastUsedSettings.json) / the registry backup JSON / the Logs/ transcript → lets you rule WD definitively in or out of any "did WD break X?" question.
• System context — filtered Application + System + Microsoft-Windows-AppXDeploymentServer/Operational event logs; Get-AppxPackage -AllUsers + provisioned state; winget version/list; System Restore / System Protection status + restore-point history; OS build.
• Packaged into a single redacted zip.

Works retroactively (after a self-fix)

Users often hit a problem and immediately try System Restore before reporting. The bundle would lean on sources that survive a restore — Event logs (not reverted; System Restore only touches the registry + monitored files), the appended transcript, restore-point history — so the failure evidence is recoverable even after they tried to recover. (Current registry/Appx state reflects the post-fix state and can't be reconstructed, but what failed survives.)

Privacy

WD's users debloat for privacy, so this would redact (usernames, PC name, SIDs, user paths), show a manifest of what's included, and let the user open the zip before uploading. Opt-in and transparent.

Distribution — gated by design (so it doesn't generate noise)

Not promoted in the main flow. A standalone support tool you link when a report is unclear: a user files a normal issue → if it isn't enough to diagnose, you ask them to run the tool while the problem is still present and attach the zip. It runs only on request — no flood of unsolicited dumps — and it supplements the issue template rather than replacing it. A determined user can still find it; a casual one won't trip over it.

Notes

• Self-consistency: it would avoid runtime C# compilation (Add-Type -MemberDefinition) so it doesn't trip the same antivirus temp-DLL false-positive currently affecting WD (When i press Apply Changes, it makes a random dll in Temp #659 / Script bails and nothing ahppens #660 / Random DLL bugs with "GEN:Variant" caught by antivirus #663, GUI startup still compiles MaximizedWindowHelper at runtime, emitting the same temp DLL that trips antivirus (#659/#660/#663) -- not covered by #661 #668) — built-in cmdlets/assemblies only.
• Deliberately lightweight: collect + redact + zip, no analysis engine, so it's low-maintenance. Could be a separate script / release asset rather than a change to WD core, keeping it out of your main code path.
• Some elevation (admin) is needed for complete capture (-AllUsers Appx, full event logs) — so an admin-gate with a clear warning when not elevated, like similar tools use.

Question

Would an opt-in, support-requested diagnostics collector like this be useful to you — as a separate tool you can link when a report needs more data? If there's interest I'm happy to prototype it, and I'd want your steer on positioning (standalone vs a WD switch), the exact capture list, and the redaction scope.

[Raphire]

Heya,

While this might provide some more details on errors I'm not sure if I'm comfortable adding this. Outside of the privacy concerns I think it may end up being more trouble than it's worth.

[HetCreep]

Totally fair, and the privacy angle is the right thing to weigh first.

Just to clarify the design in case it shifts the concern: it was meant to be fully opt-in and local-only -- the script writes a single file the user can open and read, with nothing uploaded automatically; they would manually attach it to a report only if they choose to. Sensitive values (usernames/paths) could be redacted in the output. So the privacy exposure stays in the user's hands.

That said, the maintenance/support-burden point is completely your call -- you are the one who would carry it, and "more trouble than it's worth" is a legitimate reason to pass. No worries either way; happy for you to close this if you would rather not take it on.