KB5094126 causing app launch delays and service start timeout errors

Windows Update automatically rolled KB5094126 (2026-06 Security Update, build 8655) out to most computers running Windows 11 over the last few days, and I am experiencing some serious issues on several PCs after this update. Interestingly, I have more PCs configured identically and being used the same way (as an NVR) that are running the update just fine.

Initial symptoms that brought this issue to my immediate attention:

• Blue Iris service doesn't autostart; EventLog records "A timeout was reached (45000 milliseconds) while waiting for the Blue Iris Service service to connect."
• Jump Desktop service doesn't autostart; EventLog records "A timeout was reached (45000 milliseconds) while waiting for the JumpConnect service to connect."
• OpenVPN service doesn't autostart; EventLog records "A timeout was reached (45000 milliseconds) while waiting for the OpenVPNService service to connect."

As these PCs are headless, the above results in them appearing to be offline. No other services are flagged as timing out. Apart from OpenVPN (which depends on DHCP), these services do not depend on any other services. None of these services logged any errors or even an attempt at being started to their own log files (i.e. Windows never launched them, or they were hung at a very early stage of initialization for 45 seconds before being terminated by Services.exe for failure to register, never getting a chance to log anything).

OpenVPN somehow gets automatically started at a later time, but the other two services (despite having Restart the Service as an unlimited failure action) never manage to get started. Another piece of software I wrote which launches at startup in the background via the Task Scheduler is starting fine, but delayed: Usually it logs something like "App started, system uptime 0:04/0:03" (mins:secs) every time a PC is booted, but on these PCs, it's logging "App started, uptime 1:45/uptime 2:02/uptime 1:55/uptime 2:05/uptime 2:11"—something is causing a significant startup delay.

Further diagnosis reveals:

