A useful support report identifies the recovery stage, exact error, application version, and source/destination situation without exposing an entire private file collection. Keep diagnostic material separate from recovered files. When a log is requested, use the file and location appropriate to your installed version rather than sending an unrelated Windows log or a guessed folder.
Start with the event you need explained
Describe what you expected and what happened instead. Useful examples include a device absent from the source list, a scan stopping with a read error, a supported file failing to preview, or an export failing on a particular destination.
Record the approximate time, XRecovery version, Windows version and architecture, source type/capacity, connection method, and the exact message. Include whether the source still appears in Windows and whether any file exported successfully. Keep observations separate from a diagnosis such as “the disk is dead” unless that has actually been established.
For an export problem, add the selected result’s size and the destination’s file system and free space. For a loading problem, identify whether the input was a saved scan result, raw disk image, or virtual disk image. These are different inputs and lead to different checks.
Preserve relevant diagnostic files
If your support contact requests a particular application log, use the path and file name supplied for your installation and version. Locate it in File Explorer, compare its timestamp with the event, and copy the requested file to a separate folder for your support report. Preserve the original diagnostic file while the question is open.
Use the exact diagnostic-file path provided by support for your installation and Windows account. If you do not know which log applies, send the basic event description first and ask the support route to identify the relevant file.
A Windows crash or event record may be useful if the issue actually concerns a crash or system access failure. Label it with its origin and collect only the requested time range. An unrelated full system history usually adds private information without explaining the recovery event.
Make a working copy before redaction
Keep a private original where appropriate and redact a copy for ordinary support exchange. Replace private account names, document names, paths, and unrelated device information with consistent neutral labels while preserving the technical relationship needed to understand the error.
Remove license codes, passwords, recovery keys, access tokens, and personal contents. A path such as SOURCE\ClientA\report.docx can demonstrate nesting without revealing the client’s identity. Keep sizes, relevant error codes, and event order intact when they explain the problem.
Do not describe a modified log as an untouched original. State that the attachment is redacted and identify any removed sections that may affect interpretation. If exact evidence is needed, agree on the authorized secure handling route before sharing it.
Choose screenshots and samples deliberately
Capture the relevant window and message, not an entire desktop with private applications visible. Redact file lists or account details outside the problem area. Show enough of the source/destination context to establish which device was selected.
A sample file can help with a format-specific issue, but use a small authorized non-sensitive example when one is requested. Do not substitute a different file and claim it reproduces the same failure without checking. Do not attach an entire disk image or private folder simply because a single file failed.
Send a report someone can follow
Organize the report as: task, source, destination, steps, observed message, time, and attachments. List what each attachment represents and whether it is redacted. Distinguish the actions you completed from suggestions you have not tried.
Use the official XRecovery support channel reached from the product website. Keep your source and verified exports intact while the issue is assessed. Do not repeatedly reproduce an error on unstable storage just to obtain a better screenshot or log.
For the next step, see XRecovery 4.0 Support: Find the Right Workflow for Your Next Step.