我们在调试dump文件的时候，如果出现mscorwks版本不一致的情况，可以参考下面这个discussion，已经试过，可以work
Posted by Microsoft on 10/21/2008 at 8:27 AM
L.C.,
Sincere apologies for the extremely delayed response on this bug. There's really no excuse. Rest assured, Microsoft are trying to pay more close attention to Connect bugs. As you can imagine, it can be difficult to scale, but we know we can do better and we're working on it.
Regarding this issue, in particular, I've verified on a machine with mscorwks version 2.0.50727.42 that I can debug a dump with mscorwks version 2.0.50727.832. I am using x86 WinDbg version 6.9.0003.113 and after loading the dump I execute the following commands:
-.sympath srv*http://msdl.microsoft.com/download/symbols
-.reload
-.load c:\windows\microsoft.net\framework\v2.0.50727\sos.dll
-!threads - this is an SOS command and it succeeds.
I believe I did see that if I loaded SOS prior to setting up my symbol path and executing ".reload" I needed to run ".cordll -ve -u -l" in order for SOS commands to work. One thing to note, you must use the debugger which matches the architecture of the dump. E.g. if you're debugging an x86 dump you cannot use the x64 version of WinDbg. SOS doesn't support cross-platform debugging at this time.
So, it looks like the .832 version of mscordacwks is properly indexed on our HTTP symbol server. We do this so we can enable exactly the scenario you describe: to debug a dump with a different version of the runtime than what is installed on the debugger machine.
I'm going to resolve this "Not Repro" for now, but if you still aren't able to make this work, please feel free to re-activate the issue.
Thank you for your patience on this issue and again, my sincere apologies for the delay in response.
Regards,
Jon
Sincere apologies for the extremely delayed response on this bug. There's really no excuse. Rest assured, Microsoft are trying to pay more close attention to Connect bugs. As you can imagine, it can be difficult to scale, but we know we can do better and we're working on it.
Regarding this issue, in particular, I've verified on a machine with mscorwks version 2.0.50727.42 that I can debug a dump with mscorwks version 2.0.50727.832. I am using x86 WinDbg version 6.9.0003.113 and after loading the dump I execute the following commands:
-.sympath srv*http://msdl.microsoft.com/download/symbols
-.reload
-.load c:\windows\microsoft.net\framework\v2.0.50727\sos.dll
-!threads - this is an SOS command and it succeeds.
I believe I did see that if I loaded SOS prior to setting up my symbol path and executing ".reload" I needed to run ".cordll -ve -u -l" in order for SOS commands to work. One thing to note, you must use the debugger which matches the architecture of the dump. E.g. if you're debugging an x86 dump you cannot use the x64 version of WinDbg. SOS doesn't support cross-platform debugging at this time.
So, it looks like the .832 version of mscordacwks is properly indexed on our HTTP symbol server. We do this so we can enable exactly the scenario you describe: to debug a dump with a different version of the runtime than what is installed on the debugger machine.
I'm going to resolve this "Not Repro" for now, but if you still aren't able to make this work, please feel free to re-activate the issue.
Thank you for your patience on this issue and again, my sincere apologies for the delay in response.
Regards,
Jon
