I have a minidump crashed from a .NET application. Is there any way to know the CLR version (e.g. version of mscorwks.dll) of the fault machine (which generates the crash dump) using either Windbg or some other tool?
In WinDbg: the easiest way is to use the !eeversion command, but if you want additional info you can use the lm command with the v verbose option for the runtime module mscorwks. If you're on .NET 4 the runtime is called clr, so in that case you need to change the command accordingly.
0:026> lm vm mscorwks
start end module name
79e70000 7a3ff000 mscorwks T (no symbols)
Loaded symbol image file: mscorwks.dll
Image path: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Image name: mscorwks.dll
Timestamp: Wed Oct 24 09:41:29 2007 (471EF729)
CheckSum: 00597AA8
ImageSize: 0058F000
File version: 2.0.50727.1433
Product version: 2.0.50727.1433
File flags: 0 (Mask 3F)
File OS: 4 Unknown Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
!EEVersion should give the CLR version.
Go verbose in WinDbg:
>lm v
............. (lots of modules).......
687d0000 68d06000 System_Xml_ni (deferred)
Image path: C:\Windows\assembly\NativeImages_v2.0.50727_32\System.Xml\38b9d09539b67b08ee996db6c71f8a9b\System.Xml.ni.dll
Image name: System.Xml.ni.dll
Has CLR image header, track-debug-data flag not set
Timestamp: Mon Oct 06 20:43:49 2008 (48EADAF5)
CheckSum: 00000000
ImageSize: 00536000
File version: 2.0.50727.3074
Product version: 2.0.50727.3074
File flags: 0 (Mask 3F)
File OS: 4 Unknown Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: Microsoft® .NET Framework
InternalName: System.Xml.dll
OriginalFilename: System.Xml.dll
ProductVersion: 2.0.50727.3074
FileVersion: 2.0.50727.3074 (QFE.050727-3000)
FileDescription: .NET Framework
LegalCopyright: © Microsoft Corporation. All rights reserved.
Comments: Flavor=Retail
Alternatively, load the dump in Visual Studio and use the Debug | Windows | Modules toolwindow to display some of this info.
Examples for two different .Net versions, using the version information of clr.dll:
.Net 4.0(.x?)
Image name: clr.dll
Timestamp: Thu Mar 18 21:39:07 2010 (4BA21EEB)
...
File version: 4.0.30319.1
Product version: 4.0.30319.1
.Net 4.5.2
Image name: clr.dll
Timestamp: Fri Nov 07 20:09:21 2014 (545CA861)
...
File version: 4.5.27.0
Product version: 4.0.30319.0
Related
I'm building zlib from source using Visual Studio 2012. Note, I didn't tag zlib here simply because I don't think the question is specific to any given project.
The build succeeds but when I use dumpbin /EXPORTS the output looks like this:
C:\Source\zlib>dumpbin /EXPORTS ./zlib1.dll
Microsoft (R) COFF/PE Dumper Version 11.00.61232.400
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file ./zlib1.dll
File Type: DLL
Section contains the following exports for zlib1.dll
00000000 characteristics
5DD6A00D time date stamp Thu Nov 21 08:32:45 2019
0.00 version
1 ordinal base
165 number of functions
119 number of names
ordinal hint RVA name
1 1 00001000 adler32
140 2 00001340 adler32_combine
2 3 00001410 compress
39 4 00001360 compress2
46 5 00001430 compressBound
However, when I examine a version someone else built (using VC6 - not sure if that matters), the output looks like:
C:\Source\zlib-1.2.7-win32>dumpbin /EXPORTS ./zlib1.dll
Microsoft (R) COFF/PE Dumper Version 11.00.61232.400
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file ./zlib1.dll
File Type: DLL
Section contains the following exports for zlib1.dll
00000000 characteristics
509EFCCB time date stamp Sat Nov 10 19:18:03 2012
0.00 version
1 ordinal base
76 number of functions
76 number of names
ordinal hint RVA name
1 0 00001000 adler32 = _adler32
2 1 00001270 adler32_combine = _adler32_combine
3 2 00001340 adler32_combine64 = _adler32_combine64
4 3 00001400 compress = _compress
5 4 00001360 compress2 = _compress2
6 5 00001420 compressBound = _compressBound
I'm having problems finding the visual studio setting that changes this output type. Next I tried just changing the .def file from
LIBRARY
; zlib data compression and ZIP file I/O library
VERSION 1.2
EXPORTS
adler32 #1
to
LIBRARY
; zlib data compression and ZIP file I/O library
VERSION 1.2
EXPORTS
_adler32=adler32 #1
But that appears to simply rename the export so instead of getting:
ordinal hint RVA name
1 0 00001000 adler32 = _adler32
I get:
ordinal hint RVA name
1 0 00001000 _adler32
and if you switch them around in the .def file, the project doesn't build/link correctly(makes sense).
So is there a setting in newer (than VC6) versions of VS that give /EXPORTS in the format somefunc=_somefunc?
According to this answer (C++ DLL Export: Decorated/Mangled names), they must have used Generate Debug Info = Yes
Seems like someone is playing a prank on me. My computer settings change between days and I'm certain that this version is a home-brew and not the original OS X.
Recovery/re-installation doesn't work because it restores itself after a day. How do I check if this is the original operating system?
messing around with the terminal raises a few red flags. For example:
master.passwd contains this:
nobody:*:-2:-2::0:0:Unprivileged User:/var/empty:/usr/bin/false
root:*:0:0::0:0:System Administrator:/var/root:/bin/sh
daemon:*:1:1::0:0:System Services:/var/root:/usr/bin/false
_uucp:*:4:4::0:0:Unix to Unix Copy Protocol:/var/spool/uucp:/usr/sbin/uucico
_taskgated:*:13:13::0:0:Task Gate Daemon:/var/empty:/usr/bin/false
_networkd:*:24:24::0:0:Network Services:/var/networkd:/usr/bin/false
_installassistant:*:25:25::0:0:Install Assistant:/var/empty:/usr/bin/false
_lp:*:26:26::0:0:Printing Services:/var/spool/cups:/usr/bin/false
_postfix:*:27:27::0:0:Postfix Mail Server:/var/spool/postfix:/usr/bin/false
_scsd:*:31:31::0:0:Service Configuration Service:/var/empty:/usr/bin/false
_ces:*:32:32::0:0:Certificate Enrollment Service:/var/empty:/usr/bin/false
_appstore:*:33:33::0:0:Mac App Store Service:/var/empty:/usr/bin/false
_mcxalr:*:54:54::0:0:MCX AppLaunch:/var/empty:/usr/bin/false
_appleevents:*:55:55::0:0:AppleEvents Daemon:/var/empty:/usr/bin/false
_geod:*:56:56::0:0:Geo Services Daemon:/var/db/geod:/usr/bin/false
_devdocs:*:59:59::0:0:Developer Documentation:/var/empty:/usr/bin/false
_sandbox:*:60:60::0:0:Seatbelt:/var/empty:/usr/bin/false
_mdnsresponder:*:65:65::0:0:mDNSResponder:/var/empty:/usr/bin/false
_ard:*:67:67::0:0:Apple Remote Desktop:/var/empty:/usr/bin/false
_www:*:70:70::0:0:World Wide Web Server:/Library/WebServer:/usr/bin/false
_eppc:*:71:71::0:0:Apple Events User:/var/empty:/usr/bin/false
_cvs:*:72:72::0:0:CVS Server:/var/empty:/usr/bin/false
_svn:*:73:73::0:0:SVN Server:/var/empty:/usr/bin/false
_mysql:*:74:74::0:0:MySQL Server:/var/empty:/usr/bin/false
_sshd:*:75:75::0:0:sshd Privilege separation:/var/empty:/usr/bin/false
_qtss:*:76:76::0:0:QuickTime Streaming Server:/var/empty:/usr/bin/false
_cyrus:*:77:6::0:0:Cyrus Administrator:/var/imap:/usr/bin/false
_mailman:*:78:78::0:0:Mailman List Server:/var/empty:/usr/bin/false
_appserver:*:79:79::0:0:Application Server:/var/empty:/usr/bin/false
_clamav:*:82:82::0:0:ClamAV Daemon:/var/virusmails:/usr/bin/false
_amavisd:*:83:83::0:0:AMaViS Daemon:/var/virusmails:/usr/bin/false
_jabber:*:84:84::0:0:Jabber XMPP Server:/var/empty:/usr/bin/false
_appowner:*:87:87::0:0:Application Owner:/var/empty:/usr/bin/false
_windowserver:*:88:88::0:0:WindowServer:/var/empty:/usr/bin/false
_spotlight:*:89:89::0:0:Spotlight:/var/empty:/usr/bin/false
_tokend:*:91:91::0:0:Token Daemon:/var/empty:/usr/bin/false
_securityagent:*:92:92::0:0:SecurityAgent:/var/db/securityagent:/usr/bin/false
_calendar:*:93:93::0:0:Calendar:/var/empty:/usr/bin/false
_teamsserver:*:94:94::0:0:TeamsServer:/var/teamsserver:/usr/bin/false
_update_sharing:*:95:-2::0:0:Update Sharing:/var/empty:/usr/bin/false
_installer:*:96:-2::0:0:Installer:/var/empty:/usr/bin/false
_atsserver:*:97:97::0:0:ATS Server:/var/empty:/usr/bin/false
_ftp:*:98:-2::0:0:FTP Daemon:/var/empty:/usr/bin/false
_unknown:*:99:99::0:0:Unknown User:/var/empty:/usr/bin/false
_softwareupdate:*:200:200::0:0:Software Update Service:/var/db/softwareupdate:/usr/bin/false
_coreaudiod:*:202:202::0:0:Core Audio Daemon:/var/empty:/usr/bin/false
_screensaver:*:203:203::0:0:Screensaver:/var/empty:/usr/bin/false
_locationd:*:205:205::0:0:Location Daemon:/var/db/locationd:/usr/bin/false
_trustevaluationagent:*:208:208::0:0:Trust Evaluation Agent:/var/empty:/usr/bin/false
_timezone:*:210:210::0:0:AutoTimeZoneDaemon:/var/empty:/usr/bin/false
_lda:*:211:211::0:0:Local Delivery Agent:/var/empty:/usr/bin/false
_cvmsroot:*:212:212::0:0:CVMS Root:/var/empty:/usr/bin/false
_usbmuxd:*:213:213::0:0:iPhone OS Device Helper:/var/db/lockdown:/usr/bin/false
_dovecot:*:214:6::0:0:Dovecot Administrator:/var/empty:/usr/bin/false
_dpaudio:*:215:215::0:0:DP Audio:/var/empty:/usr/bin/false
_postgres:*:216:216::0:0:PostgreSQL Server:/var/empty:/usr/bin/false
_krbtgt:*:217:-2::0:0:Kerberos Ticket Granting Ticket:/var/empty:/usr/bin/false
_kadmin_admin:*:218:-2::0:0:Kerberos Admin Service:/var/empty:/usr/bin/false
_kadmin_changepw:*:219:-2::0:0:Kerberos Change Password Service:/var/empty:/usr/bin/false
expected a command to set a master password...
There's a "VM" mounted disk hidden in /private/var/vm
it contains this file
$ cat sleepimage
and it returns:
Model: MBP121
EFI Version: 186.0.0.0.0
Built by: root#xapp160
Date: Fri Jun 14 09:21:38 PDT 2019
Revision: 186 (B&I)
ROM Version: F000_B00
Build Type: Official Build, Release
Compiler: Apple LLVM version 5.0 (clang-500.0.68) (based on LLVM 3.3svn)
Model: MBP121
EFI Version: 186.0.0.0.0
Built by: root#xapp160
Date: Fri Jun 14 09:21:38 PDT 2019
Revision: 186 (B&I)
ROM Version: F000_B00
Build Type: Official Build, Release
Compiler: Apple LLVM version 5.0 (clang-500.0.68) (based on LLVM 3.3svn)
garbled text
EFI Version: 186.0.0.0.0
Built by: root#xapp160
Date: Fri Jun 14 09:21:38 PDT 2019
Revision: 186 (B&I)
ROM Version: F000_B00
Build Type: Official Build, Release
Compiler: Apple LLVM version 5.0 (clang-500.0.68) (based on LLVM 3.3svn)
I am trying to debug a managed core dump, but it is hopeless, because the microsoft symbol server does not seem to contain the symbols for clr.dll version 4.6.1055.0.
Please, observe:
0:022> lmvm clr
Browse full module list
start end module name
73fa0000 74651000 clr (export symbols) clr.dll
Loaded symbol image file: clr.dll
Image path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Image name: clr.dll
Browse all global symbols functions data
Timestamp: Thu Nov 5 21:24:51 2015 (563C0F73)
CheckSum: 006B3E43
ImageSize: 006B1000
File version: 4.6.1055.0
Product version: 4.0.30319.0
File flags: 8 (Mask 3F) Private
File OS: 4 Unknown Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: Microsoft® .NET Framework
InternalName: clr.dll
OriginalFilename: clr.dll
ProductVersion: 4.6.1055.0
FileVersion: 4.6.1055.0 built by: NETFXREL2
PrivateBuild: DDBLD400
FileDescription: Microsoft .NET Runtime Common Language Runtime - WorkStation
LegalCopyright: © Microsoft Corporation. All rights reserved.
Comments: Flavor=Retail
0:022> .reload /f clr.dll
SYMSRV: BYINDEX: 0xDA
e:\symbols
clr.pdb
1C6AD585F62042AEB690C4C105CB9B962
SYMSRV: e:\symbols\clr.pdb\1C6AD585F62042AEB690C4C105CB9B962\clr.pdb - file not found
SYMSRV: e:\symbols\clr.pdb\1C6AD585F62042AEB690C4C105CB9B962\clr.pdb not found
SYMSRV: BYINDEX: 0xDB
http://msdl.microsoft.com/download/symbols
clr.pdb
1C6AD585F62042AEB690C4C105CB9B962
SYMSRV: HTTPGET: /download/symbols/clr.pdb/1C6AD585F62042AEB690C4C105CB9B962/clr.pdb
SYMSRV: HttpQueryInfo: 404 - HTTP_STATUS_NOT_FOUND
SYMSRV: HTTPGET: /download/symbols/clr.pdb/1C6AD585F62042AEB690C4C105CB9B962/clr.pd_
SYMSRV: HttpQueryInfo: 404 - HTTP_STATUS_NOT_FOUND
SYMSRV: HTTPGET: /download/symbols/clr.pdb/1C6AD585F62042AEB690C4C105CB9B962/file.ptr
SYMSRV: HttpQueryInfo: 404 - HTTP_STATUS_NOT_FOUND
SYMSRV: C:\ProgramData\dbg\sym\clr.pdb\1C6AD585F62042AEB690C4C105CB9B962\clr.pdb - file not found
SYMSRV: http://msdl.microsoft.com/download/symbols/clr.pdb/1C6AD585F62042AEB690C4C105CB9B962/clr.pdb not found
SYMSRV: C:\ProgramData\dbg\sym\clr.pdb\1C6AD585F62042AEB690C4C105CB9B962\clr.pdb not found
DBGHELP: clr.pdb - file not found
*** ERROR: Symbol file could not be found. Defaulted to export symbols for clr.dll -
DBGHELP: clr - export symbols
************* Symbol Loading Error Summary **************
Module name Error
clr PDB not found : cache*e:\symbols
Unable to locate the .pdb file in this location
The system cannot find the file specified : srv*http://msdl.microsoft.com/download/symbols
The SYMSRV client failed to find a file in the UNC store, or there
is an invalid UNC store (an invalid path or the pingme.txt file is
not present in the root directory), or the file is present in the
symbol server exclusion list.
So, I went to https://developer.microsoft.com/en-us/windows/hardware/download-symbols in hope to download the right symbols. But how do I know which one to download? I did download and installed the ones for Windows 10, x86 32-bit retail symbols of Windows 10 - September 2016 and Windows 10 and Windows Server 2016 - August 2016
But none contained the clr.pdb matching the GUID 1C6AD585F62042AEB690C4C105CB9B962.
What should I do? I am sure there is a better way that downloading and installing all of them.
The web archive has a copy of the desired page from 2016-07-30 where the files seem to be available for download.
If version 4.6.1055.0 of .NET 4.6 was part of the OS at the time it was released, chances are that your clr.pdb is included. I still wonder why it's not available via the official symbol server, but it has happened before that Microsoft simply "forgot" to put it there.
I am trying kernel debugging using vmware and windbg.I have connected two OS and all symbols are loaded successfully.If I want to see my driver in memory how can I disassembly that?
I have tried lm commands and lmvm commands
kd> lmvm comint32
start end module name
88da9000 88daf000 comint32 (private pdb symbols) C:\Program Files (x86)\Debugging Tools for Windows (x86)\sym\comint32.pdb\653387D894B4412FA9E30659E58DD47C1\comint32.pdb
Loaded symbol image file: comint32.sys
Image path: \SystemRoot\System32\Drivers\comint32.sys
Image name: comint32.sys
Timestamp: Thu Apr 11 20:10:55 2013 (51677B3F)
CheckSum: 0000CACF
ImageSize: 00006000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
x comint32!* should dump all the symbols of the module along with their addresses in memory.
You can then either use the u command (with the name (e.g. comint32!DriverEntry) or the address of a function as a parameter) to disassemble into the main window or you can open the disassembly window and paste the name/address into it and browse the disassembled code there.
See your windbg reference for further details.
I'm trying to dump heap information from full dump memory file sitting on Windows Server 2003 SP2 x86. Dump was created for 32-bit mixed (native/clr) application which was running on Windows Server 2003 SP2 x64 machine.
From the following windbg log I understand that loaded ntdll.dll image is incorrect and does not correspond to ntdll.pdb symbols. I have tried to specify the location to ntdll.dll from the target machine but windbg still shows that the module is loaded from the standard location (c:\windows\system32).
What did I do wrong? How to force windbg to load correct version of ntdll?
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.
[ ... skipped ... ]
0:042> vertarget
Windows Server 2003 Version 3790 (Service Pack 2) MP (4 procs) Free x86 compatible
Product: Server, suite: TerminalServer SingleUserTS
kernel32.dll version: 5.2.3790.4480 (srv03_sp2_gdr.090321-1244)
Machine Name:
Debug session time: Wed Mar 16 16:36:10.000 2011 (GMT-5)
System Uptime: 17 days 10:34:26.068
Process Uptime: 1 days 15:19:14.000
Kernel time: 0 days 1:24:01.000
User time: 0 days 22:07:58.000
0:042> .sympath
Symbol search path is: C:\mscordacwks\v2.0.50727.3615;C:\__exe;SRV*C\Symbols*http://referencesource.microsoft.com/symbols;SRV*c:\Symbols*http://msdl.microsoft.com/download/symbols;SRV*C:\Symbols*http://source.msdn.microsoft.com/symbols
0:042> .exepath
Executable image search path is: C:\__exe;C:\__target\Windows\SysWOW64;
0:042> .reload
[ ... skipped ... ]
0:042> .reload /u ntdll.dll
Unloaded ntdll.dll
0:042> .reload /v /f ntdll.dll
AddImage: C:\WINDOWS\system32\ntdll.dll // why is it still c:\windows\system32
DllBase = 7d600000
Size = 000f0000
Checksum = 000c371a
TimeDateStamp = 4cc1831e
0:042> lm
[ ... skipped ... ]
7d600000 7d6f0000 ntdll (pdb symbols) c:\symbols\wntdll.pdb\9ED8E09C6723448380648C4456726AEF2\wntdll.pdb
0:042> !heap
*************************************************************************
*** Your debugger is not using the correct symbols ***
[ ... skipped ... ]
*** Type referenced: ntdll!_HEAP_ENTRY ***
*************************************************************************
Invalid type information
0:042> lmi vm ntdll
start end module name
7d600000 7d6f0000 ntdll (pdb symbols) ntdll.dll
Symbol file: c:\symbols\wntdll.pdb\9ED8E09C6723448380648C4456726AEF2\wntdll.pdb
Image path: C:\WINDOWS\system32\ntdll.dll
Image name: ntdll.dll
Timestamp: Fri Oct 22 07:27:10 2010 (4CC1831E)
CheckSum: 000C371A
ImageSize: 000F0000
File version: 5.2.3790.4789 // this is correct and
Product version: 5.2.3790.4789 // does correspond to target computer
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: MicrosoftR WindowsR Operating System
InternalName: ntdll.dll
OriginalFilename: ntdll.dll
ProductVersion: 5.2.3790.4789
FileVersion: 5.2.3790.4789 (srv03_sp2_gdr.101019-0340)
FileDescription: NT Layer DLL
LegalCopyright: c Microsoft Corporation. All rights reserved.
UPDATE:
I moved a little bit further in my issue. I managed to connect to the live process on the customers side and tried to
investigate heap (heap -s) there and basically I got the same result.
(1520.7c4): Wake debugger - code 80000007 (first chance)
eax=00000000 ebx=00327d50 ecx=00000000 edx=00000000 esi=0030b428 edi=002debe4
eip=7d61c876 esp=002df008 ebp=002df06c iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000202
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\system32\ntdll.dll -
ntdll!ZwReadFile+0x15:
7d61c876 c22400 ret 24h
0:000> !heap -s
*************************************************************************
*** Your debugger is not using the correct symbols ***
*** [...skipped...] ***
*** Type referenced: ntdll!_HEAP_ENTRY ***
*************************************************************************
Invalid type information
0:000> .reload
Reloading current modules
................................................................
....................................
0:000> !heap -s
*************************************************************************
*** Your debugger is not using the correct symbols ***
*** [...skipped...] ***
*** Type referenced: ntdll!_HEAP_ENTRY ***
*************************************************************************
Invalid type information
I think I have a problem similar to one mentioned in this article http://support.microsoft.com/kb/959207.
Environment and problem seem to be the same but dll versions are different, so it is not the solution for me.
I think I have to escalate this problem to Microsoft.
Does anybody know where I should go with this question?
This could happen if dump was created with 64 bit tools. There is good information on Tess's blog that explains the reason why bitness of the dump matters.
The solution appears to be easy but not obvious.
I found a wntdll.pdb slightly bigger than mine which contains required symbols and reloaded it with command .reload /f /i ntdll.dll
and I take the previous build of windbg 6.11.0001.404, in the current one 6.12.0002.633 !heap command still does not work in my case.
It looks like the type _HEAP_ENTRY is not included in the pdb of 2003 SP2 ntdll.dll
Microsoft released a hotfix http://support.microsoft.com/kb/959207, but you seem to have a later ntdll version.