Fix 0X00000892: Service thread creation failure

When this error hits

You're staring at the Services console or a script that tries to start a service, and it fails with error 0X00000892. The event log shows Event ID 7024 with the text "A thread for the new service could not be created". This usually happens on busy Windows Server 2016, 2019, or 2022 boxes running lots of services, or on terminal servers with high user loads. I've seen it most often after a service pack or cumulative update, or when someone cranks up the number of worker threads in an app like SQL Server or IIS.

Root cause in plain English

0X00000892 maps to STATUS_NO_MEMORY at the kernel level, but not in the way you think. Windows has a limit on the total number of threads across all processes — it's tied to system memory and the paged pool size. When that pool runs dry, any new thread creation fails. The culprit here is almost always thread pool exhaustion from a misbehaving service or driver, or the service account lacking the SeIncreaseQuotaPrivilege right. Don't bother checking physical RAM first; it's rarely the issue.

Step-by-step fix

1. Identify the thread hog — Open Task Manager, go to Details tab, add the Threads column if not visible. Sort by thread count. Look for anything using 500+ threads. Common offenders: svchost.exe hosting a leaky service, sqlservr.exe with max worker threads set too high, or a .NET app with ThreadPool.SetMinThreads cranked up.
2. Check the system-wide thread limit — Run this in PowerShell as admin:
   

   Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" -Name "PagedPoolSize"

   
   If PagedPoolSize is set to a specific value (like 0xFFFFFFFF), that's the max. Default is 0 (system-managed). If it's set to anything under 256MB, that's your bottleneck.
3. Reset paged pool to system-managed — If you found a custom PagedPoolSize, delete it:
   

   Remove-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" -Name "PagedPoolSize"

   
   Then reboot.
4. Fix the service account permissions — Open Local Security Policy -> User Rights Assignment -> Adjust memory quotas for a process. Make sure the service account (or NT SERVICE\ALL SERVICES) is listed. If missing, add it. Reboot the service.
5. Kill the thread hog (temporary) — If you need the service up now, restart the offending process or service. For example, if SQL Server has 2000 threads, run:
   

   Restart-Service MSSQLSERVER

   
   Then reconfigure its max worker threads.
6. Increase the thread limit via registry (last resort) — Only do this if you've confirmed paged pool exhaustion via Performance Monitor (counter: Memory\Pool Paged Bytes > 80% of max). Create a DWORD at HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PagedPoolSize and set it to 0xFFFFFFFF (max), or calculate a value in bytes (e.g., 512MB = 0x20000000). Reboot.

What to check if it still fails

If the steps above don't work, look at driver-level issues. Run poolmon (part of Windows SDK) to find non-paged pool leaks — tag "Thrd" means thread stack allocations. Also check if anti-virus or endpoint protection is blocking thread creation for the service account. Temporarily disable it to test. Finally, verify the service binary isn't corrupted — run sfc /scannow and check system file integrity.

One more thing: if this is a 32-bit service on a 64-bit OS, the thread limit for 32-bit processes is lower. Move to a 64-bit build of the service if possible.