As I am sure many of you are aware, WinDbg does not support the debugging of managed target code, either live or in a crash dump. What little functionality there is, is contained in extensions designed for this purpose.
Midway through 2008, Microsoft released version 6.7.5.0 of the Debugging Tools for Windows. This version was able to accurately render stacks that contain managed (.NET) frames in them. It was also able to detect and open the matching source for managed stack frames (presuming the source was available on the debugging machine). After a short period of time, this release was quietly replaced with one that did not have said capabilities and ever since then, this functionality has remained unavailable in continuing releases. Version 6.7.5.0 contained this functionality because of a mistake in the release process that resulted in the external release of the version of the debugger that is built only for internal Microsoft use. As a matter of policy, this internal version is not released externally because it uses undocumented CLR (.NET Common Language Runtime) functions that might put Microsoft on unclear legal ground should they be used in a product that is made available to customers. This is because WinDbg is a product of the Windows team and the CLR is a product of a different business unit that also contains Visual Studio.
Lately, after consulting with our attorneys, it was determined that it would be legally kosher to ship a version WinDbg that uses the undocumented CLR functions in question. It was at this point that I announced to this newsgroup that the next version of the Debugging Tools for Windows would restore the CLR support that was missing since version 6.7.5.0 was replaced.
I am afraid that I spoke too soon. Since then, the members of the CLR team have made it clear that they do not want to allow this functionality to be put back into the external release of WinDbg, because they are concerned that they might have to document the functions that WinDbg calls in order to work with managed targets. This leaves us with little choice but to continue to maintain WinDbg as a non-CLR enabled debugger into the indefinite future.
> As I am sure many of you are aware, WinDbg does not support the debugging > of > managed target code, either live or in a crash dump. What little > functionality there is, is contained in extensions designed for this > purpose.
> Midway through 2008, Microsoft released version 6.7.5.0 of the Debugging > Tools for Windows. This version was able to accurately render stacks that > contain managed (.NET) frames in them. It was also able to detect and > open > the matching source for managed stack frames (presuming the source was > available on the debugging machine). After a short period of time, this > release was quietly replaced with one that did not have said capabilities > and ever since then, this functionality has remained unavailable in > continuing releases. Version 6.7.5.0 contained this functionality because > of a mistake in the release process that resulted in the external release > of > the version of the debugger that is built only for internal Microsoft use. > As a matter of policy, this internal version is not released externally > because it uses undocumented CLR (.NET Common Language Runtime) functions > that might put Microsoft on unclear legal ground should they be used in a > product that is made available to customers. This is because WinDbg is a > product of the Windows team and the CLR is a product of a different > business > unit that also contains Visual Studio.
> Lately, after consulting with our attorneys, it was determined that it > would > be legally kosher to ship a version WinDbg that uses the undocumented CLR > functions in question. It was at this point that I announced to this > newsgroup that the next version of the Debugging Tools for Windows would > restore the CLR support that was missing since version 6.7.5.0 was > replaced.
> I am afraid that I spoke too soon. Since then, the members of the CLR > team > have made it clear that they do not want to allow this functionality to be > put back into the external release of WinDbg, because they are concerned > that they might have to document the functions that WinDbg calls in order > to > work with managed targets. This leaves us with little choice but to > continue to maintain WinDbg as a non-CLR enabled debugger into the > indefinite future.
> As I am sure many of you are aware, WinDbg does not support the debugging > of > managed target code, either live or in a crash dump. What little > functionality there is, is contained in extensions designed for this > purpose.
> Midway through 2008, Microsoft released version 6.7.5.0 of the Debugging > Tools for Windows. This version was able to accurately render stacks that > contain managed (.NET) frames in them. It was also able to detect and > open > the matching source for managed stack frames (presuming the source was > available on the debugging machine). After a short period of time, this > release was quietly replaced with one that did not have said capabilities > and ever since then, this functionality has remained unavailable in > continuing releases. Version 6.7.5.0 contained this functionality because > of a mistake in the release process that resulted in the external release > of > the version of the debugger that is built only for internal Microsoft use. > As a matter of policy, this internal version is not released externally > because it uses undocumented CLR (.NET Common Language Runtime) functions > that might put Microsoft on unclear legal ground should they be used in a > product that is made available to customers. This is because WinDbg is a > product of the Windows team and the CLR is a product of a different > business > unit that also contains Visual Studio.
> Lately, after consulting with our attorneys, it was determined that it > would > be legally kosher to ship a version WinDbg that uses the undocumented CLR > functions in question. It was at this point that I announced to this > newsgroup that the next version of the Debugging Tools for Windows would > restore the CLR support that was missing since version 6.7.5.0 was > replaced.
> I am afraid that I spoke too soon. Since then, the members of the CLR > team > have made it clear that they do not want to allow this functionality to be > put back into the external release of WinDbg, because they are concerned > that they might have to document the functions that WinDbg calls in order > to > work with managed targets. This leaves us with little choice but to > continue to maintain WinDbg as a non-CLR enabled debugger into the > indefinite future.
My statement, "No it does not, Marc" was meant to indicate that this does *not* impact the the functionality of the sos extension. This extension is the product of the CLR team and its capabilities are completely determined by them.
|
