Rolling back to the August Patch seems to fix it for us – the camera works again in Teams and Windows Hello without crashing. We’re seeing the same issue you mentioned on some of our Dell 14 Pro Plus devices, with the Camera Frame Server crashing and causing the devices to freeze for a few minutes. This started around the September Patch. We have tickets open with both Microsoft and Dell, but for now the August patch rollback is the only reliable workaround for us while we work through it.

Using Latitude 7450, 5550, and Pro 14 Premium pa14250,

I tried the following and was unsuccessful
Regedit key for EnableFrameServerMode for

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Media Foundation\Platform

set to 0

Updating Camera driver to latest
Updating Graphics to latest
Latest Bios
Used Dell command update for any remaining updates

Windows 11 24H2 seems to be the OS with the most issues, devices on 23H2 are only experiencing slowness/lag at the start of a Zoom session, or any app that activates the camera. (this is weird on its own, but doesnt crash)

24H2 locks up the pc, errors seem to stop once camera is disabled, and when Windows Camera Frame Server Services are disabled.

Error logs for Windows Camera Frame Server error occur exactly at the time of the PC freezes
In our cases its a hard freeze for 2 minutes until it recovers, then happens over and over again while the camera is in use.

Devices that have not updated yet with the September patch are unaffected.
Rolling back the September update seemed to allow a test user to use the camera. Testing again once they reinstall the September Update.

Interestingly the August Update states that there were some issues with video streaming applications like OBS that do involve the camera that were "fixed" in the September update

Are you experiencing these issues on Ethernet connections? For us it seems to be the case that using wifi causes this, which makes it hard to troubleshoot. This is the only thread I found that talks about this issue, curious why others are also experiencing this.

We’re seeing almost identical behaviour here.

Rollback results are the same on our end - reverting to the August CU fixes it straight away. All drivers, BIOS, and firmware are fully up to date (confirmed again through Dell Command Update).

For us, it’s strangely more consistent when the device is on Wi-Fi and connected to VPN, though we’ve also been able to replicate it on ethernet, but this is super rare. Interesting that you’re seeing differences on 23H2 - we don’t have any 23H2 devices in production so I can’t confirm, but we’ve also been able to reproduce it on new 25H2 builds.

Our affected devices are Dell Pro Plus 14 models. We haven’t observed this behaviour on any of our older Dell devices. As part of troubleshooting, we’ve even rolled back camera drivers by a version or two but it still didn’t help.

Same pattern as you described - as soon as the camera is turned on during a Teams call, the device hard freezes for a few minutes, logs the Camera Frame Server event, then recovers… rinse and repeat. We’re also seeing it when Windows Hello facial recognition is used after the device wakes from sleep - it hangs for a few minutes, fails facial sign-in, falls back to PIN, and logs the same Frame Server event at the exact time of the freeze.

We can’t replicate the issue on a Dell OEM image, but it’s not really an equal comparison in a managed enterprise environment. We’ve got tickets open with both Microsoft and Dell and have supplied them with all the dumps and logs under the sun.

Have you raised cases with Microsoft and Dell as well?

Microsoft advised that the September CU simply "removed" the safeguard hold related to camera and unresponsive app behaviour - the one described here:

https://xtls-v4.hkg1.meaqua.org/en-us/windows/release-health/status-windows-11-24h2#3412msgdesc

They’ve said the underlying issue for that safeguard was already “fixed", and the September update simply lifted the 24H2 block for affected devices. But our devices were already on 24H2 with the August CU and had no issues until the September update was applied, so that explanation doesn’t quite fit.

I’m pushing back a bit on that - either there were further changes in the September CU relating to camera behaviour, or it’s a very bad coincidence (which is unlikely). I’ll update here if I hear anything useful back from Microsoft or Dell.

I have a small update

I downgraded the wifi driver to 23.110.0.5, turned off ipv6, and disabled camera effects.

Now I dont know if that changed the behavior of the camera or anything, but something thats consistent across the models is the wifi chip inside, which in this case is a Intel Wi-Fi 7 BE201 320MHz. In my event viewer I was getting a TON of netwtw16 errors whenever this camera frame server terminated unexpectedly (and in general since we got these in March). To test I start up a zoom, restart the service and I noticed an interesting behavior that occurs. The wifi will cut out and log error 7021 and 6062. You can fix this with a registry edit to correct the output of these errors, because initially these events were not displaying properly.
6062 - Lso was triggered (new wifi connected)
7021 - connection telemetry fields and analysis usage (not sure)

My theory is that in our environment, we have higher end wifi APs in use. Which would be compatible with these wifi7 cards, but our users may not have this at home. To test I used a hotspot device and restarted the camera frame server service and immediately I noticed that it would lag, stutter, freeze, all the symptoms. Sometimes the zoom would outright crash. In advanced properties I changed the 802.11n/ac/ax/be wireless mode to just AC and while it would stutter when the service is restarted, the camera might need to be toggled, but the wifi does not cut out. I have been running a zoom for a few hours now and it hasnt frozen up until I manually restart that camera frame service. When I change this setting I do not get the 6062 and 7021 error over and over.

If someone else could test this out on their devices I'd be curious if that at least lets your users use the computer! It would explain the no issues on ethernet theory.

Heres the registry instructions if anyones curious

1. Open event viewer and make a note of device mentioned in the problematic eventlog entry from source Netwtw16 In my case: Intel(R) Wi-Fi 7 BE201 320MHz
2. Open device manager and find the above device under Network adapters
3. Right click the device -> properties -> Driver -> Driver Details -> make a note of a directory name in front of \Netwtw16.sys - Go to %SystemRoot%\System32\DriverStore\FileRepository<directory name from #3> Make sure Netwtw16.sys exists there and make a note of full path to Netwtw16.sys. In my case: C:\Windows\System32\DriverStore\FileRepository\netwtw6e.inf_amd64_14f5374e2f00286a\Netwtw16.sys
4. Open regedit and go to HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\EventLog\System\Netwtw16

EventMessageFile key should be present there and its data should look like this: %SystemRoot%\System32\netevent.dll;%13%\Netwtw16.sys

5. Edit the data in the key EventMessageFile so it looks like this: %SystemRoot%\System32\netevent.dll;<path from #3> In my case: %SystemRoot%\System32\netevent.dll;%SystemRoot%\System32\DriverStore\FileRepository\netwtw6e.inf_amd64_14f5374e2f00286a\Netwtw16.sys
6. Reboot
7. After reboot check event viewer, events from Netwtw16 should now read properly

Small correction for wifi chips
Dell 14 Pro has wifi7 BE201 320 MHz (definitely has issues with this)
7450 has wifi7 BE200 160 MHz (has issues with this)
5550 has wifi 6e AX211 160 MHz (this model is not affected by this glitch)