Brave cause wifi adapter to kill itself

[gznero]

I have an issue with the wifi adapter (Realtek RTL8852BE) that it keeps disconnect the wifi signal time-to-time when watch Youtube Live stream using Brave. I have generated the report for WLAN and the issue points at Error 8003 that the driver disconnecting the connection by itself. The range of disconnection period is very wide, starting from 5 mins to 1 hour-ish which during this range, the connection can be disconnected at anytime. What I can do is only disable the adapter and re-enable it to turn it back on or it won’t come back ever.

I have tried many methods including uninstall the device from Device Manager and install the latest Wifi driver that manufacturer has, change Wifi range from BE to AX, disable the roaming sensitivity, disable the power management to stop the device to save power, etc., none of these working. However, with finally testing the livestream session on FIrefox which do not cause this issue so it turns into conclusion that Brave browser causing the adapter to kill itself for whatever reason, I don’t know.

However the timing of I turned using Brave and Windows forced itself 25H2 on my device is very unclear that when exactly and which comes first. (Due to 25H2 cause a lot of problems on my device lately so I don’t know if this is one of them, or it is Brave itself only)

And as mentioned, the issue starts only when I watch Live stream, doing anything else is fine and no disconnection whatsoever, so what can I do about this?

---

Description of the issue:
How can this issue be reproduced?

1. Open livestream (Youtube/Twitch) on Brave Browser Desktop.

2. During 5 mins to 120-ish mins the adapter will kill itself eventually.

Expected result: The wifi adapter doesn’t kill itself after watching livestream/do a livestream, can join or perform the session from start to end.

Brave Version( check About Brave): Brave 1.89.143

Additional Information:

• Wifi adapter - Realtek RTL8852BE
• Windows 11 – 25H2

[MasterLink]

A web browser, can NOT kill a wireless adapter. A faulty Windows update however can.

Reason: NOTHING, and I mean nothing Brave does, installs or touches, have anything to do with the adapter itself, ONLY the TCP/IP stack. In 30 years of my Internet based computing (we got the “Internet” officially when it first was available coming from Prodigy and BBS’s), that would truly be a first for a web browser to kill hardware of any kind.

If the adapter is not working, you need to chase something else, namely Windows 11 25H2 which was the first for Windows to move to a kernel that contains Rust. And it hasn’t been entirely smooth.

My Mediatek wireless AND Bluetooth adapter both borked themselves with 25H2, requiring a complete driverstore removal and reinstallation to bring it back.

[gznero]

The WLAN report shows error 8003 which Driver stopped the adapter. This error does not happened in doing anything else on brave including watching Youtube by just video playback. Live stream however, cause this issue frequently and in very annoying way which on Firefox, it does not kill the adapter and can prolonged for long sessions without disconnection. Live stream on Brave cannot sustain more than 2 hours-ish time, sometimes disconnect every 5 minutes for 2-3 times before going for 30-40 mins and start disconnecting again. While on Firefox, 6 hours straight and no problem.

I’m not trying to be stubborn, but with this test result, what can I think for anything else?

It could be true, sure, but I want the exact reasons first what cause this and why this issue only appears on Brave.

And to confirm again, my attempt on uninstalling the device and reinstalling the drivers, does not solve the issue on my end.

[winui64]

MasterLink already gave a reply, but I’d like to offer a “first-step diagnose”, if you could call it that.

1. Can you try the exact same steps on Chrome/Chromium? Who knows, it might could be a Chromium issue?
2. Do you have any other Windows devices, Ethernet cable (even if you pair the ethernet cable with a USB adapter) that you can use for testing purposes?
3. Even if you don’t use ethernet, you could try the same steps in a virtual machine. I don’t know your technical expertise, but based on your inital post, I assume you can figure it out.
   1. Install Vmware Workstation or Virtualbox.
   2. Download the lastest Windows ISO file.
   3. Open Vmware or Virtualbox.
   4. General instructions:
      1. add your ISO file,
      2. start the VM,
      3. select Windows 11 Pro,
      4. “I don’t have a product key”,
      5. choose the drive,
      6. Install, Restart,
      7. Enter Out-of-box experience,
      8. add keyboard settings,
      9. Follow these instructions to create a local account: https://www.elevenforum.com/t/a-new-way-to-create-a-local-user-account-better-than-oobe-bypassnro.34784/
      10. Turn off all the data collection stuff
      11. Open Edge and download Brave.

I’m going to try this on a test subject laptop and let you know what I find.

I’m sorry if this doesn’t progress to a solution, but we can give it a try.

[289wk]

Suggest getting some other Wi-Fi device and test.

[gznero]

Sorry for late reply.

I have done 2 tests, the results are:

