No CLR support in the latest debugger release

225 views
Skip to first unread message

pat styles [microsoft]

unread,
Nov 24, 2008, 11:27:37 AM11/24/08
to
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.

regards,
.pat styles [microsoft]

Marc Sherman

unread,
Nov 24, 2008, 5:54:27 PM11/24/08
to
Pat,

This doesn't impact the functionality in the sos extension, right?

thanks,
Marc

"pat styles [microsoft]" <pat.s...@microsoft.com> wrote in message
news:419AABAB-4BF3-457C...@microsoft.com...

pat styles [microsoft]

unread,
Nov 24, 2008, 6:00:19 PM11/24/08
to
No it does not, Marc.

.pat styles [microsoft]

"Marc Sherman" <masher...@yahoo.com> wrote in message
news:#PEqbeoT...@TK2MSFTNGP04.phx.gbl...

Jochen Kalmbach [MVP]

unread,
Nov 25, 2008, 2:52:32 AM11/25/08
to
Hi Pat!

Really bad news...

> This doesn't impact the functionality in the sos extension, right?
>

> No it does not, Marc.

Wouldn't it be possible to implement such a feature
(source-debugging-support; or at least for dumps) in sos.dll?

So the CLR-team would be responsible for this feature and would have
"control" over it.

Greetings
Jochen

v...@gmx.de

unread,
Nov 25, 2008, 3:23:50 AM11/25/08
to
Hi Pat,

thanks a lot for this clarification.
To be honest I'm not happy about this decision.
But I'm happy that I kept my private copy of 6.7.5.0!

Volker

http://www.voneinem-windbg.blogspot.com

Jochen Kalmbach [MVP]

unread,
Nov 25, 2008, 3:40:11 AM11/25/08
to
Hi vve!

> But I'm happy that I kept my private copy of 6.7.5.0!

FYI: You can still download the 6.7.5.0 version ;)

Greetings
Jochen

v...@gmx.de

unread,
Nov 25, 2008, 5:03:45 AM11/25/08
to
Hi Jochen,

could you provide the the link?

Thanks,
Volker

Jochen Kalmbach [MVP]

unread,
Nov 25, 2008, 5:15:15 AM11/25/08
to
Hi vve!

> could you provide the the link?

Copy the link for the 6.7.5.1 download and rename "1" to "0" ;)

Greetings
Jochen

pat styles [microsoft]

unread,
Nov 25, 2008, 9:43:38 AM11/25/08
to
Maybe I was unclear.

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.

.pat styles [microsoft]

"Jochen Kalmbach [MVP]" <nospam-Joch...@holzma.de> wrote in message
news:OB$3BLtTJ...@TK2MSFTNGP05.phx.gbl...

Reply all
Reply to author
Forward
0 new messages