1. No setup actions are occurring at bootup—these PCs boot up to the login screen while processes in the background struggle to launch. Worth noting, there were several updates released a few months ago that all had update loop issues, which despite being successfully installed (at least according to winver), Windows would keep force-rebooting the PC to install them again and again—but this never caused any services to fail to start (they'd just start normally once the update process completed). A few days later, Microsoft would pull the update, release a new one the following week, and the forced reboot cycles (sometimes a dozen times every night) would go away after installing the replacement update.
2. When I log in to Windows (local account) for the first time after rebooting, they log in to a black screen. The desktop takes 40 seconds to appear, and the taskbar takes another 10 seconds to appear after that. Clicking the notification area then takes about 5 seconds for the notification panel to open (it opens immediately after the first time). Normally, these PCs log in to a fully loaded desktop in about 2 seconds and there is never a delay in opening anything. The Start Menu works fine, but that's because I'm using OpenShell—I bet it would be having delays too if the Windows Start Menu was enabled. This happens whether I'm logging in immediately after system boot or hours later. However, it does not occur if I log out and log back in—2 seconds to the desktop no problem.
3. Opening the Settings app, it sits there showing a big gear for 15 seconds before displaying normally. Subsequent opens occur in half a second as usual.
4. Running System Informer (or any other program) as administrator, nothing happens for several seconds, the desktop dims for several seconds, the UAC dialog appears with no content or buttons for several seconds, then the content+buttons appear. System Informer starts immediately after clicking [Yes], showing low CPU usage and plenty of free memory. The PCs otherwise feel fast, and subsequent UAC dialogs pop up right away (even after logging out and back in). HwInfo shows the CPU core speeds bouncing around normally, so it's not stuck on low clocks with just one core unparked (for example). CPUs are Intel 10700K and 13900HX, 48GB RAM, all NVMe drives, etc.
5. Standalone Win32 programs all seem to open instantly every time; this just seems to affect some programs—primarily ones using the modern/UWP platform (including the UAC dialog)—and the select Win32 sevices I mentioned above.
6. There are no unusual errors/warnings in the main Event Logs. Drilling down into specific Application and Service logs:
7. BitLocker-API/Management is reporting "BitLocker determined that the TCG log is invalid for use of Secure Boot. The filtered TCG log for PCR[7] is included in this event." as info. Another affected PC is alternating this and a warning "BitLocker cannot use Secure Boot for integrity because the expected TCG Log separator entry is missing or invalid." These errors first appear 6/10 after the update installed and seem to appear upon every boot. BitLocker is not in use whatsoever on these PCs and I'd love to uninstall it completely.
8. State Repository/Operational is frequently logging error "Error 0x15: misuse at line 185353 of [737ae4a347] SQL" on the affected machines. This started after the update, but is not seen on the several updated yet unaffected machines I checked.
9. WFP/Operational is logging a lot of warnings like "Transaction Watchdog Timeout. The filtering engine has exceeded the configured threshold to process a transaction. This could indicate a suboptimal policy configuration that may cause temporary network outages. Owning Process ID: 0. Transaction Time (msec): 3203. Transaction Commit Time (msec): 406. Configured Threshold (msec): 500". These warnings started 6/10 after the update.
10. Windows Firewall With Advanced Security/FirewallDiagnostics is logging a lot of information like "FwThreadWaitTimeAndHoldTimeForFwLock. callersAppCommandLine: MPSSVC, callerFunctionName: FwProfileMgrUpdateCachedPolicy, threadWaitAndLockHoldTimeMs: 11969, fwLockHoldTimeMs: 11969". These informations started 6/10 after the update.

It's like the system is waiting on something in the background, but I can't seem to find any more information besides the above on what it could be. I added code to my software that would allow me to remotely start the services that were failing to autostart, and they come online just fine after making that request. But all the problems described above come back after a reboot—the affected services fail to start again, login takes forever, first UAC dialog is sluggish, etc. For the time being, I will just make it my program's responsibility to send a start request to the two services that are failing to autostart to work around the issues, and hope that a later Windows Update will resolve them.

Anyone else experiencing similar issues with this update? This update was supposed to make things faster, not slower! Any ideas what Microsoft broke this time?

I experienced the same. It's specifically the KB5089573 update, that was rolled into that update.

At login, background apps are slow to start. My scheduled tasks in task scheduler are also slow to execute. What used to be a total of 30 second bootup/startup time turned into 3 minutes. I have auto login on boot, and I have autolock script to run at login to keep it protected. But since it doesn't run until a whole 1-2 minutes. I leaves my machine vulnerable for that amount of time.


Edit: The fix is to disable the new low latency profile with "vivetool.exe /disable /id:58989092"

You'll have to download vivetool and use the command line

Have you checked the Timeout Detection and Recovery,TDR, time is set at the default time of 2 seconds,in milliseconds ?
HKEY_Local_Machine\System\CurrentControlSet\Control\GraphicsDriver
The Reg key is TdrDelay.
Also have you tried disabling all non Microsoft Apps from auto starting,then re-enabling them,one at a time to see if if the cause of the problem lies there ?

@duhk Wow, it's hard to believe it's the low latency profile causing the issue. Operating CPU speed is plenty fast during these issues due to background loads, and the systems aren't normally anywhere near this slow even if I manually force the CPU to run at its lowest speed (800 MHz) with only one core. But I refuse to use vivetool, so no verification on my end unless someone knows the actual FeatureFlags to toggle in the registry. I wonder if it's a notification issue (why would Microsoft make that a blocking call!), or something unrelated also attached to that feature flag.

@joeandmarg0 TdrDelay values are not present in any of the machines I checked (affected and not affected). Not seeing any visual evidence (or logs) that the video driver is getting restarted.

Techie007 said:

@duhk Wow, it's hard to believe it's the low latency profile causing the issue. Operating CPU speed is plenty fast during these issues due to background loads, and the systems aren't normally anywhere near this slow even if I manually force the CPU to run at its lowest speed (800 MHz) with only one core. But I refuse to use vivetool, so no verification on my end unless someone knows the actual FeatureFlags to toggle in the registry. I wonder if it's a notification issue (why would Microsoft make that a blocking call!), or something unrelated also attached to that feature flag.

@joeandmarg0 TdrDelay values are not present in any of the machines I checked (affected and not affected). Not seeing any visual evidence (or logs) that the video driver is getting restarted.

Click to expand...

It's what fixed the issue for me. I prefer to utilize windows feature flags myself either through registry or group policy. But so far, I wasn't able to find any info on it. vivetool was the only solution. You can obviously re-enable if needed. But that's the only fix at the moment aside from rolling back the update.. I am also curious as to what it is exactly in the "Performance Update" that is causing the slow startup.

edit: Also the reason why only some of your machines are affected is because it's one of those "slow rollout" features. That could be why not soo many people are seeing the issue.