One of the tools I use on an every day basis is Mstsc.exe, which is the terminal services client application that you'll find on all recent versions of Windows. However, something strange started to happen yesterday. Whenever I would attempt to connect to a remote machine, Mstsc.exe would crash without even displaying a warning message. So I checked the application event log (eventvwr.msc) and found the following error message:
Faulting application mstsc.exe, version 6.0.6001.180000, faulting module ntdll.dll, version 6.0.6001.180000, exception code 0x80000003
Exception code 0x80000003 is something I've come across when debugging drivers and it's defined in ntstatus.h as STATUS_BREAKPOINT. It means that a breakpoint or ASSERT was encountered when no kernel debugger is attached to the system. You can find some related information here.
At this point, I had to scratch my head and ponder my navel. I couldn't figure out what I'd done to my machine recently that would cause this problem. So I did a Live Search on the exception code and found a blog post by Joe Wirtley who described encountering this issue after installing the DirectX SDK. His resolution was to uninstall the DirectX SDK.
Coincidently, I'd been doing some work with DirectX recently, so I started thinking, what is it about the DirectX SDK that would cause a kernel mode breakpoint to occur? So then it hit me ... the DirectX Control Panel.
Dxcpl.exe is a useful little tool that's part of the DirectX SDK and one of it's primary uses is to help debug Direct3D code. I'd been using this utility a few days earlier and had forgotten to disable some of the debug settings. My version of mstsc.exe evidently uses Direct3D 9 because it started working happily just as soon as I disabled the debug settings in dxcpl.exe. Here's a screen capture that shows the culprit settings.