I am encountering the .Net run-time version error referencing mscordacwks.dll, and I've seen several posts related to that. My issue seems unique, however, due to the fact that my local .Net framework actually matches the version where the dump file was generated. So the dialog is saying that I need to have v2.0.50727.4961 (64 bit), and that's the version installed on the machine where I'm trying to import the memory dump.

So why is it rejecting my run-time version when it's actually the correct version?

It's worth mentioning that I've submitted a request to my manager to purchase licenses of this software, but he's not impressed that I can't get it to work. Help!?

It's odd that you get a version mismatch in your case. To be able to get more information about this problem, it would be good if we could try to import the memory dump ourselves. Is there any possibility for you to provide us with the memory dump file? If so, please contact us at support@scitech.se so that we can send you information on how to upload the dump file to us. It might also be a good idea for you to provide us with the sos.dll file and the mscordacwks.dll file from your machine.

I actually figured this one out by getting it to work in WinDbg first. I tried:.loadby sos clr!eeheap

...and WinDbg told me it was looking for mscordacwks_AMD64_AMD64_4.0.30319.235.dll. So I copied mscordacwks.dll to the WinDbg folder and renamed it as requested. Then WinDbg worked just fine.

The confusing thing is that .Net Memory Profiler was prompting me for the location of the v2.0.50727.4961 (64 bit) version of mscordacwks.dll. But I instead entered the path to the mscordacwks_AMD64_AMD64_4.0.30319.235.dll, and then it worked and loaded the dump file.

It does sound like a bug in the profiler. It is possible to load both .NET runtime 2.0 and 4.0 into the same process. When importing a memory dump, the profiler will only import data from one of the runtimes, and the v4.0 runtime is supposed to have higher priority.

Do you have two runtimes loaded into your process?

We would like to investigate this further and find out what's causing the problem, but then we would need to look at the memory dump file. Is there any possibility for you to provide us with the memory dump file? If so, please contact us at support@scitech.se so that we can send you information on how to upload the dump file to us.

Thanks for sending us the memory dump and for the update regarding mscordacwks. The Microsoft symbol server does not always have the correct version of mscordacwks available (I believe this is more common for hot-fix versions of the runtime). If the symbol server does not provide the correct version of mscordacwks, you need to specify the file manually. Using the mscordacwks file you sent, I managed to import the memory dump, so I assume that you have successfully imported it as well?