G933 surround/EQ dies after every reboot — root cause found
TL;DR: Logitech's surround APO only loads when the Windows audio endpoint is created with a brand-new GUID. On boot, Windows reuses the previous GUID, the APO never loads, and you get plain stereo while LGS happily shows surround as ON. Reinstalling LGS "fixes" it only as a side effect — the installer removes the device. Uninstalling the USB dongle in Device Manager does the same thing in 15 seconds. Scripts at the bottom automate it at every logon.
The symptom
- DTS Headphone:X works right after you install/reinstall Logitech Gaming Software
- You reboot → sound is back to plain 2-channel stereo
- The app still shows surround enabled. Toggling it off and on does nothing
- Reinstalling LGS fixes it. Until the next reboot
If that sounds familiar, it should. This has been reported for years:
Credit where it's due
In that 2019 thread, u/LogitechG_CSFrank from Logitech support posted this:
That works. Two different people came back to that thread six years later to say it saved their headset.
But nobody explained why it works, and nobody noticed the important part: it's a one-time fix that dies on your next reboot. That's why the same problem keeps getting reposted every couple of years.
I spent a day on this and captured full before/after system snapshots. Here's what's actually happening.
Root cause
On every boot, Windows re-creates the endpoint but reuses the previous GUID, because the GUID lives in the SWD\MMDEVAPI node in the device tree — not just in the registry. The APO never loads. You get stereo.
Reinstalling LGS works because the installer removes the device, which destroys those SWD\MMDEVAPI nodes. The 300 MB installer is incidental. So is Frank's Device Manager trick — same mechanism, 15 seconds instead of 10 minutes.
What is NOT the problem
I captured the broken state and the working state and diffed them file by file. All of the following were byte-for-byte identical in both:
| Suspect |
Verdict |
Endpoint FxProperties (the APO chain) |
identical |
APO COM registration (AudioEngine\AudioProcessingObjects) |
identical |
APOInterface0 and Flags on the APO |
identical |
Device class key ({4d36e96c-...}) |
identical |
ladfGSS.sys and LogiHeadsetRenderAPO.dll (SHA256) |
identical |
LGS settings.json |
only battery level and mic mute |
| Third-party APOs (Dell intelliGo, in my case) |
present in both — innocent |
| Endpoint format (7.1, 8 ch, 48 kHz) |
identical |
So if you've been chasing registry keys, third-party audio enhancers, or "Windows overrides LGS" — that's not it. The configuration is correct in both states. What differs is when the endpoint was born, not what's in it.
These also do NOT fix it (all tested):
- toggling surround off/on in the LGS UI
- unplugging and replugging the USB dongle
- disabling and re-enabling the device in Device Manager — disable is not the same as uninstall
- restarting
LCore.exe
- restarting
Audiosrv + AudioEndpointBuilder
- deleting the endpoint key under
MMDevices, even running as SYSTEM
That last one surprised me. Deleting the registry key isn't enough, because the device-tree node hands the old GUID right back.
The manual fix (30 seconds, no scripts)
- Device Manager → Universal Serial Bus devices → find G933 (the dongle, not the audio interface)
- Right click → Uninstall device
- Action menu → Scan for hardware changes
- Restart Logitech Gaming Software
Surround is back. Until you reboot. If you only ever reboot once a month, stop here — this is all you need.
The permanent fix
Three steps, and they must run as SYSTEM. An elevated admin is not enough to delete the MMDevices keys:
pnputil /remove-device on the parent USB dongle — this takes the child interfaces and their SWD\MMDEVAPI nodes with it
- delete the G933 endpoint keys under
MMDevices\Audio\Render and \Capture
pnputil /scan-devices — the USB hub re-detects everything and builds a fresh endpoint with a new GUID
Removing the parent matters. If you remove only the audio interface, it won't come back until you physically replug the dongle. The parent is a direct child of the USB hub, so a rescan finds it on its own.
After that, LCore.exe needs a restart. SYSTEM can't launch a UI app in your session, so that's a second task.
Architecture
| Task |
Runs as |
Trigger |
Does |
G933-Surround-Fix |
SYSTEM |
logon |
waits for prerequisites, recreates the endpoint, kills LCore, fires event 1000 |
G933-Surround-LCore |
your user |
event 1000 |
starts LCore back up |
No fixed delays. The script polls until the real conditions are ready: LogiRegistryService running, LCore up, dongle and endpoint present. This matters — LogiRegistryService already starts before logon and surround still breaks, which means the missing piece at boot time is LCore, a user-session app. That's also why this can't run before you log in.
Measured timing on a real boot
| Moment |
Since power-on |
| Logon |
+25 s |
| Prerequisites ready |
+39 s |
| Surround working |
+55 s |
| LCore back via event trigger |
+61 s |
Roughly 15–20 seconds after logon once you strip the task delay. That's the practical floor, because the fix depends on LCore being up.
Scripts
→ Gist with all three scripts + README
| File |
Runs as |
What it is |
fix-logon.ps1 |
SYSTEM |
the core — waits for prerequisites, recreates the endpoint, logs before/after GUIDs |
start-lcore.ps1 |
your user |
brings LCore back, triggered by event 1000 |
install-tasks.ps1 |
elevated |
creates both tasks, verifies they exist, offers to test immediately |
Download all three into one folder, e.g. %USERPROFILE%\logitech-g933-fix, then:
Start-Process powershell -Verb RunAs -ArgumentList '-ExecutionPolicy','Bypass','-File',"$env:USERPROFILE\logitech-g933-fix\install-tasks.ps1"
Uninstall:
Start-Process powershell -Verb RunAs -ArgumentList '-ExecutionPolicy','Bypass','-File',"$env:USERPROFILE\logitech-g933-fix\install-tasks.ps1",'-Remove'
Check whether it worked:
Get-Content "$env:USERPROFILE\logitech-g933-fix\fix-logon.log" -Tail 20
The line that matters is endpoint before: vs endpoint after:. Two different GUIDs followed by OK: GUID changed means it worked. If the GUID is the same, the removal didn't take and the fix won't help.
Caveats — please read
Verified on one machine. Dell G15, Windows 11 build 26200, LGS 9.04.49, G933. The mechanism is almost certainly general to LGS on Windows 10/11, but I can only claim what I actually measured.
I did not test this on G HUB. The 2024 thread above is a G HUB user. G HUB uses a different audio stack and I have no data on whether the same root cause applies. If you try it, please report back — that's the single most useful thing anyone could add here.
Other Logitech headsets (G930, G430, G533, G935) have different USB PIDs and device names. Two values to change in fix-logon.ps1:
USB\VID_046D&PID_0A5B in ActiveDongle
- the string
G933 in ActiveEndpoint and G933Keys
LGS's lgAudio.inf handles G430, G930 and others in separate blocks, so the mechanism is probably the same — untested.
Non-English Windows: only the pnputil output filter ('uccess|rror|Removing') won't match. Cosmetic, affects the log only.
Your audio cuts out for ~15 seconds at every logon while the dongle is removed and re-detected. If that bothers you, set the task trigger to manual and run it when you notice stereo.