Debugging a .net 4.0 application when .net 4.5 is installed

I have a machine that runs .net 4.0 and where I took a memory dump of an application. I moved the dump to my machine, which has .net 4.5 installed and tried to debug it in WinDbg:

0:000> .loadby sos clr
0:000> !DumpHeap
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
            2) the file mscordacwks.dll that matches your version of clr.dll is 
                in the version directory or on the symbol path
            3) or, if you are debugging a dump file, verify that the file 
                mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
            4) you are debugging on supported cross platform architecture as 
                the dump file. For example, an ARM dump file must be debugged
                on an X86 or an ARM machine; an AMD64 dump file must be
                debugged on an AMD64 machine.

You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll.  .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable
path is pointing to clr.dll as well.

On the internet, there’s a bunch of guides that focus on bringing in the right version of mscordacwks.dll, but that wasn’t my problem (I have setup the Symbol Server and WinDBG was correctly downloading the right version). Turns out that .net 4.5 comes with a new SOS.dll that is incompatible with .net 4.0 memory dumps. The solution for me was to copy the SOS.dll from a .net 4.0 machine (from C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319) into the winext folder of my WinDbg installation (C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x86\winext) and then just load it with

.load sos

Yeah, this whole in-place upgrade of .net 4.0 to 4.5 was truly a great idea…