EDIT 10/17: The issues is not resolved on my machine. I still need to use the command in PowerShell before opening Steam for the first time after a system reboot. Unfortunate.
EDIT 10/16: The issue seems to have been resolved with the latest steam patch. AMD users should no longer need to do anything special, simply run steam as per normal. The body of the post is being preserved for the future.
TL;DR / the fix
If Steam crashes right after starting since today’s client update and you have an AMD GPU, AMD’s GameManager64.dll is the likely cause. It’s loaded into Steam by the “AMD External Events Utility” service. Stop that service, start Steam, then turn the service back on.
Admin PowerShell, one line (change the path if Steam is installed somewhere else):
Stop-Service 'AMD External Events Utility' -Force; Start-Process explorer.exe '"C:\Program Files (x86)\Steam\steam.exe"'; Start-Sleep 20; Start-Service 'AMD External Events Utility'
Non command line: open services.msc, stop AMD External Events Utility, start Steam, then start the service again. You have to do this every time Steam starts, including when it restarts itself after an update.
Are you affected?
Check Event Viewer > Windows Logs > Application for Event ID 1000 entries showing:
- Faulting application:
steam.exe
- Faulting module:
ntdll.dll
- Exception code:
0xc0000005
My setup: RX 7900 XTX, AMD driver 32.0.31041.1004, Windows 10 22H2, Steam client updated Oct 15 (steam.exe 11.12.30.7).
Detailed explanation
I analyzed the crash dumps Windows saves in %LOCALAPPDATA%\CrashDumps using WinDbg and disassembled the AMD DLLs.
- Injection: The AMD External Events Utility service (
atiesrxx.exe) runs a helper, atieah64.exe, that injects detoured64.dll and GameManager64.dll into steam.exe as it starts. GameManager64 contains a list of game launchers it targets: steam.exe, origin.exe, uplay.exe and ubisoftgamelauncher.exe.
- The hook: GameManager64 uses Microsoft Detours to intercept
kernel32!CreateProcessW (and CreateProcessA). On every call it:
- removes its own hook,
- calls the real CreateProcessW,
- puts the hook back.
- What changed: The updated Steam starts
vulkandriverquery.exe and vulkandriverquery64.exe at the same moment, on two worker threads (CJobMgr::m_WorkThreadPool:0 and :1). The two remove/restore sequences overlap and leave an orphaned patch. AMD’s internal pointer says “unhooked” (it points to the raw kernel32!CreateProcessWStub), but the function still jumps into AMD’s hook.
- The crash: Every “real” call re-enters the hook. Both threads recurse about 10,650 levels deep until the 1 MB thread stack is exhausted. Steam’s own crash handler then fails too, which is why the error blames ntdll.dll and not AMD.
Evidence:
- All three dumps I analysed show the same two threads in the same loop, each launching one of the vulkandriverquery programs.
- Under a debugger the timing changes and Steam starts fine.
- With the AMD service stopped, GameManager64 never loads and Steam runs normally.
Whose bug is it? Steam’s update triggered it, but the defect is in AMD’s code. Starting processes from two threads at once is normal, supported Windows behaviour. AMD’s hook just can’t handle it. I’m inferring that older Steam builds launched those two programs one after the other; I didn’t test an old build. Valve could work around it quickly (launch them one at a time), but AMD needs to fix the hook. Other launchers it targets could hit the same bug if they ever start programs in parallel.
I’ve only tested this on one machine. If you have the same crash, please post your driver version.
