Help

Save, Reopen, and Compare USB Capture Sessions

Save a session

After capturing USB traffic, save as a .bscope session file. The session preserves:

All captured packets with decoded fields
Adapter metadata (platform, capture source, timestamps)
Filter state at time of save
Device identification

Reopen a session

Open a saved .bscope file to review captured evidence offline. All packet tables, decodes, and filters are available exactly as they were during the live capture.

Compare sessions

The most powerful diagnostic pattern: capture the working device behavior, capture the failing behavior, then compare.

Reopen the known-good and failing sessions in turn, or use separate application instances where that is safe and supported by the operating system. Bus Scope does not claim an automatic side-by-side diff engine. Record comparable landmarks and inspect:

Enumeration sequence (descriptors, configuration selection)
Class-specific requests (HID reports, CDC commands, MSC commands)
Endpoint traffic patterns
Error statuses and stalls
Timing and sequencing

The difference between the working and failing capture is usually the evidence that explains the bug.

Direct answer: preserve comparable evidence

A useful .bscope session is more than a packet archive. Save the capture only after recording the host, operating system, capture provider, device identity, firmware build, physical topology, action that triggered the behavior, and the expected result. Professional session replay allows the case to be reopened. Comparison remains an operator workflow: align the same semantic stages and find the first defensible divergence.

Comparison field	Known-good case	Failing case
Host and provider	OS, kernel/build, usbmon, USBPcap, or XHC20	Same where controlled; otherwise record difference
Device identity	VID, PID, serial, interfaces, speed	Confirm whether identity changed
Firmware and configuration	Exact build and selected mode	Candidate build and selected mode
Trigger action	Same application command or physical action	Repeat the same action
Capture scope	Same bus, root hub, device, endpoints, and filters	Confirm no evidence was filtered out
First divergence	Baseline request, response, status, or timing	First different semantic event

The first divergence is generally more useful than a broad list of every different timestamp. Two hosts can number frames differently and expose capture records through different provider formats, so compare USB meaning: setup fields, descriptor bytes, transfer direction and type, endpoint, status, lengths, resets, stalls, and sequence.

Save and recovery checklist

Before saving, stop or pause capture at a deliberate point and note whether the failure completed, recovered, or remained active. Use a filename that identifies the device, firmware, host, scenario, and case state without exposing secrets. Keep the source capture and .bscope file in an approved project folder.

After saving:

close the active case;
reopen the .bscope file;
confirm device and adapter metadata;
inspect a packet near the start, target failure, and end;
confirm filters have not hidden the evidence;
verify descriptor, decoded-event, statistics, and packet-detail views;
retain the original session while preparing any report or derivative.

If reopen fails or content appears incomplete, do not overwrite the only session. Preserve the file, record the application version and error, and use the capture troubleshooting guide to separate file recovery from capture-provider problems.

Compare working and failing sessions

Begin with enumeration: reset, initial device descriptor request, assigned address, complete descriptors, configuration selection, and driver/class setup. Then compare the command that starts the failing behavior. Follow the same endpoint and direction through its completion, short packet, STALL, timeout, reset, or disconnect.

Divergence	What it supports	What it does not prove alone
Descriptor bytes differ	Firmware table, mode, identity, or corruption needs review	Which source line is wrong
Same request, different response length	Buffer, state, or descriptor contract is a strong lead	Root cause without firmware evidence
First STALL on one build	Endpoint or control-request handling diverged	Why the device chose STALL
Reset follows the same command	Command and reset are correlated	Electrical, watchdog, firmware, or host ownership
Bus evidence matches but app result differs	Driver or application layer deserves attention	That every USB detail is healthy

For a broader comparison method, use the complete USB diagnostics guide.

Edition and handoff boundary

Current catalog truth places live capture, decoders, triggers, large-capture analysis, and the available JSON/text evidence path in Community. Professional adds reusable session replay. Saving and reopening .bscope sessions therefore requires the paid capability; an access error is different from a malformed file or missing provider.

Session files can contain device identifiers, payload bytes, HID reports, storage commands, media, and private firmware behavior. Review authorization, access, retention, and recipient scope before handoff. A Professional license grants software capability, not permission to capture or share device traffic.

Session QA

Both runs use a documented, repeatable trigger.
Host, provider, topology, device, firmware, and filters are recorded.
The session is reopened before it becomes evidence.
Comparison starts from the same semantic USB stage.
The first divergence is stated with packet fields and context.
Different providers are not compared only by frame number.
Conclusions distinguish correlation from proven root cause.
Sensitive data and retention are reviewed before handoff.

FAQ

Does Bus Scope automatically diff two sessions?

No automatic diff engine is claimed. Reopen the sessions, align comparable stages, and record the first meaningful difference.

Is session replay included in Community?

No. The current catalog identifies session replay as the paid capability.

Can I compare Linux and Windows captures?

Yes, but compare semantic transfers rather than provider record shape or frame numbering. usbmon and USBPcap observe the host stack differently.

Direct answer and acceptance boundary

For “Save, Reopen, and Compare USB Capture Sessions”, the short answer is: How to save USB captures as .bscope sessions, reopen them for review, and compare sessions to identify differences between working and failing device behavior. Treat that statement as a result to verify, not as a promise that every input, device, project, or environment behaves identically. A complete result records the starting state, the exact action, the visible output, and the condition that proves the task is finished in Bus Scope.

