 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Visual Studio.NET / Debugging / April 2006"Unable to load image" .... b77a5c561934e089_df60ae4e\mscorlib.dll for dump debugging
How can I load the relevant symbols? Where should I place the original (missing) dll and what path to set? When debugging crash dump - I found this in one of the stack traces: --- ... 0012f354 00a3a42a 00000003 0be175c0 00000100 kernel32!ReadFile+0x64 Unable to load image c:\WINDOWS\assembly\nativeimages1_v1.1.4322\mscorlib\1.0.5000.0__b77a5c561934e089_df60ae4e\mscorlib.dll, Win32 error 2 *** WARNING: Unable to verify timestamp for mscorlib.dll *** ERROR: Module load completed but symbols could not be loaded for mscorlib.dll WARNING: Frame IP not in any known module. Following frames may be wrong. ... --- This version of mscorlib does not exist on my machine (I have 2 other fersions under "C:\WINDOWS\assembly\NativeImages1_v1.1.4322\mscorlib\") Copying it does not help. My SymbolsPath is: srv*c:\websymbols*http://msdl.microsoft.com/download/symbols; and most symbols load just fine Dekel Additional info: I found it was not copied previousely After copying it I get the following error for the same thread instead: --- 0012f354 00a3a42a 00000003 0be175c0 00000100 kernel32!ReadFile+0x64 *** WARNING: Unable to verify checksum for mscorlib.dll *** ERROR: Module load completed but symbols could not be loaded for mscorlib.dll WARNING: Frame IP not in any known module. Following frames may be wrong. 0012f3b8 79aa83fa 0012f3e0 00000000 00000100 0xa3a42a 00000100 00000000 00000000 00000000 00000000 mscorlib_79990000+0x1183fa --- > Additional info: > [quoted text clipped - 11 lines] > 00000100 00000000 00000000 00000000 00000000 mscorlib_79990000+0x1183fa > --- This is an NGEN-ed copy of mscorlib.dll, and such modules usually do not have symbols in .NET 1.x. You can try to use SOS extension and its !clrstack and !dumpstack commands to get the call stack of this thread. Regards, Oleg [VC++ MVP http://www.debuginfo.com/] Hi Oleg and thanks for your reply it seems like the SOS does not recognize this as a managed thread sinsce someting went wrong during the loading of mscorlib.dll What am I doing wrong? Why is it telling "Unable to verify checksum for mscorlib.dll" - What is needed in order to verify the checksum? - Any link to relevant article will be appreciated This seems to prevent understanding any managed code in other threads call stack Is there a way to do one of the following: 1. Obtain the relevant symbols 2. See managed call stack even though the symbols are not found for this mscorlib.dll 3. Make the CLR use a version of mscorlib.dll for which I can obtain the symbols 4. workaround this in other way See the result of !clrstack and !dumpstack below Thanks Dekel 0:061> ~0kb ChildEBP RetAddr Args to Child 0012f158 7c821c94 7c836066 00000018 0012f1b8 ntdll!KiFastSystemCallRet 0012f15c 7c836066 00000018 0012f1b8 0012f1b8 ntdll!NtRequestWaitReplyPort+0xc 0012f17c 77eaaba3 00000000 00240688 0002021d ntdll!CsrClientCallServer+0x8c 0012f274 77eaacb8 00000003 097d8908 00000100 kernel32!ReadConsoleInternal+0x1b8 0012f2fc 77e41990 00000003 097d8908 00000100 kernel32!ReadConsoleA+0x3b 0012f354 00aca42a 00000003 097d8908 00000100 kernel32!ReadFile+0x64 *** WARNING: Unable to verify checksum for mscorlib.dll *** ERROR: Module load completed but symbols could not be loaded for mscorlib.dll WARNING: Frame IP not in any known module. Following frames may be wrong. 0012f3b8 79aa83fa 0012f3e0 00000000 00000100 0xaca42a 00000100 00000000 00000000 00000000 00000000 mscorlib_79990000+0x1183fa 0:061> ~0e!clrstack Loaded Son of Strike data table version 5 from "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorwks.dll" Thread 0 Not a managed thread. 0:061> ~0e!dumpstack Thread 0 Current frame: ntdll!KiFastSystemCallRet ChildEBP RetAddr Caller,Callee 0012f158 7c821c94 ntdll!NtRequestWaitReplyPort+0xc 0012f15c 7c836066 ntdll!CsrClientCallServer+0x8c, calling ntdll!ZwRequestWaitReplyPort 0012f17c 77eaaba3 kernel32!ReadConsoleInternal+0x1b8, calling ntdll!CsrClientCallServer 0012f274 77eaacb8 kernel32!ReadConsoleA+0x3b, calling kernel32!ReadConsoleInternal 0012f2fc 77e41990 kernel32!ReadFile+0x64, calling kernel32!ReadConsoleA 0012f3e0 799ea3ff 799ea3ff 0012f408 79ab223b 79ab223b 0012f410 79a09c95 79a09c95 0012f69c 7923c069 mscorwks!CallDescrWorker+0x30 0012f6a4 7923e0bc mscorwks!MethodDesc::CallDescr+0x1b8, calling mscorwks!CallDescrWorker 0012f6d4 791d7b5e mscorwks!MetaSig::SizeOfActualFixedArgStack+0x14, calling mscorwks!MetaSig::ForceSigWalk 0012f6e4 7923dfae mscorwks!MethodDesc::CallDescr+0x79, calling mscorwks!MetaSig::SizeOfActualFixedArgStack 0012f6e8 7923dfbe mscorwks!MethodDesc::CallDescr+0x89, calling mscorwks!_alloca_probe 0012f758 791b54ef mscorwks!StgPoolReadOnly::GetBlob+0x3f, calling mscorwks!CPackedLen::GetLength 0012f774 791d7774 mscorwks!CMiniMdTemplate<CMiniMd>::getSignatureOfMethod+0x3b 0012f790 791d77a6 mscorwks!MDInternalRO::GetSigOfMethodDef+0x2b, calling mscorwks!CMiniMdTemplate<CMiniMd>::getSignatureOfMethod 0012f7b4 7923e2a7 mscorwks!MethodDesc::CallDescr+0x4f, calling mscorwks!MethodDesc::CallDescr 0012f814 791b54ef mscorwks!StgPoolReadOnly::GetBlob+0x3f, calling mscorwks!CPackedLen::GetLength 0012f830 791d7774 mscorwks!CMiniMdTemplate<CMiniMd>::getSignatureOfMethod+0x3b 0012f84c 791d77a6 mscorwks!MDInternalRO::GetSigOfMethodDef+0x2b, calling mscorwks!CMiniMdTemplate<CMiniMd>::getSignatureOfMethod 0012f85c 791d7360 mscorwks!MethodDesc::GetSig+0x4c 0012f870 7923e315 mscorwks!MethodDesc::Call+0x97, calling mscorwks!MethodDesc::CallDescr 0012f898 7923a6b5 mscorwks!ClassLoader::CanAccess+0x1d6, calling mscorwks!MethodDesc::Call 0012f8e4 791b76aa mscorwks!CMiniMdBase::getIX+0x21, calling mscorwks!MetaDataTracker::NoteAccess 0012f910 791b8d3a mscorwks!ClassLoader::LoadTypeHandle+0x23a, calling mscorwks!ClassLoader::LoadTypeHandle 0012f938 791d785e mscorwks!Module::LookupMethodDef+0x18, calling mscorwks!Module::GetFromRidMap 0012f950 7923a8fa mscorwks!ClassLoader::ExecuteMainMethod+0x49d, calling mscorwks!ClassLoader::CanAccess+0x3e 0012fa14 7c82f9dd ntdll!RtlFreeHeap+0x70f, calling ntdll!_SEH_epilog 0012fa28 77e6bacd kernel32!WaitForSingleObjectEx+0xdc, calling kernel32!_SEH_epilog 0012fa64 7923a56f mscorwks!Assembly::ExecuteMainMethod+0x21, calling mscorwks!ClassLoader::ExecuteMainMethod 0012fa7c 7923a4ba mscorwks!SystemDomain::ExecuteMainMethod+0x421, calling mscorwks!Assembly::ExecuteMainMethod 0012fac4 7c82fda6 ntdll!RtlAllocateHeap+0x460, calling ntdll!RtlLeaveCriticalSection 0012fb48 7c8302b3 ntdll!RtlpFreeToHeapLookaside+0x22, calling ntdll!RtlpInterlockedPushEntrySList 0012fb54 7c82f9c1 ntdll!RtlFreeHeap+0x20e, calling ntdll!RtlpFreeToHeapLookaside 0012fbec 7c830da7 ntdll!RtlpDosPathNameToRelativeNtPathName_Ustr+0x3cb, calling ntdll!_SEH_epilog 0012fbf0 7c830f0f ntdll!RtlpDosPathNameToRelativeNtPathName_U+0x55, calling ntdll!RtlpDosPathNameToRelativeNtPathName_Ustr 0012fc10 7c8339a3 ntdll!LdrpSnapThunk+0xc0, calling ntdll!LdrpNameToOrdinal 0012fc3c 7c831fb2 ntdll!RtlImageNtHeaderEx+0xee, calling ntdll!_SEH_epilog 0012fc50 7c832742 ntdll!RtlImageDirectoryEntryToData+0x57, calling ntdll!RtlpImageDirectoryEntryToData32 0012fc70 7c832b78 ntdll!LdrUnlockLoaderLock+0x84, calling ntdll!RtlLeaveCriticalSection 0012fc74 7c832b7f ntdll!LdrUnlockLoaderLock+0xad, calling ntdll!_SEH_epilog 0012fca0 7c832b7f ntdll!LdrUnlockLoaderLock+0xad, calling ntdll!_SEH_epilog 0012fca4 77e68e4c kernel32!GetModuleFileNameW+0x10d, calling ntdll!LdrUnlockLoaderLock 0012fcb0 77e68e33 kernel32!GetModuleFileNameW+0xf2, calling kernel32!_SEH_epilog 0012fccc 77e58ebc kernel32!VirtualQuery+0x15, calling kernel32!VirtualQueryEx 0012fd0c 791b90b9 mscorwks!Bucket::InsertValue+0xb, calling mscorwks!Bucket::HasFreeSlots 0012fd18 791b9150 mscorwks!HashMap::InsertValue+0x60, calling mscorwks!Bucket::InsertValue 0012fd20 791b9167 mscorwks!HashMap::InsertValue+0x98, calling mscorwks!AutoCooperativeGC::~AutoCooperativeGC 0012fd60 791c6afa mscorwks!ExecuteEXE+0x1ce, calling mscorwks!SystemDomain::ExecuteMainMethod 0012fe50 791b8bbe mscorwks!ClassLoader::LoadTypeHandle+0x6e6, calling mscorwks!_SEH_epilog 0012fe54 791b8d3a mscorwks!ClassLoader::LoadTypeHandle+0x23a, calling mscorwks!ClassLoader::LoadTypeHandle 0012fe68 791b8d4f mscorwks!ClassLoader::LoadTypeHandle+0x24b, calling mscorwks!Thread::DisablePreemptiveGC 0012fe78 791b4e53 mscorwks!GCFrame::GCFrame+0x23, calling mscorwks!GCFrame::Init 0012fe90 791b9ebe mscorwks!EEClass::CheckRestore+0x7c, calling mscorwks!ClassLoader::LoadTypeHandle 0012fea0 791b9ecf mscorwks!EEClass::CheckRestore+0x91, calling mscorwks!GCFrame::Pop 0012fef8 791b9f28 mscorwks!Binder::FetchClass+0x2d, calling mscorwks!MethodTable::CheckRestore 0012ff04 791c7f11 mscorwks!EEStartup+0x621, calling mscorwks!Binder::FetchClass 0012ff3c 791c7fb9 mscorwks!TryEEStartup+0x21, calling mscorwks!EEStartup 0012ff40 791c7fd1 mscorwks!TryEEStartup+0x5a, calling mscorwks!_SEH_epilog 0012ff5c 791c7fd1 mscorwks!TryEEStartup+0x5a, calling mscorwks!_SEH_epilog 0012ff70 791c6bf7 mscorwks!CoInitializeEE+0x94, calling mscorwks!_SEH_epilog 0012ffa0 791c69f2 mscorwks!_CorExeMain+0x59, calling mscorwks!ExecuteEXE 0012ffc0 77e523cd kernel32!BaseProcessStart+0x23 Hi Dekel, > it seems like the SOS does not recognize this as a managed thread > sinsce someting went wrong during the loading of mscorlib.dll > What am I doing wrong? I would suspect that the crash dump does not contain enough information for SOS to work. How do you create the crash dump? > Why is it telling "Unable to verify checksum for mscorlib.dll" Because it does not contain the checksum in the file header. It is not a problem, since many executables do not contain the checksum. > - What is needed in order to verify the checksum? It is not necessary to verify it (and not possible in this case). It does not affect debugging, though. > - Any link to relevant article will be appreciated See /release linker option in MSDN. > This seems to prevent understanding any managed code in other threads > call stack > Is there a way to do one of the following: > 1. Obtain the relevant symbols No way in this case, but symbols for this module are not usually needed to get the managed call stack. > 2. See managed call stack even though the symbols are not found for > this mscorlib.dll It should be possible even without symbols, assuming that the module itself is available and can be found by the debugger. > 3. Make the CLR use a version of mscorlib.dll for which I can obtain > the symbols I guess it is not possible, at least in general case (though I cannot be completely sure). > 4. workaround this in other way Let's start with checking my guess that the crash dump does not contain enough information. Oleg Hi Oleg > How do you create the crash dump? This dump was created by VS 2003 that attached to the process after the AV * It seems like there is incompatibility between the dump created by VS and the dump created by the debugging tools (ADPlus cdb) - When I open VS dump in windbg I get the problem I reported in this thread - When I try to open the dump created by ADPlus in VS the VS itself crashes Is it a known issue? I understand the checksum warning should be ignored (?) I still have a problem understanding managed call stacks (Could be a VS dump issue though) Thanks Dekel > > How do you create the crash dump? > This dump was created by VS 2003 - that attached to the process after > the AV At the bottom of the Save Dump As dialog you can select the type of the dump. Probably you have kept the default selection ("Minidump"), which is not enough for SOS. You can try to select "Minidump with Heap" and see if it helps. > * It seems like there is incompatibility between the dump created by > VS and the dump created by the debugging tools (ADPlus ? cdb) [quoted text clipped - 4 lines] > > Is it a known issue? I don't know. Usually VS can debug minidumps created with ADPlus/CDB. > I understand the checksum warning should be ignored (?) Yes. > I still have a problem understanding managed call stacks (Could be a VS > dump issue though) Yes, try to use "Minidump with heap", or ".dump /ma" command in CDB and see if managed call stacks appear. Oleg Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.