1. Exact same steps on Chrome does not cause the driver to kill wifi adapter, I did open livestream on Youtube for 10 hours and it has no problem. I try using Brave just few hours ago, can stay only 30 mins.
2. Ethernet seems not having issue with this, it seems to run normal except some hic-ups then and there which other browsers did not have. However, the testing time is around 1-2 hour-ish. (as I cannot stay in the space that can plugin LAN cable for long so I cannot use this as an problem solving method)

Hope this gives you some information. I know this is very unusual, but these are what I can do for now. Thanks.

[winui64]

I only saw your message just then. Thanks for your reply. I’d probably ask @Mattches and see if he has any solution for you.

Can you try clean installing your Wifi driver? I’d recommend getting the driver from your computer manufacturer or Realtek.

[gznero]

The tests I have done are already under clean installed and latest WIfi driver with computer manufacturer environment.

Thanks.

[289wk]

@gznero

Why does Brave’s traffic trigger the driver failure while Firefox does not?

What ChatGPT has to say:

---

Why it happens more on Brave

Different browsers use different networking stacks and optimizations:

• Brave (Chromium-based):

• • Uses aggressive hardware acceleration
• • Uses QUIC protocol (HTTP/3 over UDP) by default
• • More parallel connections / buffering for streaming

• Firefox:

• • Different networking stack (Necko)
• • QUIC behavior differs and is sometimes less aggressive
• • Often more tolerant of flaky drivers

Live streaming (especially long sessions) stresses:

• sustained throughput
• buffer management
• UDP traffic (QUIC)

That combination can expose a buggy Wi-Fi driver.

---

Most likely root causes

From experience, error 8003 during heavy streaming usually comes from:

1. Outdated or unstable Wi-Fi driver
2. Power management resetting the adapter
3. QUIC/UDP handling issues in the driver
4. Thermal or firmware instability in the adapter
5. Router compatibility quirks (less likely since Firefox works fine)

---

What to try (in order of impact)

1. Update or reinstall Wi-Fi driver (most important)

( you did that )

---

2. Disable power saving on the Wi-Fi adapter

• Device Manager → Network Adapter → Properties → Power Management
• Uncheck: “Allow the computer to turn off this device to save power”

Also: Windows Power Plan → set to High Performance

---

3. Disable QUIC in Brave (very relevant for streaming)

This is a big one. In Brave:

1. Go to: brave://flags
2. Search: QUIC
3. Disable: Experimental QUIC protocol

Restart browser.

This forces Brave to use TCP instead of UDP, which many unstable drivers handle better.

---

4. Turn off hardware acceleration in Brave

• Settings → System → disable: Use hardware acceleration when available

This reduces GPU/network pipeline stress.

---

5. Check advanced adapter settings

In Device Manager → Adapter → Advanced: Try:

• Disable *802.11ax (Wi-Fi 6)**rarily
• Set Preferred Band = 5 GHz
• Reduce Roaming Aggressiveness
• Disable Throughput Booster / AMPDU (if present)

---

6. Compare behavior on Ethernet

If possible: Use wired connection

If the issue disappears completely:

• Confirms it’s 100% Wi-Fi driver/hardware related

---

7. Check Windows Event Viewer

Look for:

• “Netwtw” (Intel)
• “rtwlane” (Realtek)

Frequent resets = driver crash loop.

---

Why Firefox works fine - likely:

• Uses less aggressive buffering
• Handles QUIC differently or falls back sooner
• Generates traffic patterns that don’t trigger the driver bug

So it’s not that Firefox is “better”—it’s just not hitting the same failure path.

---

Bottom line

This is almost certainly: A Wi-Fi driver instability exposed by Brave’s networking behavior (especially QUIC + streaming).

---

[Mattches]

@gznero have you only seen this occur on one specific machine?

[gznero]

From the list you mentioned from ChatGPT.

Step 1 - 6, I have already done that.

7. For Event Viewer, I don’t see any “rtwlane” error. The error I saw is only mentioned about HttpEvent but the time that error happened is not matched with WLANreport time that stated when the disconnection is happened. (9:07 PM vs. 9:26 PM) And there is no Error or Warning during 9:26 PM time in the Event Viewer.

Hope this data can provide you more information.

Thanks.

[gznero]

I did not test on other machines since I have only one. I have Brave on my iPhone but I do not think the test on iPhone is gonna do anything with desktop version.

However, if you think it could, I could test for you.

[289wk]

@gznero

Go to ‘brave://settings/extensions’ and Disable Media Router

Your Local Area Network (“LAN”) router to the world? That device’s log ← what does it show around the time of, preceding, your Wi-Fi adapter’s demise de jour?

---

Meanwhile, if you are willing …

