Re: How to debug system.typeloadexception
- From: David Morris <dmmorris@xxxxxxxxxxxxxxxx>
- Date: Wed, 9 Apr 2008 15:46:01 -0700
Thanks for the help. Based on your post, I was able to see the problem when I
installed the right .NET Framework SDK and ran DbgClr.exe. It looks like a
class that is loaded dynamically did not get output by the setup project. I
had installed the 3.5 SDK thinking it was a superset of the 2.0 SDK. It
appears as if it doesn't include the CLR debugger.
Thanks,
David Morris
"Jeroen Mostert" wrote:
David Morris wrote:.
I created an installer package and it works on some machines and not others.Try enabling Fusion logging:
I get an error "system.typeloadexception", which I believe is telling me that
an assembly that is loaded in the GAC on my development machine is missing on
the target machine. Unfortunately, I can't identify the missing assembly from
the message. The target machine is a VM that I can restore so I am looking
for advice on how I can get more information (like a stack trace).
http://blogs.msdn.com/suzcook/archive/2003/05/29/57120.aspx
I tried installing the SDK and Visual Studio Express on the target machine
but I still don't have the dbgclr.exe -- I am not sure why.
dbgclr is installed with the .NET SDK
(http://www.microsoft.com/downloads/details.aspx?FamilyID=fe6f2099-b7b4-4f47-a244-c96d69c35dec).
After that it should be in the "Tools" map of the SDK entry on the Start Menu.
The .NET SDK is not the .NET redistributable, not the Platform SDK, and not
Visual Studio, and dbgclr is included with none of those. There's also
cordbg and mdbg and of course ntsd, cdb and windbg! There's certainly no
shortage of debugging options for Windows.
I have reviewed the approximately 50 DLL's and can't come up with<snip>
anything that is missing.
How can I identify the missing assembly (if that is the problem). I did
install windbg, which seems to indicate an Infragistics dll may be the
problem but all of the Infragistics dlls from my development machine are in
the application directory and at least some of them load because the window
starts to appear. Here is that trace:
Quite useless, I'm afraid.
I have little experience using the managed debuggers (other than VS itself),
but if neither Fusion logs nor dbgclr can help you out, windbg can still
tell you what happened by leveraging some extensions. Try entering the
following when you get a managed exception:
..symfix
..reload
..loadby sos mscorwks
!pe -nested
The latter command prints details of the managed exception. Another useful
command is "!dumpstack -ee" for the managed call stack at the time of the
exception ("!dumpstack" to include unmanaged functions).
Overall, the native debuggers are best at diagnosing interop problems (and
internal CLR errors, if you're so inclined). If you don't need to go that
deep, managed debugging is a lot more convenient.
--
J.
- Follow-Ups:
- Re: How to debug system.typeloadexception
- From: "Jeffrey Tan[MSFT]"
- Re: How to debug system.typeloadexception
- References:
- How to debug system.typeloadexception
- From: David Morris
- Re: How to debug system.typeloadexception
- From: Jeroen Mostert
- How to debug system.typeloadexception
- Prev by Date: Re: How to debug system.typeloadexception
- Next by Date: Re: How to debug system.typeloadexception
- Previous by thread: Re: How to debug system.typeloadexception
- Next by thread: Re: How to debug system.typeloadexception
- Index(es):
Relevant Pages
|