# Bug Report: Black screen when overwriting screen share (Error 6205)

**URL:** <https://devforum.zoom.us/t/bug-report-black-screen-when-overwriting-screen-share-error-6205/141760>\
**Category:** Web\
**Created:** [February 9, 2026, 4:16am UTC](https://devforum.zoom.us/t/bug-report-black-screen-when-overwriting-screen-share-error-6205/141760 "2026-02-09T04:16:13Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Thong1](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/thong1/32/69093_2.png) [@Thong1](https://devforum.zoom.us/u/Thong1)\
**Post date:** [February 9, 2026, 4:16am UTC](https://devforum.zoom.us/t/bug-report-black-screen-when-overwriting-screen-share-error-6205/141760/1 "2026-02-09T04:16:13Z")

</div>

## Bug Report: Black screen when overwriting screen share (Error 6205)

### Environment

- **Zoom Web SDK Version:** v2.2.12
- **Browser:** Microsoft Edge v144
- **OS:** Windows 11
- **Error code:** 6205 (from browser console)

* * *

### Pre-conditions

- At least **1 Host and 2 Guest users** join the same meeting.
- All users have permission to share screen.
- Security policy does not allow sharing Meeting ID or source code.

* * *

### Steps to reproduce

1. **User1 starts screen sharing.**  
→ User2 and User3 can see User1’s shared screen normally.

2. **User2 starts screen sharing without stopping User1’s share** (overwrite sharing).  
→ User1’s share stops automatically.  
→ User1 and User3 can see User2’s share.

3. **User3 starts screen sharing without stopping User2’s share** (overwrite sharing).  
→ User2’s share stops automatically.  
→ User1 and User2 can see User3’s share.

4. **User3 stops screen sharing.**

5. **User3 starts screen sharing again.**

* * *

### Actual Result

- **User2 sees a black screen** while screen sharing is active.
- Console log shows:e rrorCode: 6205
- Screen content is not rendered.

* * *

### Expected Result

All participants should be able to view the shared screen/tab correctly after screen sharing is overwritten by another user.

* * *

### Frequency

- **100% reproducible** with the above steps.

* * *

### Notes

- Issue occurs only when screen sharing is overwritten by another participant without manually stopping the previous share.
- Meeting ID and source code cannot be provided due to security restrictions.
- SDK logs can be provided if required.

---

<div class="post-metadata">

**Author:** ![vic.yang](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/vic.yang/32/24656_2.png) [@vic.yang](https://devforum.zoom.us/u/vic.yang)\
**Post date:** [February 9, 2026, 7:41am UTC](https://devforum.zoom.us/t/bug-report-black-screen-when-overwriting-screen-share-error-6205/141760/2 "2026-02-09T07:41:25Z")

</div>

Hey @Thong1

Thanks for your feedback.

> errorCode: 6205

Can you share which method threw the 6205 error? Also, what was the reason when this error occurred? Additionally, our sample app provides code to handle the related case — could you refer to this implementation?

> <https://github.com/zoom/videosdk-web-sample/blob/master/src/feature/video/components/share-view/single-share-view.tsx>

Thanks  
Vic

---

<div class="post-metadata">

**Author:** ![Thong1](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/thong1/32/69093_2.png) [@Thong1](https://devforum.zoom.us/u/Thong1)\
**Post date:** [March 9, 2026, 2:51am UTC](https://devforum.zoom.us/t/bug-report-black-screen-when-overwriting-screen-share-error-6205/141760/3 "2026-03-09T02:51:25Z")

</div>

Hello Zoom Support Team,

Regarding this issue, we would like to report and confirm a screen sharing problem that occurred after upgrading the Zoom Video SDK from **v2.2.5** to **v2.2.12**.

After the upgrade, we found an issue related to screen sharing behavior in meetings with multiple participants. We downgraded back to **v2.2.5** and confirmed that the issue no longer occurs there.

## 1. Issue summary

After upgrading from **2.2.5** to **2.2.12** , when multiple participants share their screens one after another without the previous sharer manually stopping sharing first, a participant may see a blank shared screen instead of the currently shared content.

## 2. Pre-conditions

- A meeting with multiple participants

- Minimum:

- In our reproduction scenario, we used 3 participants:

## 3. Steps to reproduce

1. user1, user2, and user3 join the meeting.

2. user1 starts screen sharing.

3. user2 starts screen sharing without user1 manually stopping sharing first.

4. user3 starts screen sharing without user2 manually stopping sharing first.

5. user3 stops screen sharing.

6. user3 starts screen sharing again.

## 4. Actual result

After user3 starts sharing again, **user2 sees a blank shared screen**.

## 5. Expected result

All participants, including guest users, should see the currently shared screen correctly.

## 6. Verification result

We downgraded the SDK from **2.2.12** back to **2.2.5** and confirmed that this issue does **not** occur in **2.2.5**.

Because of this, we suspect the issue is related to changes introduced between **2.2.5** and **2.2.12** (possibly starting from **2.2.10** ).

## 7. Our investigation

After reviewing the SDK package code, we suspect the issue may be caused by a logic change in `stopShareView()` introduced in **2.2.10** and still present in **2.2.12**.

### Behavior in SDK 2.2.5

In **2.2.5** , `stopShareView()` appears to always reset `isReceiveSharing = false` regardless of any other state.

Conceptually, it behaves like this:

```javascript
stopShareView() {
    if (!isReceiveSharing) return Promise.resolve("");

    mediaAgent.stopRenderSharing();
    rwgAgent.unsubscribeSharing(activeNodeId, isFromMainSession);
    dispatch(setIsReceiveSharing(false));
    return Promise.resolve("");
}

```

### Behavior in SDK 2.2.12

In **2.2.12** , `stopShareView()` appears to use `shareViewAttachments` and `activeNodeId` for cleanup, and `isReceiveSharing` is reset only when all attachments become empty.

Conceptually, it behaves like this:

```javascript
stopShareView() {
    if (!isReceiveSharing) return Promise.resolve("");

    const dummyElements = shareViewAttachments[activeNodeId]?.filter(e => e.isDummy) || [];
    if (dummyElements.length > 0) {
        dispatch(removeShareViewAttachment({ userId: activeNodeId, element: dummyElements }));
    }

    mediaAgent.stopRenderSharing();
    rwgAgent.unsubscribeSharing(activeNodeId, isFromMainSession);

    const updated = getState().share.shareViewAttachments;
    if (Object.entries(updated).every(([, arr]) => arr.length === 0)) {
        dispatch(setIsReceiveSharing(false));
    }

    return Promise.resolve("");
}

```

### Suspected root cause

Our current assumption is:

- `stopShareView()` now depends on `activeNodeId` to clean up `shareViewAttachments`
- if `activeNodeId` has already been reset or changed unexpectedly, then `shareViewAttachments[activeNodeId]` may be `undefined`
- cleanup does not complete correctly
- `isReceiveSharing` may remain stuck as `true`
- as a result, the next sharing session may not be rendered correctly for some participants, causing a blank screen

## 8. Important note about source code review

The SDK source downloaded from npm appears to be obfuscated, so actual variable and function names in the package are minified/obfuscated. Our analysis above is based on reverse investigation/mapping of the package logic, not on readable original source code.

## 9. Our proposed workaround / fix

Our current workaround is to call:

- `stopShareView()` **before**
- `startShareView()`

The intention is to ensure that the previous share receiving state is fully cleaned up before starting a new share view.

## 10. Our impact assessment of this workaround

At the moment, we believe this workaround is safe because `stopShareView()` in SDK **2.2.12** appears to have a safe early return:

```javascript
if (!isReceiveSharing) return Promise.resolve("");

```

So our understanding is:

- if cleanup has already completed successfully and `isReceiveSharing = false`, then calling `stopShareView()` again should do nothing
- if cleanup did not complete successfully and `isReceiveSharing = true`, then calling `stopShareView()` first should help remove stale state and reset the sharing state before `startShareView()`

## 11. Questions for Zoom

Could you please help confirm the following:

1. Is our suspected root cause correct?

2. Is calling `stopShareView()` before `startShareView()` the correct workaround?

3. Is there an official or recommended fix from Zoom for this issue?

4. Are there any required code changes or best practices that developers should follow when upgrading from **Video SDK 2.2.5** to **2.2.12** , especially for screen sharing flows?

5. Has Zoom identified any known issues related to screen sharing state cleanup in versions **2.2.10** to **2.2.12**?

We would appreciate your confirmation and any official guidance you can provide.

Thank you.

Best regards,

Thong

---

<div class="post-metadata">

**Author:** ![vic.yang](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/vic.yang/32/24656_2.png) [@vic.yang](https://devforum.zoom.us/u/vic.yang)\
**Post date:** [March 16, 2026, 9:27am UTC](https://devforum.zoom.us/t/bug-report-black-screen-when-overwriting-screen-share-error-6205/141760/4 "2026-03-16T09:27:03Z")

</div>

Hi @Thong1

Thank you for providing the detailed analysis.

This is indeed an issue we introduced in Video SDK **2.2.10** , and we will fix it in an upcoming release(v **2.4.0** ). The workaround you mentioned—calling `stopShareView()` before `startShareView()`—is a reasonable approach.

Thanks  
Vic

---

<div class="post-metadata">

**Author:** ![Thong1](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/thong1/32/69093_2.png) [@Thong1](https://devforum.zoom.us/u/Thong1)\
**Post date:** [March 17, 2026, 3:28am UTC](https://devforum.zoom.us/t/bug-report-black-screen-when-overwriting-screen-share-error-6205/141760/5 "2026-03-17T03:28:59Z")

</div>

Hi @vic.yang,

Thank you for confirming that this issue will be fixed in the upcoming v2.4.0 release.

In the meantime, could you please let us know if there is any way to completely resolve the black screen issue during screen sharing while using the current SDK version (2.2.12)?

We want to ensure the best possible user experience while waiting for the update.

Thank you again for your support.

Best regards,  
Thong

---

<div class="post-metadata">

**Author:** ![vic.yang](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/vic.yang/32/24656_2.png) [@vic.yang](https://devforum.zoom.us/u/vic.yang)\
**Post date:** [March 17, 2026, 8:11am UTC](https://devforum.zoom.us/t/bug-report-black-screen-when-overwriting-screen-share-error-6205/141760/6 "2026-03-17T08:11:03Z")

</div>

Hi @Thong1

> could you please let us know if there is any way to completely resolve the black screen issue during screen sharing while using the current SDK version (2.2.12)?

After further evaluating this issue, we found that calling `stopShareView` does not fully resolve it. The issue is caused by an internal state not being completely cleaned up when switching from the viewer role to the presenter role in the Video SDK Web.

We have already fixed this issue, but the fix will only be included in an upcoming release, which is scheduled for early April.

Thanks  
Vic