Some preparation for gathering Brave Browser network log info. In a Brave Browser New Window, go to ‘brave://net-export’ ← That is where you will find the button to click and “Start Logging to Disk” ← capturing the Brave Browser network log.

When you click the button, you will be prompted to download a file named ‘chrome-net-export-log.json’ and the network logging will commence to write to that JSON file until you return to the same ‘brave://net-export’ page and stop the logging.

When you stop the logging, you can upload the ‘chrome-net-export-log.json’ file at ‘https://netlog-viewer.appspot.com/’

When the file is uploaded, in the subsequent window at the site, you will see on the left, a list of selections:

Select ‘Events’. A chore for you, is to discover the portion of events, close to when the Wi-Fi adapter quits. My guess is, somewhere approaching “the end of reasonable events?”

When you click on the tiny checkbox at the left of an event, a detailed window will display to the right of the event. You will see info like ‘t=63657’ ← is the time [probably] in milliseconds since the Start Time ← that is stated near the top of the event details - example: ‘Start Time: 2026-05-05 21:53:53.714’

The general idea here, is that you might identify a repeating pattern. And maybe (repeat, maybe) you will have something to compare with the LAN router log.

[gznero]

Update

I did have Wifi card replaced (same model however, because the manufacturer refuse to change the model at this moment due to still under their waranty). It dies immediately after I go watching live stream for 10 mins.

However, I just saw your comment so I just disable Media Router just at this moment and logging the net-export thing. Let’s see if it still kills the adapter and get something in the log.

Thanks

[289wk]

@gznero

Might have an effect: Brave Browser > Developer Tools > Network window. Opening that, and leaving it open, can (or seems to) slow down the “back and forth” of Request/Response (browser/website) traffic. In other words, sort of provides a tiny bit of breathing space that may allow some process “time to think.”

Sometimes, in that window, I also Enable the ‘Disable cache’ button.

---

Re another Wi-Fi adapter, I was thinking along the lines of a USB device, something like:

‘https://www.amazon.com/1300Mbps-Wireless-Adapters-802-11ac-10-6-10-15/dp/B08GM5FJ96’

for test purposes.

[gznero]

Hi,

I have able to log the period that the adapter dies into the ‘brave://net-export’.

Can I send it to you privately through DM, E-mail, or something?

[289wk]

@gznero

My view, for now -

A) You can generate a comprehensive HTML report by running the command netsh wlan show wlanreport ← which logs connection attempts, authentication details, driver events, and power states for the past few days. The resulting report written to file wlan-report-latest.html at: C:\ProgramData\Microsoft\Windows\WlanReport\wlan-report-latest.html

B) In a Brave Browser New Window, you can go to brave://net-export ← That is where you will find the button to click and Start Logging to Disk ← capturing the Brave Browser network log. When you click the button, you will be prompted to download a file named chrome-net-export-log.json and the network logging will commence to write to that JSON file until you return to the same brave://net-export page and stop the logging.

C) Thus, you would have 2 files with valuable diagnostic information:

• wlan-report-latest.html
• chrome-net-export-log.json

… that would be useful in the hands of Brave Support.

---

Useful, if Brave Support is willing to spend resources and time on a setup that duplicates yours exactly or “close enough” to:

• Wi-Fi adapter (Realtek RTL8852BE)
• Brave Browser setup
• Network connections and conditions
• LiveStream source
• and more

In attempts to replicate what you experience, in order to effectively and indirectly try and correct an issue of your Wi-Fi adapter. And, such attempts probably requiring several trial-and-error sessions.

Your two files would be useful. The ‘wlan-report-latest.html’ file definitely indicating the moments when the Wi-Fi adapter fails, and the ‘chrome-net-export-log.json’ file providing additional info at time-frame of plus-and-minus 30 seconds surrounding those moments.

But, would Brave Support / some one or more Brave developers be willing to undertake all that? (If my view, or estimate of the situation, is a close guess.)

I ran step (A) above, and the resulting “wlan-report-latest.html” file shows:

Event ID 8003 (not “Error 8003”)
WLAN AutoConfig service has successfully disconnected from a wireless network.

And all I did was visit the Brave Community, during which visit, my Broadcom Wi-Fi adapter quit … and then was recovered:

What do you think?

[gznero]

Hi,

I have both of them… the thing is I am asking the way to send you the files “privately” so I don’t need to upload my file publicly here.

Thanks.

[289wk]

@gznero

My last reply, is the case I would present to Brave Support. They might take up your case, or not.

Your case is up to you, to present to them. They would provide a private way to upload files - via a Direct Message (“DM”) or e-mail address.

[gznero]

Oh… I see, I thought you’re one of the support, sorry. But thank you for the update!

Now I have to wait and see eh…