Evidence-first operating procedure

Work from a small, repeatable case before changing a full project. Record the application version, operating system, input or device identity, relevant settings, and the expected result. Perform one deliberate action, preserve the first unexpected transition, and compare it with a known-good run whenever one is available. Changing several controls at once may hide which condition fixed or created the problem.

Checkpoint 1: Save, Reopen, and Compare USB Capture Sessions

Treat “Save, Reopen, and Compare USB Capture Sessions” as a separate acceptance gate for “Save, Reopen, and Compare USB Capture Sessions”. Record its initial state before acting, then capture the first visible change and the final state. If the result differs from the page’s stated outcome, return to the last confirmed checkpoint instead of continuing with assumptions.

Checkpoint 2: How to save USB captures as .bscope sessions, reopen them for review, and compare sessions

Verify “How to save USB captures as .bscope sessions, reopen them for review, and compare sessions to identify differences between working and failing device ” with the smallest representative input. Keep unrelated settings unchanged, repeat the same action once, and note whether the result is stable after reopening or reconnecting. A screenshot alone is weaker than a record that includes the input, setting, action, output, and time.

Checkpoint 3: Save a session

For “Save a session”, distinguish a product decision from an operating-system, hardware, source-file, permission, or workflow boundary. Confirm which layer supplied the evidence before assigning a cause. This prevents a nearby symptom from being reported as a proven root cause.

Checkpoint 4: Reopen a session

Use “Reopen a session” to define a pass/fail statement that another operator can repeat. Include what should be present, what must be absent, and what recovery action is safe if the check fails. Keep the original project or capture unchanged until the repaired copy has passed the same check.

Checkpoint 5: Compare sessions

When “Compare sessions” is ambiguous, compare one known-good case with one failing case under matching conditions. Mark the first meaningful difference rather than listing every later symptom. That first boundary usually produces a clearer support request and a safer next experiment.

Checkpoint 6: Direct answer: preserve comparable evidence

Close “Direct answer: preserve comparable evidence” only after the saved, exported, or reopened result still matches the observed state. Temporary UI feedback is useful, but durable evidence is stronger. Record any limitation that remains so the next reader does not interpret an incomplete path as a successful one.

Checkpoint 7: Save and recovery checklist

Treat “Save and recovery checklist” as a separate acceptance gate for “Save, Reopen, and Compare USB Capture Sessions”. Record its initial state before acting, then capture the first visible change and the final state. If the result differs from the page’s stated outcome, return to the last confirmed checkpoint instead of continuing with assumptions.

Checkpoint 8: Compare working and failing sessions

Verify “Compare working and failing sessions” with the smallest representative input. Keep unrelated settings unchanged, repeat the same action once, and note whether the result is stable after reopening or reconnecting. A screenshot alone is weaker than a record that includes the input, setting, action, output, and time.

Checkpoint 9: Edition and handoff boundary

For “Edition and handoff boundary”, distinguish a product decision from an operating-system, hardware, source-file, permission, or workflow boundary. Confirm which layer supplied the evidence before assigning a cause. This prevents a nearby symptom from being reported as a proven root cause.

Checkpoint 10: Session QA

Use “Session QA” to define a pass/fail statement that another operator can repeat. Include what should be present, what must be absent, and what recovery action is safe if the check fails. Keep the original project or capture unchanged until the repaired copy has passed the same check.

Acceptance matrix

Checkpoint	Evidence to retain	Pass condition
Save, Reopen, and Compare USB Capture Sessions	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
How to save USB captures as .bscope sessions, reopen them for review, and compare sessions to identify differences betwe	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Save a session	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Reopen a session	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Compare sessions	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome
Direct answer: preserve comparable evidence	Initial state, one action, and resulting state	A second operator can reproduce the stated outcome

Failure isolation, recovery, and handoff

If a check fails, stop at the first failed boundary. Preserve the source, project, session, or capture; duplicate it before destructive editing; and change one variable per experiment. Repeating a broad workflow after several simultaneous changes may produce a different result without explaining why.

Separate absence of evidence from evidence of absence. A blank view may mean the wrong input, scope, filter, permission, device, time range, or project state rather than “nothing happened.” Verify the acquisition or import path before interpreting a decoder, editor, report, or export.

Before handoff, reopen the durable artifact and inspect its beginning, the decision point, and its end. Record version, platform, relevant configuration, expected behavior, observed behavior, and the smallest reproduction. Remove or redact sensitive material and confirm the recipient is authorized to receive it.

Questions and answers

What is the fastest reliable way to start?

Use the smallest representative case, write down the expected result, and change one variable. Confirm the basic path before adding filters, effects, edits, automation, or a larger source. This creates a baseline that can be compared after every later decision.

What evidence should be saved?

Keep the input identity, application version, platform, relevant settings, exact action, first unexpected transition, and final output. If the workflow creates a project, session, report, or export, close and reopen it before treating it as durable evidence.

When should the procedure be repeated?

Repeat it after an application, operating-system, driver, firmware, model, source, or workflow change that can alter the result. Preserve the earlier accepted case so the comparison uses the same acceptance boundary rather than memory.

When is the task ready for handoff?

It is ready when another authorized person can identify the input, repeat the action, see the same result, understand any remaining limitation, and open the saved artifact without relying on undocumented local state.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: