Skip to content

Support Bundle Capability (Flow)

This document describes the end-to-end technical flow for generating and using SmrtHub Support Bundles.

Canonical references

  • Support Bundle Subsystem (contracts and invariants): README.Files/Subsystems/SupportBundle/README.md
  • Support Bundle Reference Guide: README.Files/Reference-Guides/Smrt.SupportBundle.README.md
  • Operational Data Policy (canonical locations): README.Files/System/Policies/SmrtHub-Operational-Data-Policy-v1.0.README.md
  • Privacy & Security Policy (redaction expectations): README.Files/System/Policies/SmrtHub-Privacy-and-Security-Policy.README.md

Purpose and scope

  • Describe how Support Bundles are triggered, assembled, and packaged.
  • Clarify which components contribute artifacts and where evidence is discovered.
  • Provide troubleshooting guidance for incomplete bundles.

Entry points

  • HubWindow diagnostics actions (tray/taskbar): “Generate Support Bundle”.
  • CLI tooling that requests a bundle for a time window.
  • Approved automation hooks (when explicitly enabled).

Participating Components/Subsystems

  • Support Bundle implementation: SmrtApps/src/Smrt.SupportBundle/README.md
  • Support Bundle Subsystem (contracts): README.Files/Subsystems/SupportBundle/README.md
  • Logging Subsystem (inputs/observability): README.Files/Subsystems/Logging/README.md
  • Logging Reference Guide (HTML export parity): README.Files/Reference-Guides/SmrtHub.Logging.README.md
  • Storage Guard service host (signed system-info evidence producer): SmrtApps/src/Smrt.StorageGuard.ServiceHost/README.md
  • Retention Subsystem (retention evidence inputs): README.Files/Subsystems/Retention/README.md

Sequence / flow

  1. Trigger

  2. User/operator triggers bundle generation (typically from HubWindow) or a tool invokes the exporter.

  3. Plan

  4. The exporter computes which categories and components to include, based on options (time window, filters).

  5. Collect

  6. Evidence is collected from canonical Operational Data locations (logs, system info, diagnostics artifacts, optional config snapshots, retention/storage-guard evidence where applicable).

  7. Sanitize

  8. Artifacts are copied into a staging directory and sanitized/redacted per policy.

  9. Manifest + review output

  10. A manifest is generated with SHA-256 hashes and a summary of inclusions/skips/errors.

  11. Human review output is generated for fast triage.

  12. Package

  13. Staging content is packaged into a ZIP under the requested output directory.
  14. Staging directories are cleaned up.

Configuration and operational data

  • Support Bundles read input artifacts exclusively from the canonical directories defined by the Operational Data Policy.
  • Output location is always caller-controlled (for example ExportOptions.OutputDirectory); the exporter does not invent new global output roots.
  • Storage Guard and retention evidence are machine-wide artifacts (typically under %ProgramData%/SmrtHub/Logs/system-info/); the Support Bundle flow consumes those signed outputs rather than attempting to re-run probes during export.

Observability & diagnostics

  • The export flow must emit structured telemetry through SmrtHub.Logging (C#) and must never rely on ad-hoc loggers.
  • Every run produces audit-friendly diagnostics:
  • manifest.json with per-file hashes and inclusion/skip/error summaries.
  • HTML review output for quick triage.
  • Failures must be actionable: include the category, the canonical input path attempted, and the reason it was skipped/failed.

Security & privacy

  • Redaction is a first-class requirement. The exporter must never include secrets or raw sensitive content by accident.
  • When redaction cannot be applied safely, the flow must fail fast or skip the artifact with a clear error, per the Privacy & Security Policy.

Failure modes and expected behaviors

  • Missing category inputs: category is skipped and recorded in the manifest + logs.
  • Redaction failure: fail fast or skip the artifact with a clear error; never include raw secrets by accident.
  • Permission issues: log which canonical path was inaccessible and which account context is required.
  • Large bundles: apply caps and record truncation decisions in the manifest.

Testing & validation expectations

  • Validate bundles include logs for the requested time window.
  • Validate manifest hashing and review output.
  • Validate redaction behavior against known token/PII patterns.