Debugging 3rd party (or Microsoft) assemblies

[Notre Poubelle]

Hello,

I know tools like Lutz Roeder's Reflector can be used to disassemble an
assembly into any number of .NET languages and this is invaluable for
debugging 3rd party (e.g. Microsoft) components. There are many times when
debugging my own code leads deep into a 3rd party component and an exception
may occur within that 3rd party component. By using VS' debugger, I can see
the call stack, which gives me information on the method that raised the
exception but of course I can't debug the code to see the arguments and the
exact managed statement that caused a problem.

I'm aware of tools like Mike Stall's Mdbg that allows one to go to the
disassembly of .NET assembly during runtime. As cool as this is, it is
limited by the fact that you can't see the value of any variables; you can
step through the IL but you can't view any locals which greatly limits its
use for debugging.

The only thing I can think of to achieve effective debugging (short of
looking at the native disassembly which I'm not brave enough to try) is to
disassemble the 3rd party assembly and then rebuild it with debug symbols.
This is where my question comes in. Does any tool you know of allow one to
take an assembly and generate C# (or VB .NET) source code for the entire
assembly, rather than on a method by method basis such that it is easy to
rebuild the assembly? A problem I see in rebuilding the assembly would be to
ensure that rebuilt assembly is signed with the identical strong name as the
orginal assembly so that references from other code are still valid and I
don't have to rebuild a large tree of assemblies. Is this possible?

Thanks you,
Notre

[Ben Voigt]

"Notre Poubelle" <no************@online.nospam> wrote in message
news:50**********************************@microsof t.com...

Hello,

I know tools like Lutz Roeder's Reflector can be used to disassemble an
assembly into any number of .NET languages and this is invaluable for
debugging 3rd party (e.g. Microsoft) components. There are many times
when
debugging my own code leads deep into a 3rd party component and an
exception
may occur within that 3rd party component. By using VS' debugger, I can
see
the call stack, which gives me information on the method that raised the
exception but of course I can't debug the code to see the arguments and
the
exact managed statement that caused a problem.

I'm aware of tools like Mike Stall's Mdbg that allows one to go to the
disassembly of .NET assembly during runtime. As cool as this is, it is
limited by the fact that you can't see the value of any variables; you can
step through the IL but you can't view any locals which greatly limits its
use for debugging.

The only thing I can think of to achieve effective debugging (short of
looking at the native disassembly which I'm not brave enough to try) is to
disassemble the 3rd party assembly and then rebuild it with debug
symbols.
This is where my question comes in. Does any tool you know of allow one
to
take an assembly and generate C# (or VB .NET) source code for the entire
assembly, rather than on a method by method basis such that it is easy to
rebuild the assembly? A problem I see in rebuilding the assembly would be
to
ensure that rebuilt assembly is signed with the identical strong name as
the
orginal assembly so that references from other code are still valid and I
don't have to rebuild a large tree of assemblies. Is this possible?
http://www.codeproject.com/dotnet/De...rk_Classes.asp

Thanks you,
Notre

[Mattias Sjögren]

Notre,

A problem I see in rebuilding the assembly would be to
ensure that rebuilt assembly is signed with the identical strong name as the
orginal assembly so that references from other code are still valid and I
don't have to rebuild a large tree of assemblies. Is this possible?

No. If it was, the whole strong name system would be broken.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Cowboy \(Gregory A. Beamer\)]

You can find a bit of info with tools like ProcessExplorer
(sysinternals.com), but it does not give you everything you would need. I am
not sure if there is a tool that can poke as deeply as you would like.

--
Gregory A. Beamer

*************************************************
Think Outside the Box!
*************************************************
"Notre Poubelle" <no************@online.nospam> wrote in message
news:50**********************************@microsof t.com...

Hello,

I know tools like Lutz Roeder's Reflector can be used to disassemble an
assembly into any number of .NET languages and this is invaluable for
debugging 3rd party (e.g. Microsoft) components. There are many times
when
debugging my own code leads deep into a 3rd party component and an
exception
may occur within that 3rd party component. By using VS' debugger, I can
see
the call stack, which gives me information on the method that raised the
exception but of course I can't debug the code to see the arguments and
the
exact managed statement that caused a problem.

I'm aware of tools like Mike Stall's Mdbg that allows one to go to the
disassembly of .NET assembly during runtime. As cool as this is, it is
limited by the fact that you can't see the value of any variables; you can
step through the IL but you can't view any locals which greatly limits its
use for debugging.

The only thing I can think of to achieve effective debugging (short of
looking at the native disassembly which I'm not brave enough to try) is to
disassemble the 3rd party assembly and then rebuild it with debug
symbols.
This is where my question comes in. Does any tool you know of allow one
to
take an assembly and generate C# (or VB .NET) source code for the entire
assembly, rather than on a method by method basis such that it is easy to
rebuild the assembly? A problem I see in rebuilding the assembly would be
to
ensure that rebuilt assembly is signed with the identical strong name as
the
orginal assembly so that references from other code are still valid and I
don't have to rebuild a large tree of assemblies. Is this possible?

Thanks you,
Notre

[Notre Poubelle]

Thank you Ben. This was a great article. I've followed the instructions to
disassemble & reassemble the assembly, but I am having trouble adding an
assembly to the GAC. The error messages is

Failure in adding the assembly to the cache: Strong name signature could not
be verified. Was the assembly built delay-signed?

I tried using gacutil /i <assemblyname> and gacutil /i <assemblyname> /f

Any further suggestions?

Notre

[Notre Poubelle]

Hi Mattias,

Sorry for being slow, but I'm not sure what you're saying. Are you saying
that one cannot replace one assembly with another and maintain a working
strong name system?

Thanks,
Notre

[Notre Poubelle]

I found a way to get this working almost perfectly.

I used the strong name utility (sn) to register my rebuilt assembly to skip
verification (-Vr). This got past the earlier error message I was getting,
and I was able to put the assembly into the GAC.

The only glitch I have now is that when I set breakpoint in the IL they are
hit, but I'm having trouble clearing the breakpoints!

I'm using VS 2005. I used the symbol files I generated as part of the
assembly re-creation. I associate the pdbs with the assembly I placed in the
GAC and the symbols are loaded properly. I then use the IDE to set
breakpoints in IL and these are hit, but when I attempt to delete the
breakpoints, they are still hit (even though they appear cleared in the IDE)!
Any hints or workarounds?

Thanks,
Notre

[Kevin Yu [MSFT]]

Hi Notre,

The strong name system is a way to maintain certain assembly is published
by certain publisher. A key is used to sign it to make sure that others
cannot modify it. If the assembly is modified, the key token will be
changed. Which means that you cannot modify the assembly and re-assign it,
unless you have the publisher's key file.

If this can be done, the whole strong named system will be broken. HTH.

Kevin Yu
Microsoft Online Community Support

================================================== ==========================
==========================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
================================================== ==========================
==========================

(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Notre Poubelle]

Thank you Kevin. I managed to get something to appear to work by disabling
strong name verification on my assembly before placing it into the GAC. This
is sufficient for my debugging needs (except the problem I'm having with
clearing the IL breakpoints). By disabling the strong name verification on
the assembly, what am I losing?

Thanks,
Notre

[Kevin Yu [MSFT]]

Hi Notre,

If this is only for debugging, I think OK. But it might break the reference
change for other assemblies, if other assemblies are referencing it with
strong named signature.

Kevin Yu
Microsoft Online Community Support

================================================== ==========================
==========================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
================================================== ==========================
==========================

(This posting is provided "AS IS", with no warranties, and confers no
rights.)