KB5094126 causing app launch delays and service start timeout errors

• 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."

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.

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...

Techie007 said:

Now running Windows 11 build 26200.9278 with 26H2 expected to release soon, yet this bug remains unresolved and bad as ever: PCs that should boot to the desktop in 20 seconds are barely usable after several minutes—over a minute for the desktop to appear after logging in, another 30 seconds before the taskbar appears, some programs open right away when clicked, and then proceed to hang, some services repeatedly fail to start, etc.

However, I recently noticed in Task Manager that the system NVMe drive is sitting there, pegged at 100% activity for minutes, with response times regularly over 100ms and transfer rates in the 1MB/s range while this is happening. Comparing with one machine that has remained unaffected, I noticed the unaffected machine is using the old NVMe stack. Back when the new NVMe stack was rolled out, I did quite a bit of testing and found universal speed improvements and reduced CPU usage during high I/O with no significant issues, and included it in my debloating script—with no problems until KB5094126 was released back in June. The unaffected machine using the old NVMe stack had all the applicable "14 series" feature switches enabled (156965516, 735209102, 1176759950, 1853569164, 3244671118)—except for 3244671118, which was not present. So for a test on an affected machine, I deleted "HKLM\SYSTEM\CurrentControlSet\Control\FeatureManagement\Overrides\14\3244671118" from the registry, ran ReconcileFeatures, and rebooted. That PC rebooted to the desktop in 20 seconds for the first time in months! Opening Device Manager confirmed it was no longer using the new NVMe stack. I ran CrystalDiskMark before and after, and the results are as expected: Faster on the new NVMe stack, and slower on the old NVMe stack. Yet there is some massive I/O bottleneck occuring under unknown circumstances that seem to trigger primarily when the system is booting up when using the new NVMe stack, causing extreme delays and service start failures. I don't know what Microsoft broke (and I bet they don't know either!), but I'm glad I found a solution. Too bad the new NVMe stack has to go on the back burner for now!

View attachment 181401
View attachment 181402

tl,dr: The issues and massive slowdown introduced in June is caused by a negative interaction between something Microsoft added in June and the new NVMe stack. Removing override "14\3244671118" from the registry, reconciling features, and rebooting, restores normal system operation using the legacy storage stack without losing the low latency power profile improvements.

Click to expand...