Mysterious fastprox WMI crasher for Source games
Saturday, October 16, 2010 3:26:26 PM
Steam Support pages gave some possible fixes such as adding Local Service to Administrators group or repairing Windows Management Instrumentation libraries. The former didn't help, but had a side effect of granting normal users admin powers too. Not nice. Doing the WMI repairs didn't help either, but as it appears, that was not very far from the real problem, though.
Today I started digging in deeper on the matter by running the game through WinDbg. Apparently the error was "Access Violation", but when looking in more detail, the faulting instruction was trying to read from memory address 0x0000000. Classical NULL pointer error. Checking the disassembly, this NULL pointer was found by dereferencing a pointer with some offset of returned value of another function. So the actual problem very likely resided in the function called just before the crash. Here WinDbg didn't want to help me. I could not place a breakpoint at this location to see what the actual function to be called would be since shaderapidx9.dll was dynamically loaded and this memory area was not occupied at application launch yet.
After a few tries and running it under different contexts, I managed to get symbolic name for the module and offset from the module load address to the part just before calling the interesting function. Then using bu (I think it means unreferenced breakpoint) it was possible to place a breakpoint that was dynamically resolved after the shaderapidx9 module was loaded but before the code would execute.
Turns out the function was from fastprox module, part of WMI. Specifically, the call was to fastprox!CEnumProxyBuffer::XEnumFacelet::Release. I have no idea what that really is, but apparently something here was going wrong, causing part of memory containing pointers to have zeros, later causing attempt to read from address 0x0 and crashing the game. So now at least I found out where the actual problem happens. The crash was inside shaderapidx9.dll, but the actual error leading to crash was in fastprox.dll.
Then I made a wild try: I renamed C:\Windows\SysWOW64\wbem\fastprox.dll to fastprox.dll_. To my big surprise the game actually launched now and there didn't seem to be any problems. But this file had been there since the beginning but the game stopped working a few days ago, so it was certainly the source of the problem itself. Without knowing better, I blame QuickTime myself, although other things that had happened in the past few days had been updating VirtualBox and installing a patch to Adobe Reader. Unfortunately I didn't have enough System Restore points to try to pinpoint what actually caused this problem to appear. But since it wouldn't be just the existence of fastprox.dll itself, I tried renaming it back and doing other tricks to try to get WMI to work nicely.
One problem I noticed was that the Steam Support page instructed doing the repair steps in C:\Windows\System32\wbem, but since L4D2 (as well as other Source games by default) is 32-bit process, so it actually uses files from SysWOW64, not System32. So I ran the repair steps from inside SysWOW64 too, but that didn't help. I even managed to somehow get WMI service to not even start again, got a weird error message instead:
Windows could not start the Windows Management Instrumentation service on Local Computer. Error 1290: The service start failed since one or more services in the same process have an incompatible service SID type setting. A service with restricted service SID type can only coexist in the same process with other services with a restricted SID type. If the service SID type for this service was just configured, the hosting process must be restarted in order to start this service.
This was a bit worrying, since WMI is one of the more important services for system components in Windows. Well, I remembered which svchost.exe was running this service in the past, so I tried doing what the error hinted at: I killed the process. Of course that also affected all the numerous other services running on that process. But a miracle happened: Windows automatically launched that svchost.exe again, with WMI service in it, and then later started all the other services that went down also. But still, the game wouldn't launch if fastprox.dll was present in SysWOW64\wbem.
So for now I do not have 32-bit version of fastprox.dll and the games seem to work fine. I just think this might lead to some other problems. But at least it is not the 64-bit version in fault, as deleting that file would render the whole WMI service inoperable (I tried!).