If Streamlabs Desktop is open, create a diagnostic report from Settings > Get Support > Upload Diagnostic Report, then copy its code into the Diagnostic Report Code field on Streamlabs’ support form. The code is the normal route for routine troubleshooting; a folder-sharing link is a fallback if the app cannot generate a report.
A report gives support information to investigate, but it does not prove what caused a problem or guarantee a fix. Share the code or fallback material only through the support request and only as requested. In particular, a public sharing link can be opened by anyone who has it.
When a diagnostic report is useful
Create a report when you are contacting Streamlabs support about an issue with Streamlabs Desktop and the application will open. It gives the support team diagnostic information alongside your description, so they can consider the app context rather than relying on a symptom summary alone. It is useful for problems such as an unexpected behaviour or a setting that does not work as expected, but it is not a verdict on the cause.
Before opening the form, note what you were doing when the problem appeared, when it began, and whether you can make it happen again. Add the relevant operating system and app version if you know them. A concise account such as “the preview goes black after I change scenes” is more useful than “it is broken”; include what you already tried, without guessing at a technical cause.
The report code is not the same as a screenshot. Streamlabs’ instructions specifically ask for the code in the form field and say not to substitute screenshots for it. You can attach a screenshot separately if support asks for one or it clearly helps explain what is visible, but it does not replace the report code.
Not every troubleshooting problem needs the same evidence. If a support form or support article asks for issue-specific details, follow that request rather than treating an example checklist as universal. For instance, a network or multistream issue may call for information beyond a standard Desktop report. If your problem is an interrupted broadcast, first note what drops and when; a guide to troubleshooting a 24/7 music stream that drops on Indian broadband can also help you separate a streaming-path symptom from a Desktop support issue.
Generate the report code in Streamlabs Desktop
Keep Streamlabs Desktop open and follow this route:
- Select Settings.
- Open Get Support.
- Select Upload Diagnostic Report.
- Wait for the upload to finish and for the report code to appear.
- Copy the code so you can paste it into the support request.
The wording of controls can change as the application is updated, but these are the documented steps. If the upload takes a moment, let it complete before leaving the page. Do not assume that opening the screen alone has generated a report: wait for the code, then copy the value shown.
Keep the code intact when copying it. Avoid retyping it from memory, trimming characters, or sending a cropped screenshot in its place. If the code is not displayed or the upload reports an error, do not invent a substitute; move to the fallback section below or explain in the support request that report generation failed.
The report is one piece of context, not a diagnostic conclusion. It may help support investigate alongside your description, but it cannot establish by itself that a particular setting, network, device or update caused the problem. If you are operating a continuous channel, record whether the issue occurs on the local preview, the broadcast, or both. Guides such as testing content themes on a 24/7 YouTube live stream address channel experiments, not Streamlabs diagnosis, so keep those questions distinct when you write the ticket.
Put the code in the support form
Open Streamlabs’ support request form, choose the relevant product or issue category, and complete the fields shown. The options can vary according to the category. Enter the copied value in the field labelled Diagnostic Report Code. Do not paste it only into a general description if the specific code field is available.
In the description, say what you expected, what happened instead, when the issue began, and the steps that reproduce it if you know them. Mention relevant environment details, such as your operating system and Streamlabs Desktop version, where the form asks for them or they help explain the problem. Stick to observations: “it began after I selected a different audio device” is safer and more useful than presenting that timing as proof that the device caused it.
Before submitting, check that the code is in the report-code field and that the description explains the symptom. A screenshot is not a replacement for the code, and a long description does not make a missing code appear. If the form rejects the code or the field is unavailable for the selected category, say so in the ticket and follow any directions the form provides.
You can consult Streamlabs’ documented report and cache-folder instructions alongside the form. These instructions describe the ordinary code route and the alternative when report generation is unavailable. The form and app labels may change, so check the current page rather than relying on a saved screenshot of an older version.
If report generation fails
First distinguish a failed upload from a missing code. If the Upload Diagnostic Report action is still running, allow it to finish; if it reports an error or no code appears, note what you observed. You can try again if the app remains responsive, but do not make repeated attempts indefinitely or claim a report was generated when you have no code to provide.
If Streamlabs Desktop will not open or the report cannot be created, use the documented slobs-client folder fallback in the next section. Tell support that you could not generate a report and are sharing the folder as an alternative. The fallback is not the preferred routine path when you have a working app and code.
Crash telemetry is a separate process. Streamlabs’ crash troubleshooting guide describes enabling additional crash reporting and then submitting information after a subsequent crash. If support asks for that workflow, follow its steps and provide the resulting filename as directed. Do not treat crash telemetry as interchangeable with the standard diagnostic report code or assume that a crash report is required for every support ticket.
For an issue that also involves a live broadcast dropping, distinguish that symptom from a Desktop crash in your description. A stream can be interrupted without the app producing a crash report, and the right evidence depends on what support is investigating. For example, a packet-loss and upload-limit check for an Ethernet stream may help you describe a connection symptom, but it does not replace the requested Streamlabs report.
Locate and compress the slobs-client folder
Use this only if the regular report is unavailable and support needs the fallback. Streamlabs’ instructions identify %appdata% as the Windows parent location and ~/Library/Application Support as the macOS parent location. From the relevant parent location, locate the folder named slobs-client.
On Windows, open File Explorer and enter %appdata% in its address bar, then look for slobs-client in the location that opens. On macOS, use Finder’s Go to Folder function and enter ~/Library/Application Support, then look for slobs-client. Folder visibility or the exact route through the file browser can vary, so follow Streamlabs’ current support instructions if the folder is not where expected.
Compress the folder if your computer offers that option, then upload the compressed file to a file-sharing service that lets the intended recipient access it. Keep the original folder unchanged. Do not delete it or rename its contents as a troubleshooting step; the purpose here is to provide the requested material, not to modify it.
Before uploading, make sure you have selected slobs-client, not a similarly named item or a broad parent folder containing unrelated files. A folder upload can contain more material than the short report code, so share it only when the documented fallback is needed. If you are unsure whether the requested folder is correct, ask support before sending additional files.
Share the fallback link carefully
Streamlabs’ documented fallback asks you to make the file-sharing permissions public so support can access the uploaded folder. “Public” is not the same as private to the support team: a link with public access can be opened by anyone who obtains it. Treat the link accordingly, and do not post it in a public forum, a channel description, or a social post.
Place the link in the support request where Streamlabs directs you to provide the fallback, such as the diagnostic field or ticket description when that is what the current instructions specify. State briefly that report generation failed and that the link is the slobs-client fallback. Send it only as part of the support request and do not distribute it beyond the intended support exchange.
Check that the link opens for the intended recipient without exposing it more widely than necessary. If your file-sharing service offers a way to revoke access, consider removing access when support no longer needs the file, while following any request to retain it for investigation. If the service requires a different permission setting or the support team cannot access it, ask for an approved alternative rather than assuming that the link is working.
A link-sharing service is a transport method, not a guarantee that the contents are private or that support can diagnose the issue. Do not include extra folders or files merely because they are easy to upload. The documented fallback is specifically the slobs-client folder, and sharing only what was requested reduces unnecessary disclosure.
Keep the evidence matched to the problem
Use the artifact that matches the support question. For an ordinary issue where Desktop opens, provide the report code. If the issue is a crash and support requests additional crash data, use the separate crash-reporting procedure. If the report cannot be produced, share the documented folder fallback as instructed. These paths are related, but they are not interchangeable.
| Situation | What to send | What to explain |
|---|---|---|
| Desktop opens and you can generate a report | The code in Diagnostic Report Code | What happened, when, and how to reproduce it |
| Support requests crash telemetry | The information or filename produced by the crash workflow | That you followed the crash-reporting steps |
| Report cannot be generated | A slobs-client folder link, following the documented fallback |
Why the normal report code is unavailable |
Give details that help someone understand the conditions: app version, operating system, relevant device or platform, and the steps immediately before the problem. Do not guess at a root cause or add unrelated system details to make the ticket look more technical. If the problem concerns audio on a continuous station, describing the device and when it changes is more useful than assuming the whole stream setup is at fault; the guide to routing a radio encoder into YouTube Live covers a different part of that broader workflow.
Streamlabs’ multistream troubleshooting article illustrates why evidence can depend on the issue: a particular network or platform problem may call for details beyond a standard report. Follow the request for your case, rather than treating its specialised checklist as necessary for every Desktop ticket. The aim is to provide the requested context clearly, not to upload every available file.
If your aim is simply to keep a fixed video running continuously, rather than troubleshoot Streamlabs Desktop, StreamNeo can remove the need to leave your computer running by turning an uploaded video into a YouTube live stream. It is a separate workflow, not a way to interpret a Streamlabs report or a replacement for support when you need help with the app.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does a diagnostic report identify the cause?
No. It supplies information for support to investigate alongside your description, but it does not prove what caused the issue or guarantee a fix. Describe what you observed and let support assess the available evidence.
Can I send a screenshot instead of the report code?
No, not when the form provides a Diagnostic Report Code field and asks for the code. A screenshot may be useful as separate context if support requests it, but it does not replace the report code.
What if Streamlabs Desktop cannot create the report?
Use the documented slobs-client folder fallback, compress it if possible, upload it to a file-sharing service, and share the link in the support request as instructed. Explain that code generation failed, and remember that public link access is not private to support.
Is the crash report the same as the diagnostic report?
No. Crash telemetry follows a separate workflow described in Streamlabs’ crash guide and may produce a filename to send after another crash. Use it when support asks for that crash information, rather than substituting it for the standard report code.