Is it possible to get information about the host where a dump file was been created e.g., OS version, service pack, .NET framework version etc.
Also the vertarget command displays current version of the Microsoft Windows operating. system
OS version and so forth is listed automatically when you open the dump file.
You can get the .NET framework version using the !eeversion command.
0:000> !eeversion
2.0.50727.4952 free
Workstation mode
SOS Version: 2.0.50727.4952 retail build
To get additional information for loaded modules use the verbose option for lm. E.g.
0:000> lm vm mscoree
start end module name
000007fe`f0f10000 000007fe`f0f7f000 mscoree (deferred)
Image path: C:\Windows\System32\mscoree.dll
Image name: mscoree.dll
Timestamp: Fri Nov 06 06:09:26 2009 (4AF3AF86)
CheckSum: 00072187
ImageSize: 0006F000
File version: 4.0.31106.0
Product version: 4.0.31106.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: mscoree.dll
OriginalFilename: mscoree.dll
ProductVersion: 4.0.31106.0
FileVersion: 4.0.31106.0 (Main.031106-0000)
PrivateBuild: DDBLD278
FileDescription: Microsoft .NET Runtime Execution Engine
LegalCopyright: © Microsoft Corporation. All rights reserved.
Comments: Flavor=Retail
Related
Is there a way to retrieve the process description and publisher from a Windows Kernel crash dump?
I tried !process and !dml_proc. It doesn't show that information.
Description sould be get from exe module.
Example:
0: kd> !PROCESS fffffa800482f940 2
GetPointerFromAddress: unable to read from fffff80397f65000
PROCESS fffffa800482f940
SessionId: 1 Cid: 0e3c Peb: 7f7cfefa000 ParentCid: 04bc
DirBase: 26bcc000 ObjectTable: fffff8a0028f4e80 HandleCount: <Data Not Accessible>
Image: Taskmgr.exe
0: kd> .process /p fffffa800482f940
Implicit process is now fffffa80`0482f940
0: kd> .reload /user
Loading User Symbols
..........................................................
0: kd> lmvm Taskmgr
Browse full module list
start end module name
000007f7`d08c0000 000007f7`d09da000 taskmgr (deferred)
Image path: C:\Windows\system32\taskmgr.exe
Image name: taskmgr.exe
Browse all global symbols functions data
Timestamp: Thu Jul 26 02:07:18 2012 (50107C26)
CheckSum: 00119B41
ImageSize: 0011A000
File version: 6.2.9200.16384
Product version: 6.2.9200.16384
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 1.0 App
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: Microsoft® Windows® Operating System
InternalName: Taskmgr.exe
OriginalFilename: Taskmgr.exe
ProductVersion: 6.2.9200.16384
FileVersion: 6.2.9200.16384 (win8_rtm.120725-1247)
FileDescription: Task Manager
LegalCopyright: © Microsoft Corporation. All rights reserved.
i was trying to edit and post clarification to pykd-teams answer but the edit turned out ot be substantial so posted this as an answer
FileDescription from lmvm output refers to description column in Task manager Details tab
Company Name Refers refers to publisher column in startup tab
C:\Windows\system32>wmic Startup where Caption="vmware user process" get /format:list
Caption=VMware User Process
Command="C:\Program Files\VMware\VMware Tools\vmtoolsd.exe" -n vmusr
Description=VMware User Process
Location=HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
Name=VMware User Process
SettingID=
User=Public
UserSID=
C:\Windows\system32>reg query hklm\software\microsoft\windows\currentversion\run
HKEY_LOCAL_MACHINE\software\microsoft\windows\currentversion\run
VMware User Process REG_SZ "C:\Program Files\VMware\VMware Tools\vmtoolsd.exe" -n vmusr
you can check by modifiying the FILE_VERSION_INFO in rsrc section of any file that is executed in startup see below an edited publisher in windbg of the same exe as posted above
how to check for validity of the above assertion
open a live kd session
run task manager in target and select a startup
look at details and locate the process name say vmtoolsd.exe
break into kd using ctrl+break
!process 0 0 vmtoolsd.exe
.process /p /r EPROCESS ADDRESS OF vmtoolsd.exe
!dh vmtoolsd find the Data directory SECURITY DIRECTORY and start searching for FILE_VERSION_INFO
loacte the string value of Company Name
use eb Address to edit the Company Name to some random string
execute using g
now execute task manager and you will see the publisher column in startup tab reflecting the random string as publisher
username is not tied to file but to process grab the token
from !process <Eproc> 1 and pass the TOKEN value to !token -n
here is sample script to retrieve user names for each running process
!for_each_process "r $t0=(##c++(((_EPROCESS*) ##Process )->Token.Object)&0xfffffff8);r? $t1=##c++(((_TOKEN*)##(#$t0))->LogonSession->AccountName);r? $t2=##c++(((_EPROCESS *) ##Process )->ImageFileName);.printf \"%mu\t\t\t%ma\\n\",##c++((wchar_t *)#$t1.Buffer),##c++((char*)#$t2)"
should get your results like this
kd> $$>a< getuname4proc.txt
xx-PC$ smss.exe
LOCAL SERVICE svchost.exe
xx taskhost.exe
You can get this information and a lot more by using !ps command from DbgKit.
Note: From a Kernel Memory Dump you can only get User Name. To get User Name, File Description and Company Name you need a Complete Memory Dump.
Copy dbgkit.dll into winext folder (For example: C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\winext)
Open a dump file in WinDbg
Run .load dbgkit command
Run !ps command (to view other commands run !dbgkit.help)
I am working on a game in UDK, and sometimes the game crashes when restarting the level or trying to open a new one.
I cannot find the problem trough the log files, they are just displaying a critical error.
Now I am trying to fix it by examining the crash dump, but I do not have a clue how to do this. Does anyone have an idea how I can further investigate the problem? I tried some things that I found online and this is what I have so far.
*** ERROR: Symbol file could not be found. Defaulted to export symbols for UDK.exe -
eax=00000000 ebx=39280070 ecx=0cdc0f10 edx=ffffffff esi=2a193f40 edi=296f96a0
eip=01c2caf3 esp=007cdf84 ebp=2c0132b0 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010246
UDK!GetStackOwnerClass+0x10a73:
01c2caf3 8b10 mov edx,dword ptr [eax] ds:002b:00000000=????????
0:000> !sym noisy
noisy mode - symbol prompts on
0:000> lmvm ntdll
start end module name
77890000 77a10000 ntdll (export symbols) ntdll.dll
Loaded symbol image file: ntdll.dll
Mapped memory image file: C:\Windows\SysWOW64\ntdll.dll
Image path: C:\Windows\SysWOW64\ntdll.dll
Image name: ntdll.dll
Timestamp: Thu Aug 29 03:50:31 2013 (521EA8E7)
CheckSum: 00140982
ImageSize: 00180000
File version: 6.1.7601.18247
Product version: 6.1.7601.18247
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: Microsoft® Windows® Operating System
InternalName: ntdll.dll
OriginalFilename: ntdll.dll
ProductVersion: 6.1.7601.18247
FileVersion: 6.1.7601.18247 (win7sp1_gdr.130828-1532)
FileDescription: NT Layer DLL
LegalCopyright: © Microsoft Corporation. All rights reserved.
The most basic analysis in WInDbg is done with
.symfix
.reload
!analyze -v
Since it crashes, there should be an exception somewhere. Try
.ecxr
.exr -1
Also the call stack is potentially interesting. Since this is about UDK (Unreal Engine Development Kit), I assume it's written in C++ and thus we need a native call stack
k
When I load a crash dump in windbg (x64), version 6.3.9600.16384, and load the sos extension for .net, the first time I run the !threads command I get this error:
c0000005 Exception in C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos.threads debugger extension.
PC: 00007ffa`8fe6c7e3 VA: 00000000`00000000 R/W: 0 Parameter: 00000000`00000000
Subsequent times the command runs fine. Full transcript:
Loading Dump File [C:\Users\celdredge\AppData\Local\Temp\w3wp (2).DMP]
User Mini Dump File with Full Memory: Only application data is available
************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred srv*
************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred srv*
OK c:\projects\dumps\symbols
Symbol search path is: srv*;c:\projects\dumps\symbols
Executable search path is: srv*
Windows 8 Version 9600 MP (4 procs) Free x64
Product: WinNt, suite: SingleUserTS
Built by: 6.3.9600.16384 (winblue_rtm.130821-1623)
Machine Name:
Debug session time: Tue Dec 17 23:03:00.000 2013 (UTC - 5:00)
System Uptime: 0 days 9:56:04.777
Process Uptime: 0 days 0:01:41.000
................................................................
................................................................
......................................................
ntdll!NtWaitForSingleObject+0xa:
00007ffa`a1d265ba c3 ret
0:000> .loadby sos clr
0:000> !threads
c0000005 Exception in C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos.threads debugger extension.
PC: 00007ffa`8fe6c7e3 VA: 00000000`00000000 R/W: 0 Parameter: 00000000`00000000
CLR version:
0:000> lm v mclr
start end module name
00007ffa`84450000 00007ffa`84de8000 clr (pdb symbols) C:\ProgramData\dbg\sym\clr.pdb\252574218A084BE3AFEFF8921ADADB6F2\clr.pdb
Loaded symbol image file: clr.dll
Image path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Image name: clr.dll
Browse all global symbols functions data
Timestamp: Tue Sep 10 02:54:48 2013 (522EC238)
CheckSum: 00994334
ImageSize: 00998000
File version: 4.0.30319.34003
Product version: 4.0.30319.34003
SOS version:
0:000> .chain
Extension DLL search Path:
<snip/>
Extension DLL chain:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\SOS.dll: image 4.0.30319.34003, API 1.0.0, built Tue Sep 10 02:44:16 2013
[path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos.dll]
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos: image 4.0.30319.34003, API 1.0.0, built Tue Sep 10 02:44:16 2013
[path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos.dll]
This seems to be a weird issue caused by saving an explicit workspace which remembers which extensions are loaded. If I .loadby sos clr and save the workspace, next time I open the workspace it will have sos loaded twice. However if I do .load c:\path\to\sos.dll and save the workspace, it only gets loaded once when I reopen it.
In summary, workspaces in windbg are confusing.
I am starting windbg using the following command line:
C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64>windbg -i c:\tmp\Psscor4\amd64;c:\tmp\Psscor4\x86;c:\tmp;srv*E:\symbols*http://msdl.microsoft.com/download/symbols
C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x64>
Then I load a memory crash dump and inspect where did it load the clr.dll from:
Microsoft (R) Windows Debugger Version 6.2.9200.20512 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\tmp\Memory.dmp]
User Mini Dump File with Full Memory: Only application data is available
Comment: 'Dump created by DbgHost. First chance exception 0XE0434352'
Symbol search path is: c:\tmp\Psscor4\amd64;c:\tmp\Psscor4\x86;c:\tmp;srv*E:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is: c:\tmp\Psscor4\amd64;c:\tmp\Psscor4\x86;c:\tmp;srv*E:\symbols*http://msdl.microsoft.com/download/symbols
Windows 7 Version 7601 (Service Pack 1) MP (16 procs) Free x64
Product: Server, suite: Enterprise TerminalServer SingleUserTS
Built by: 6.1.7601.17965 (win7sp1_gdr.121004-0333)
Machine Name:
Debug session time: Mon Oct 14 13:45:55.000 2013 (UTC - 4:00)
System Uptime: not available
Process Uptime: 0 days 2:49:12.000
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
............................................................
Loading unloaded module list
..
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(5768.5db4): CLR exception - code e0434352 (first/second chance not available)
KERNELBASE!RaiseException+0x39:
000007fe`fd33bccd 0000 add byte ptr [rax],al ds:00000000`3af07bb2=00
0:122> lm vm clr
start end module name
000007fe`f9a70000 000007fe`fa3ce000 clr (deferred)
Image path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Image name: clr.dll
Timestamp: Mon Jul 09 00:10:25 2012 (4FFA59B1)
CheckSum: 00959DDE
ImageSize: 0095E000
File version: 4.0.30319.17929
Product version: 4.0.30319.17929
File flags: 8 (Mask 3F) Private
File OS: 4 Unknown Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
0:122> ld clr
Symbols loaded for clr
0:122> lm vm clr
start end module name
000007fe`f9a70000 000007fe`fa3ce000 clr (pdb symbols) e:\symbols\clr.pdb\D3D86782AEDD446F917F5D81FDFD3D252\clr.pdb
Loaded symbol image file: clr.dll
Mapped memory image file: c:\tmp\clr.dll
Image path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Image name: clr.dll
Timestamp: Mon Jul 09 00:10:25 2012 (4FFA59B1)
CheckSum: 00959DDE
ImageSize: 0095E000
File version: 4.0.30319.17929
Product version: 4.0.30319.17929
File flags: 8 (Mask 3F) Private
File OS: 4 Unknown Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
0:122> .exepath
Executable image search path is: c:\tmp\Psscor4\amd64;c:\tmp\Psscor4\x86;c:\tmp;srv*E:\symbols*http://msdl.microsoft.com/download/symbols
Expanded Executable image search path is: c:\tmp\psscor4\amd64;c:\tmp\psscor4\x86;c:\tmp;srv*e:\symbols*http://msdl.microsoft.com/download/symbols
So, my question is why does windbg insist on loading clr.dll from C:\Windows\Microsoft.NET\Framework64\v4.0.30319 when both the image path and the symbol path direct to another location where sits the clr.dll that I truly need - c:\tmp?
Now, when I force loading of the symbols, then we can see this:
Loaded symbol image file: clr.dll
Mapped memory image file: c:\tmp\clr.dll
Image path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Image name: clr.dll
I do not like it. I want the image path to come from c:\tmp as well.
How do I do it?
The Image path shows where debugee (the process which were dumped) found the clr.dll.
Like it or not, it's noting you can do about it :-)
TL;DR
Why does WinDBG lmvdisplay two version info fields (when no other tool I know of does this) and under which circumstances can these fields differ?
Background: I have a live dump (from a deadlock) of our application. Symbols are loaded correctly and I was able to trace back the deadlock to Microsoft's pdm.dll ("Process Debug Manager" used for our vbscript engine).
I then wanted to check which version of this DLL was loaded in the session at the production site:
0:000> lmv m pdm
start end module name
51860000 518b8000 pdm # (pdb symbols) d:\symcache\pdm.pdb\7BE601EDE9234816B72B49DA4A25DF042\pdm.pdb
Loaded symbol image file: pdm.dll
Image path: C:\Program Files (x86)\Common Files\Microsoft Shared\VS7DEBUG\pdm.dll
Image name: pdm.dll
Timestamp: Tue Jul 29 16:46:11 2008 (488F2D33)
CheckSum: 000663E0
ImageSize: 00058000
?? File version: 9.0.30729.1
?? Product version: 9.0.30729.1
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® Visual Studio .NET
InternalName: pdm.dll
OriginalFilename: pdm.dll
?? ProductVersion: 7.10.3077
?? FileVersion: 7.10.3077
FileDescription: Process Debug Manager
LegalCopyright: Copyright© Microsoft Corporation. All rights reserved.
As you can see, the file and product versions are displayed twice, but they are mismatched in the dump!
When I cross-check on my machine for (apparently, see the timestamp and checksum!) the same file for a running iexplore process:
0:043> lmv m pdm
start end module name
3efa0000 3eff8000 pdm (pdb symbols) c:\windows\symbols\martin-cache\pdm.pdb\415D0A165EB24613BC01CE516512062C2\pdm.pdb
Loaded symbol image file: C:\Program Files (x86)\Internet Explorer\pdm.dll
Image path: C:\Program Files (x86)\Internet Explorer\pdm.dll
Image name: pdm.dll
Timestamp: Tue Jul 29 16:46:11 2008 (488F2D33)
CheckSum: 000663E0
ImageSize: 00058000
File version: 9.0.30729.1
Product version: 9.0.30729.1
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® Visual Studio® 2008
InternalName: pdm.dll
OriginalFilename: pdm.dll
ProductVersion: 9.0.30729.1
FileVersion: 9.0.30729.1 built by: SP
FileDescription: Process Debug Manager
LegalCopyright: © Microsoft Corporation. All rights reserved.
the version infos match up.
lmv displays the strings which are defined in the resource file,
I don’t know why there is common to two set of File/Product versions names the same except some spaces.
0:041> lmv m kernel32
start end module name
753e0000 754f0000 kernel32 (deferred)
Image path: C:\Windows\SysWOW64\kernel32.dll
Image name: kernel32.dll
Timestamp: Fri Aug 02 03:53:25 2013 (51FB1115)
CheckSum: 00111A9F
ImageSize: 00110000
File version: 6.1.7601.18229
Product version: 6.1.7601.18229
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: Microsoft® Windows® Operating System
InternalName: kernel32
OriginalFilename: kernel32
ProductVersion: 6.1.7601.18229
FileVersion: 6.1.7601.18229 (win7sp1_gdr.130801-1533)
In your case you have two different dll’s, look at the image file path.
Image path: C:\Program Files (x86)\Common Files\Microsoft Shared\VS7DEBUG\
and
Image path: C:\Program Files (x86)\Internet Explorer
They must have different strings in the resource section, winDbg can’t do anything but display it.
Since the time stamps are identical, one may have been tampered.