Solved Windows 11 Laptop Taking 4 Minutes to Connect to Wireless Network

Thanks for the additional info JeFtFotF. Do you happen to know *which* specific drivers got reverted in your restoration of the "Intel driver update"? Did that update include the driver for the wifi adapter? Motherboard? The Dell Inspiron 15 3511 laptop that I was helping my neighbor with has a *RealTek* wifi adapter (not sure of the exact model, as I don't have access to the computer at the moment). What brand of wifi adapter is in your system?

Tom

JeFtFotF said:

I noticed a similar issue on our Dell XPS 8960 that started about a week ago, although the delay was about 2 minutes vs the previous 5 seconds or less. I did a search and found this thread, which is one of the most detailed and well written that I have seen in a long time.
I checked a few things and chose to uninstall the Intel driver update 24.40.0 that was released on 28 Apr, and reinstalled 24.30.1 via the Intel Driver & Support Assistant. Afterward, I shut the computer down for about 10 minutes, and when I restarted, the WiFi connected almost instantaneously again.
Thank you for the inspiration that grew from the thorough discussion, testing, and reporting.

Click to expand...

Interesting... I'm running 24.40.0.4 now, after all of my trials and tribulations (and Windows reset). Moreover, simply changing drivers did not solve my problem. I even went to the trouble of ensuring a "clean" driver installation by deleting all the wifi adapter drivers from Windows so it couldn't automatically install one when I uninstalled a driver. It made no difference to my delay.

My delay issues began with about a 2 minute delay and grew over the course of a week or so to 4+ minutes.

It sounds like your problem might be different from mine.

That would not be surprising to me either. Beyond using a different, but similar, system, some of the detailed symptoms are different. And I do not know the inner workings of these drivers.

Tom, I will look for answers to your questions and reply here.

sartor,

Our Dell XPS 8960 has an Intel Killer Wi-Fi 6E AX1675 adapter. The current Wi-Fi driver version is 23.160.0.4, dated 21 Jul 2025, per Device Manager and Intel’s Driver & Support Assistant. The driver I uninstalled was version 24.40.0.3, dated 28 Apr 2026. Both versions included drivers for the Wi-Fi adapter (and Intel Bluetooth) per the webpages and release notes. Neither the webpages nor the notes mention the motherboard.

I was not as accurate as I should have been in my previous statement about “…reinstalled 24.30.1…” The download file for that version has that number in the filename but that particular ID was for the Intel Bluetooth component of that update, not the Wi-Fi component.

Thanks for the follow-up JeFtFotF...glad you got your's working well again. I'm guessing that I might have a different issue with my neighbor's computer, given that she's got a RealTek wifi adapter, and not Intel. I'm going to try disabling the "wifi direct" service, which I believe is for the cellphone connection to the printer, and see if that might be interfering. I'll also try checking the "Event viewer" that Slavic suggested, to see if there are any clues there. And I want to double-check to see if the WLAN AutoConfig service indicates "running" even during the 4-minute delay period. I'll report back once I'm able to check those things. Still hoping to find a solution short of a full Windows Reset.

Tom

This issue is driving me nuts on a Vostro P106F but I have more info. If you watch task manager at boot, is Background Task Host hitting "Suspended" status immediately after the desktop displays, and staying suspended right until you can use WiFi functions? This is what's happening for me as of this week... It seems like this isn't actually a WiFi bug. Instead, it something that is throwing the Background Task Host into suspended status before it does the background tasks of invoking the services waiting behind it -- including those related to the network stack.

I had a very similar “Windows 11 takes minutes before Wi-Fi becomes usable / login feels stuck” issue and found a cause I had not seen mentioned in the usual Wi-Fi-driver/router/network-reset advice.

In my case the Wi-Fi adapter and router were not the root problem. Once Windows actually released the logon/session path, WLAN connected almost immediately.

Symptoms:
- After reboot, Wi-Fi was not usable at the sign-in screen.
- After entering PIN/password, Windows sat on the spinning dots / pre-desktop phase for about 2-3 minutes.
- Once the desktop appeared, Wi-Fi connected almost immediately.
- Network resets, Intel Wi-Fi mode changes, startup cleanup, and testing with a local account did not fix it.

What finally identified it:
Winlogon logs showed authentication succeeded quickly, but Winlogon event 12 / desktop release was delayed by about 168 seconds.

Services diagnostics showed `camsvc` (`Capability Access Manager Service`) was requested at the same time and only reported fully running right before Winlogon resumed.

The culprit was:

C:\ProgramData\Microsoft\Windows\CapabilityAccessManager\CapabilityAccessManager.db-wal

That file had grown to about 58 GiB. After stopping `camsvc`, deleting only:

C:\ProgramData\Microsoft\Windows\CapabilityAccessManager\CapabilityAccessManager.db-wal
C:\ProgramData\Microsoft\Windows\CapabilityAccessManager\CapabilityAccessManager.db-shm

and then starting `camsvc` again, the next reboot was fixed.

Before cleanup:
- Auth success -> desktop release: ~168 seconds
- WLAN connected only after that

After cleanup:
- Auth success -> desktop release: ~0.7 seconds
- WLAN AutoConfig started before authentication
- Wi-Fi connected immediately afterward

So if someone has the same “Wi-Fi takes minutes after reboot” or “login spins for minutes before desktop” pattern, it may be worth checking the size of:

C:\ProgramData\Microsoft\Windows\CapabilityAccessManager\CapabilityAccessManager.db-wal

Notes:
- Do not permanently disable `camsvc`.
- I did not delete the main `CapabilityAccessManager.db`.
- The folder is protected; normal admin access may not be enough. I used a temporary SYSTEM scheduled task to do the cleanup.
- This may not be every delayed-Wi-Fi case, but it exactly matched mine.


I also made a small PowerShell helper for my own machine. I’m not posting it as “random script from the internet, just run this”, but the shape of it was:

- Run from an elevated PowerShell window.
- Create a temporary scheduled task running as SYSTEM, because the folder is SYSTEM-owned.
- Stop `camsvc`.
- Delete only `CapabilityAccessManager.db-wal` and `CapabilityAccessManager.db-shm`.
- Start `camsvc` again.
- Log the before/after file sizes.
- Delete the temporary scheduled task.

The important part is not the script itself, but the diagnostic: check whether `CapabilityAccessManager.db-wal` is huge and whether `camsvc` startup lines up with the Winlogon delay.

If anyone wants the exact PowerShell helper I used, I can share it, but I’d strongly suggest reading it first and only running it elevated if you understand what it does. I don't want any trouble. I'm here to help, after 2 days of pain trying to fix this and nothing I found on the internet helped.

I had a problem with my Ultrabook wireless being slow and frequently disconnecting. Updating the wireless driver resolved the issue.

tao said:

If anyone wants the exact PowerShell helper I used, I can share it, but I’d strongly suggest reading it first and only running it elevated if you understand what it does. I don't want any trouble. I'm here to help, after 2 days of pain trying to fix this and nothing I found on the internet helped.

Click to expand...

There's actually a long, deep dive on the out of control size of the CapabilityAccessManager DB, but it's not written from the perspective of a "Wi-Fi" problem.

Out of Control Capability Access Manager.db-Wal File Size

TLDR: It's believed MS knows there's a bug, and maybe it'll get fixed by the June 2026 Preview (?)

The author also provides a fix script on GitHub:
ProactiveRemediations/CapabilityAccessManager Cleanup/CapabilityAccessManager-Remediation.ps1 at main · AzureToTheMax/ProactiveRemediations

tao said:

I used a temporary SYSTEM scheduled task to do the cleanup.

Click to expand...

You could overwrite the ownership and add the user "Administrators" with full access for working with content in the future. I do this with folders which have unreasonably strict security (quite rarely, however).

Right after I reset Windows, my laptop connected to my wifi immediately upon reboot. Now, it does not connect until after I logon with my finger print. It only takes 5 seconds or so, but it's definitely slower than it was after the reset.

I attempted to access the CapabilityAccessManager to check the size of the files, but Windows denied access and sent me around the mulberry bush to gain access. I gave up. Is there an easy way to access that folder to check the file sizes?

A safer way to get SYSTEM or TrustedInstaller rights is to use PowerRun. You can open an elevated CMD or PS window, and have full access without having to tamper with file ownership or permissions.

PowerRun v1.8 (Run with highest privileges)

I ran an elevated command prompt and got the following results:

C:\Windows\System32>dir "C:\ProgramData\Microsoft\Windows\CapabilityAccessManager"
Volume in drive C is OS
Volume Serial Number is CAAE-7D7B

Directory of C:\ProgramData\Microsoft\Windows\CapabilityAccessManager

File Not Found

So, it looks like the @tao identified doesn't exist on my computer. I'm not fussed about 5 seconds to connect after login, I'm just curious if something is going wrong after the reset. If something is going wrong, I guess it can't be with that file.

You didn't run PowerRun. For security reasons, some Windows folders or files are protected by TrustedInstaller rights, which is distinct from having normal Admin rights. The whole point is to prevent Admins (like you) from tampering with critical files.

Everyone has this database, it manages rights for camera, microphone and location services.

Ah, OK. Here are the result of running the dir command in PowerRun:

Directory of C:\ProgramData\Microsoft\Windows\CapabilityAccessManager

05/06/2026 02:11 PM <DIR> .
05/06/2026 02:22 PM <DIR> ..
03/10/2026 08:52 AM 88,891,392 CapabilityAccessManager (1).db
05/06/2026 01:39 PM 383,025,152 CapabilityAccessManager (1).db-shm
05/06/2026 01:53 PM 197,247,175,392 CapabilityAccessManager (1).db-wal
05/08/2026 08:19 AM 3,145,728 CapabilityAccessManager.db
06/13/2026 10:16 AM 14,745,600 CapabilityAccessManager.db-shm
06/13/2026 10:37 AM 7,585,286,712 CapabilityAccessManager.db-wal
05/05/2026 07:06 PM 1,048,576 CapabilityConsentStorage (1).db
05/06/2026 01:39 PM 32,768 CapabilityConsentStorage (1).db-shm
05/05/2026 07:06 PM 156,592 CapabilityConsentStorage (1).db-wal
06/12/2026 03:29 PM 1,048,576 CapabilityConsentStorage.db
06/13/2026 09:18 AM 32,768 CapabilityConsentStorage.db-shm
06/12/2026 03:29 PM 168,952 CapabilityConsentStorage.db-wal
12 File(s) 205,324,758,208 bytes
2 Dir(s) 620,713,906,176 bytes free

So it looks like the .db-wal file is pretty large! Is that 197 GB or am I reading it wrong?

183 GB. Download the script in post #110.

Now from the same TI-elevated CMD, run:

I'm not an admin, so I'm a bit hesitant to do as you describe above. If the risk of running this script is low, then I'll do it. Right now, I'm not experiencing any problems with my computer, although 183 Gigs of wasted file space will be noticed at some point. I have a 1T drive.

What is TI-elevated CMD? Does that mean I enter the Powershell command into the PowerRun app? What should I expect to see after running this script? Will running this script stop the uncontrolled growth in the size of this file, or will that have to await Microsoft's fix of the underlying problem? Was this file huge when I reset Windows; i.e., did Windows end up copying it over in the reset process, or has it grown from nothing since the reset?

I started reading the script developers GIT hub entry, but it is largely over my head.

Thanks for any additional help before I run the script.

PowerRun exists for one reason, to open a CMD or PS window with TrustedInstaller rights. You can't tell the external difference between a CMD or PS running with TI rights vs. Admin. They're both the same shells, but the running permissions are different.

In order to run the cleanup script, it needs to have TI rights, which PowerRun grants to the shell you opened. The script shutdowns the background services, deletes the SQLite database log file, and restarts the services. The script will not stop the database from growing again. It's a bug, and supposedly MS may be fixing it in a month or two.

Running the cleanup may tide you over for a while until the bug fix arrives this summer. You might need to run it again, if you're experiencing a slowdown.

Why does this bug affect you? Wi-Fi as implemented by Windows is tied with Location Services. In the absence of GPS support, Windows tries to guess where you are based on sniffing nearby Wi-Fi networks. Part of this overhead is logged into the CAM for tracking privacy events. When the CAM database grows to a staggering length, the process to initialize the Wi-Fi takes a long time. But the database isn't invoked by Wi-Fi after it gets going, so you only experience a delay on startup.

You're a victim of this bug. 183 GB is super bad in terms of growing too large.

OK. I get it. Thanks!

When I go to the Git Hub site and select download, the file has a .txt type, not a .ps1 type. Am I doing something wrong? I'm unfamiliar with how git hub works.

Again, thank you.