The Wlansvc service cannot start.

First, collect evidence without changing Windows​

1. Clarify the installation history: Did Wi-Fi ever work in this installation? Did this begin immediately after installing build 29680.1000, an update, or VPN/security/Killer software? Is this an official Microsoft preview installation or a customized image? I could not verify a published Microsoft known issue matching this exact build and crash.
2. Open Terminal as administrator and run these diagnostic queries. Paste the results:
   
   Code:

   sc.exe qc WlanSvc
   sc.exe queryex WlanSvc
   sc.exe qc RasMan
   sc.exe queryex RasMan

   These inspect the service configuration and current status without changing them.
3. Check protected system-file integrity without performing repairs:
   sfc /verifyonly
   Post the final message, including any error if the check cannot complete. Microsoft documents /verifyonly as verification without repair.
4. In Event Viewer → Windows Logs → System, locate Service Control Manager errors at the same times as these crashes. Paste their General text, particularly any service-specific error or dependency failure. Also provide any accompanying Windows Error Reporting entry from the Application log.

• WlanSvc is configured for automatic startup.
• Both services exit with 1067, consistent with the application crashes you posted.
• The integrity check found no violations.
• The problem began with build 29558 and persists in 29680.

Next read-only checks​

1. Open PowerShell as administrator and run:
   
   Code:

   Get-WinEvent -FilterHashtable @{
       LogName='Application'
       ProviderName='Windows Error Reporting'
       Id=1001
   } -MaxEvents 50 |
       Where-Object { $_.Message -match 'WlanSvc|RasMan' } |
       Select-Object -First 4 TimeCreated, Message |
       Format-List

   Please paste the output. These reports may contain crash-bucket identifiers and locations of existing diagnostic files. If there is no output, say so.
2. Read the WLAN operational log:
   
   Code:

   Get-WinEvent -LogName 'Microsoft-Windows-WLAN-AutoConfig/Operational' -MaxEvents 15 |
       Select-Object TimeCreated, Id, Message |
       Format-List

   Post entries near the crash time, or the exact error if the log is unavailable. Redact network names and other personal information.
3. Confirm which VPN, third-party security, and Killer networking utilities are installed, and whether this is an official Microsoft Insider installation.

Check the installed networking components​

1. In PowerShell as administrator, run this read-only query to identify any Killer/Rivet services and whether they are running:
   
   Code:

   Get-CimInstance Win32_Service |
       Where-Object {
           $_.Name -match 'Killer|Rivet' -or
           $_.DisplayName -match 'Killer|Rivet' -or
           $_.PathName -match 'Killer|Rivet'
       } |
       Select-Object Name, DisplayName, State, StartMode, PathName |
       Format-List

   Paste the output, or say if it returns nothing.
2. Collect the installed adapter/driver details:
   
   Code:

   Get-NetAdapter -IncludeHidden |
       Where-Object { $_.InterfaceDescription -match 'Killer|AX1675' } |
       Format-List Name, InterfaceDescription, Status, *Driver*

   Microsoft documents Get-NetAdapter for inspecting networking driver information. This does not change the driver.
3. Please give the Intel Killer Performance Suite version shown in Settings → Apps → Installed apps, and clarify whether the hotspot attempt occurred before or after Wi-Fi first failed in build 29558.

Two remaining details​

1. Please provide the Intel Killer Performance Suite application version, if listed under Settings → Apps → Installed apps. Do not change anything there.
2. Did the Mobile Hotspot attempt happen before or after Wi-Fi first stopped working with build 29558?

Check for an existing crash report​

1. Press Win + R, enter perfmon /rel, and locate failures matching the WLAN AutoConfig or RasMan crash times.
2. Select a matching failure and open View technical details, if available. Paste the details, especially Problem Event Name, fault bucket, and any report identifier. If no matching failure appears, say so.

Temporarily stop the Killer background services​

1. Press Win + R, enter services.msc, and press Enter.
2. Stop Killer Network Service, Killer Analytics Service, Killer Provider Data Helper Service, and Intel Network Helper Service. If Windows requests stopping additional services, cancel and report which ones.
3. Confirm all four show no Running status. If any cannot stop or immediately restart, report that—the isolation test would be incomplete.
4. Right-click WLAN AutoConfig → Start. Report whether it stays running, fails immediately, or starts and then stops. Copy any error message.
5. If WLAN AutoConfig stays running, check whether Wi-Fi networks appear. Separately try starting Remote Access Connection Manager, and report its result.
6. Undo the test: start the four Intel/Killer services again. Their startup types should remain unchanged.

Check whether Windows already saved a report or dump​

1. Restart the four Intel/Killer services stopped for the test, leaving their startup types unchanged.
2. Open PowerShell as administrator and run this read-only check:
   
   Code:

   Get-ChildItem -Path "$env:ProgramData\Microsoft\Windows\WER\ReportArchive",
                       "$env:ProgramData\Microsoft\Windows\WER\ReportQueue" `
       -Directory -ErrorAction Continue |
       Where-Object { $_.Name -match 'WlanSvc|RasMan|svchost' } |
       Sort-Object LastWriteTime -Descending |
       Select-Object -First 10 LastWriteTime, FullName |
       Format-List

3. Paste the output, including any access errors. If a folder matches the latest crash time, open it and report the filenames inside—particularly any .dmp, .mdmp, or Report.wer files. Do not delete or modify them.

Check the existing dump configuration​

1. Open Terminal as administrator and run these read-only commands:
   
   Code:

   reg query "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps"
   reg query "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\svchost.exe"

2. Paste both results. “Unable to find the specified registry key or value” is a useful result, not a reason to create anything yet.
3. Check this folder in File Explorer:
   C:\Windows\System32\config\systemprofile\AppData\Local\CrashDumps
   Report whether it exists and contains any svchost.exe*.dmp files matching your crash times. This is the default dump location for a service running as LocalSystem, unless configured otherwise. (learn.microsoft.com)

Analyze a matching dump locally​

1. In the CrashDumps folder, select a dump whose Date modified matches a WLAN AutoConfig failure. Note its exact filename and timestamp.
2. Open Microsoft WinDbg as administrator. If it is not installed, install WinDbg from the Microsoft Store.
3. Use File → Open dump file to open that dump. WinDbg supports analysis of user-mode service dumps. (learn.microsoft.com)
4. In WinDbg’s command window—not PowerShell, run:
   
   Code:

   .symfix
   .reload
   !analyze -v
   .ecxr
   kv

   Allow symbol loading to finish. These commands configure debugger symbols, analyze the exception, and display the exception-context call stack; they do not change your networking configuration.
5. Paste the !analyze -v output and the stack from kv, along with the filename and timestamp. Include any symbol-loading or missing-memory errors rather than trying to fix them.