lm command does not show correct module - windbg

I use WinDbg to analyze Adobe Acrobat Reader, AcroRd32.exe. I want to see what modules (the .dll modules that in the same directory with AcroRd32.exe) that AcroRd.exe loaded.
I use WinDbg monitoring to open a PDF file, then use lm command to show loaded modules. However, there is no module (.DLL) that has same directory as AcroRd32.exe.
Does that mean AcroRd32.exe didn't use these DLLs? To verify my assumption, I deleted all DLL files that are in the same directory as AcroRd32.exe. Then AcroRd32.exe cannot start normally. It means that these DLLs are necessary for AcroRd32.exe. But Why WinDbg's lm command didn't show these DLL modules?

Acrobat Reader starts another instance of itself. You need to debug the second instance to see the modules being loaded:
ntdll!LdrpDoDebuggerBreak+0x2b:
77e9db9b cc int 3
0:000> .childdbg 1
Processes created by the current process will be debugged
0:000> sxe cpr
0:000> g
[...]
Executable search path is:
ModLoad: 00c20000 00e45000 AcroRd32.exe
At this point, the second instance is going to be started.
1:010> g
ntdll!LdrpDoDebuggerBreak+0x2b:
77e9db9b cc int 3
1:010> g
If you break when Acrobat Reader has loaded, you'll see:
1:010> |0s
0:000> lmf
[...]
No Adobe Acrobat Reader DLLs
[...]
0:000> |1s
1:010> lmf
[...]
56910000 56961000 sqlite C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\sqlite.dll
56970000 569a4000 AXE8SharedExpat C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AXE8SharedExpat.dll
569b0000 56a9c000 ACE C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\ACE.dll
56aa0000 56d78000 CoolType C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\CoolType.dll
56d80000 56d9e000 BIB C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\BIB.dll
56da0000 572c2000 AGM C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AGM.dll
[...]
The first instance does not have DLLs loaded from Adobe Acrobat's directory but the second one has.

Related

Windbg symbol error

I'm attempting to debug an application using WinDbg. The server doesn't have internet access, so I can't use the Microsoft Symbol server. I went ahead and downloaded the symbols for Server 2012 R2 Retail. Moved them over to the server, and installed to C:\Symbols.
When I attempt to run the debugger, I get the following output.
CommandLine: C:\actionsync\ActionSync\ActionSync.exe
************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred srv*
DBGHELP: Symbol Search Path: .sympath srv*c:\symbols*
************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred .sympath srv*c:\Symbols*
DBGHELP: Symbol Search Path: .sympath srv*c:\symbols*
DBGHELP: Symbol Search Path: .sympath srv*c:\symbols*
Symbol search path is: .sympath srv*c:\Symbols*
Executable search path is: srv*
DBGHELP: SharedUserData - virtual symbol module
ModLoad: 00ec0000 00ecc000 ActionSync.exe
ModLoad: 77120000 7728f000 ntdll.dll
ModLoad: 6fc30000 6fc86000 C:\Windows\SysWOW64\MSCOREE.DLL
ModLoad: 74de0000 74f20000 C:\Windows\SysWOW64\KERNEL32.dll
ModLoad: 74f20000 74ff7000 C:\Windows\SysWOW64\KERNELBASE.dll
(1054.478): Break instruction exception - code 80000003 (first chance)
DBGHELP: Invalid path: '.sympath srv*c:\symbols*'
DBGHELP: C:\Windows\SYSTEM32\wntdll.pdb - file not found
DBGHELP: wntdll.pdb - file not found
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll -
DBGHELP: ntdll - export symbols
eax=00000000 ebx=00000000 ecx=7fdc0000 edx=00000000 esi=7ee16000 edi=00000000
eip=771d3c7d esp=0104f2f4 ebp=0104f320 iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
ntdll!LdrInitShimEngineDynamic+0x6dd:
771d3c7d cc int 3
I am completely new to using WinDbg. Additionally, I cannot install VS on this machine.
As far as I know, I have everything setup correctly, but I'm still not able to debug this application.
Any help would be appreciated.
EDIT 1:
I updated the symbol path based on Thomas Weller's Comment
Here is the output
0:000> .sympath
Symbol search path is: .sympath srv*c:\Symbols*
Expanded Symbol search path is: .sympath srv*c:\symbols*
************* Symbol Path validation summary **************
Response Time (ms) Location
Deferred .sympath srv*c:\Symbols*
Error: Change all symbol paths attempts to access '.sympath c:\symbols' failed: 0x7b - The filename, directory name, or volume label syntax is incorrect.
************* Symbol Path validation summary **************
Response Time (ms) Location
Error 16 .sympath c:\symbols
DBGHELP: Symbol Search Path: .sympath c:\symbols
DBGHELP: Symbol Search Path: .sympath c:\symbols
0:000> .reload
Reloading current modules
.....
DBGHELP: Invalid path: '.sympath c:\symbols'
DBGHELP: C:\Windows\SYSTEM32\wntdll.pdb - file not found
DBGHELP: wntdll.pdb - file not found
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll -
DBGHELP: ntdll - export symbols
************* Symbol Loading Error Summary **************
Module name Error
ntdll All symbol search paths were invalid
Please check your symbol search path.
The following location did not respond and were excluded during symbol loading:
.sympath c:\symbols
EDIT 2:
So, it appears that the sympath is case sensitive.
I updated the sympath C:\Symbols
This is the output.
************* Symbol Path validation summary **************
Response Time (ms) Location
OK c:\Symbols
DBGHELP: Symbol Search Path: c:\symbols
DBGHELP: Symbol Search Path: c:\symbols
0:000> .reload
Reloading current modules
.....
DBGHELP: c:\symbols\wntdll.pdb - file not found
DBGHELP: c:\symbols\dll\wntdll.pdb - file not found
DBGHELP: c:\symbols\symbols\dll\wntdll.pdb - file not found
DBGHELP: C:\Windows\SYSTEM32\wntdll.pdb - file not found
DBGHELP: wntdll.pdb - file not found
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll -
DBGHELP: ntdll - export symbols
************* Symbol Loading Error Summary **************
Module name Error
ntdll PDB not found : c:\symbols\symbols\dll\wntdll.pdb
Unable to locate the .pdb file in this location
For both solutions, you need a copy of WinDbg (not neccesarily an installation). You find symchk in the WinDbg folder.
Solution for a specific dump / specific debug session
On the machine where you're debugging, create crash dump file with .dump. Skip this step if you already have a crash dump file.
At a command prompt, create a manifest file, i.e. a file that contains information about the symbols to be downloaded
symchk /id <dumpfile>.dmp /om D:\symbols.manifest
/id is for input = dump
/om is for output = manifest
Transfer that manifest file onto a machine with Internet access.
On the Internet machine then run
symchk /im X:\symbols.manifest /s srv*X:\downloadedsymbols\*http://msdl.microsoft.com/download/symbols /od
at the command prompt.
/im is for input = manifest
/od is for output details (like verbose)
Transfer the symbols back to the machine without Internet access. Copy them into a new folder, e.g. c:\downloadedsymbols, not c:\symbols . Don't use an existing symbol path, because the n-tier-layout might not match.
Open the crash dump in WinDbg.
Fix the symbols
.sympath C:\downloadedsymbols
and maybe
.reload /f
Solution for retrieving all symbols of the machine without Internet
Note: this process may take really long, since it may download thousands of symbols
At a command prompt, run
symchk /r /if %windir% /om D:\windir.manifest
/r is for recursive
/if is for input = files
/om is for output = manifest
Transfer that manifest file onto a different machine with Internet access.
On the Internet machine, run
symchk /im X:\windir.manifest /s srv*X:\winsymbols\*http://msdl.microsoft.com/download/symbols /od
/im is for input = manifest
/od is for output details (like verbose)
Transfer the symbols back to the machine without Internet access. Copy them into a new folder, e.g. c:\winsymbols, not c:\symbols . Don't use an existing symbol path, because the n-tier-layout might not match.
Use the symbols with
.sympath C:\winsymbols
.reload

force windbg not load symbol

I'm doing crash analysis on some software,and I'm sure there is no pdb file I can get for the sth.exe,but when sth.exe crashs,every time windbg will search a lot of paths and symbol servers.Even when I cut off the vm's network connection,it still pinned for a while to search the sth.exe's pdb.And this leads to a failure in my auto analysis.Is there a way to tell windbg sth.exe has no pdb,please don't waste time to search it?
create a file named symsrv.ini
in the folder where windbg is installed
the directory in this sample is e:\ewdk\program files\windows kits\10\Debuggers\x86
create an exclusion section in the file
and add all the unknown pdb's list into it
symsrv wont go searching for them
:\>ls -l symsrv.ini
-rw-rw-rw- 1 HP 0 259 2016-08-18 17:43 symsrv.ini
:\>file symsrv.ini
symsrv.ini; ASCII text, with CRLF line terminators
:\>cat symsrv.ini
[exclusions]
livekdD.sys
vmm.pdb
livekdD.pdb
vmci.pdb
vsock.pdb
clwvd.pdb
spldr.pdb
vmkbd.pdb
vmnetsrv.pdb
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
:\>livekd
LiveKd v5.40 - Execute kd/windbg on a live system
Sysinternals - www.sysinternals.com
!sym noisy
noisy mode - symbol prompts off
kd> .reload /f
SYMSRV: vmci.pdb is in the file exclusion list
DBGHELP: d:\build\ob\bora-1141980\bora-vmsoft\build\release\crosstalk\windows\wi
n2k\i386\vmci.pdb - file not found
*** ERROR: Symbol file could not be found. Defaulted to export symbols for vmci.sys -
DBGHELP: vmci - export symbols
SYMSRV: vsock.pdb is in the file exclusion list
DBGHELP: d:\build\ob\bora-1253991\bora-vmsoft\build\release\vsock\windows\win2k\
i386\vsock.pdb - file not found
*** ERROR: Symbol file could not be found. Defaulted to export symbols for vsock.sys -
DBGHELP: vsock - export symbols
SYMSRV: vmm.pdb is in the file exclusion list
DBGHELP: m:\src\built\vs2005.sp2\vssp2\usa\ent_volume\i386\sym\sys\vmm.pdb - fil
e not found
*** ERROR: Module load completed but symbols could not be loaded for vmm.sys
DBGHELP: vmm - no symbols loaded
************* Symbol Loading Error Summary **************
Module name Error
vmci The system cannot find the file specified : srv*e:\symbols*
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 thepingme.txt file is not present
in the root directory), or the fileis present
in the symbol server exclusion list.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
answer to comment
well for a start there is a setting up exclusion list topic in windbg help
this topic alludes to this file (file is alluded in respect to using the symproxy and is supposed to be created at %windowsdir\system32\inetsrv\" and doesnt work for symsrv.dll (the registry key also doesnt seem to work )
https://msdn.microsoft.com/en-us/library/windows/hardware/ff556870(v=vs.85).aspx
for me i saw in procmon a failure with NameNotFound error in fastio path in windbg installation directory
so on a hunch i moved the file from above mentioned path to windbg installation directory
and things seemed to work correctly that was very long back
but subsequently i've seen post from jason shay (MSFT) in osr windbg lists stating this feature was pushed in windbg 6.4.4 beta
http://www.osronline.com/showthread.cfm?link=68916
so there isn't any common sense missing just that the corner cases are always difficult to find

Which version of sos and clr/mscorwks.dll to load?

I have a 32-bit application (targeting .NET 3.5) hosted on a 64-bit machine. I want to analyze the memory dump of this 32-bit application. I captured the memory dump using 32-bit adplus and cdb. I am loading the memory dump into 32-bit windbg. When I load .net 2.0 sos.dll and .net 2.0 mscorwks.dll into windbg and execute !clrstack, I get the following error: "Failed to find runtime DLL (mscorwks.dll), 0x80004005
Extension commands need mscorwks.dll in order to have something to do." What am I doing wrong?
Info as requested in the comments
ADPlus command line:
adplus -hang -quiet -p 2440 -o C:\temp
WinDbg commands:
0:000> .load <fullpathto>\sos.dll
0:000> lmvm mscorwks
start end module name
0:000> .exr -1
ExceptionAddress: 00000000
ExceptionCode: 80000007 (Wake debugger)
ExceptionFlags: 00000000
NumberParameters: 0
The dump indicates that no .NET 2 was loaded. Otherwise the output of lmvm mscorwks should show the details of the .NET runtime, like this:
0:003> lmvm mscorwks
start end module name
61bc0000 6216e000 mscorwks (deferred)
Image path: C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
...
File version: 2.0.50727.5485
...
You mentioned that you loaded SOS by full path. If the dump was taken on your machine, you would typically load it using
0:003> .loadby sos mscorwks
In your case, this should already give you the hint that .NET was not loaded:
Unable to find module 'mscorwks'
If you're not so sure about the .NET version, try
.loadby sos clr; *** .NET 4
.loadby sos coreclr; *** Silverlight / Universal Apps
Maybe you had a typo in your AdPlus command line and specified the wrong process ID. If that PID accidentally exists, you got a wrong dump. Use | to check the process name
0:003> |
. 0 id: 1e78 attach name: E:\...\NET2x32.exe
BTW: The -quiet parameter of ADPlus is obsolete, you can omit it.

Analyzing a .dmp crash file?

I tried traditional ways and answers to analyze my .DMP files. WinDbg doesn`t take it, it outputs:
Could not find the C:\program files\softwaredir\dumps\dumpname_0313.rsa.dmp
File, Win32 error 0n87
It's an Multi Theft Auto: San Andreas crash dump. .rsa.dmp
Why doesn`t WinDbg take it, does it have to do with a certain dump type?
If anyone would want to try opening, here is the dumpfile with the issue
I would like to know if you have the solution to solve the opening problem/or any other tool to open the dump.
But I really need the exception that caused the crash, so either I'll need advise on how to open it or if I can fix it.
For case 2 (can't solve it for me here) the crash memory locations are:
Version 1.3.5-release 6078.0.000
Time Tue Jan 21 03:13:18 2014
Module C:\Program Files (x86)\MTA San Andreas 1.3\mods\deathmatch\client.dll
Code 0 x C0000005
Offset 0 x 0009E796
EAX 00000000 EBX 30994AB0 ECX 21E82218 EDX 0028F71C ESI 3098E520
EDI 6FBBCCC9 EBP 0028F7BC ESP 0028F6F4 EIP 1B00E796 FLG 00210246
CS 0023 DS 002B SS 002B ES 002B FS 0053 GS 002B
This is what I did to generate and analyze a dump file:
Downloaded ProcDump (a free Sysinternals tool)
Created a folder c:\dumps
Added ProcDump to PATH
Entered procdump -ma -i c:\dumps into command prompt to start the JustInTime debugger
Opened the dump file in visual studio
Using this method we were able to resolve a difficult bug and determine what exception was causing my machine to crash.

WZUNZIP -v "unsupported" [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
Here's a cmd.exe batchfile and its run results:
#ECHO OFF
SETLOCAL
SET "w=&echo."
FOR /f "delims=" %%i IN (%~f0) DO ECHO(%%i
ver%w%
ECHO(%PATH:;=&ECHO(%%w%
DIR *.zip%w%
DIR /s \wzunzip.exe \wzcline*.dll%w%
wzunzip -v ancient%w%
wzunzip -v ancient.zip%w%
GOTO :EOF
Run results:
Microsoft Windows [Version 6.1.7601]
C:\executable
C:\batch
C:\Windows
C:\Windows\SysWOW64
C:\Window s\system32
C:\Program Files\WinZip
C:\Program Files (x86)\Embarcadero\RAD Studio\9.0\bin64
C:\Program Files (x86)\Embarcadero\RAD Studio\9.0\bin
C:\FPC\2.6.2\bin\i386-win32
C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common
C:\Program Files (x86)\AMD APP\bin\x86_64
C:\Program Files (x86)\CollabNet
C:\Users\Public\Documents\RAD Studio\9.0\Bpl
C:\Users\Public\Documents\RAD Studio\9.0\Bpl\Win64
C:\Windows\System32\Wbem
c:\Program Files (x86)\Common Files\Acronis\SnapAPI\
c:\Program Files (x86)\Acronis\TrueImageHome\
C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static
C:\Program Files\TortoiseSVN\bin
C:\Program Files (x86)\RemObjects Software\Oxygene\bin
C:\Program Files (x86)\QuickTime\QTSystem\
C:\windows\System32\WindowsPowerShell\v1.0\
C:\opencobol\bin
C:\Program Files (x86)\OwlyCI
Volume in drive C has no label.
Volume Serial Number is 830B-46FA
Directory of c:\ttbackup\operational
20/04/2009 13:07 1,752,181 ancient.zip
1 File(s) 1,752,181 bytes
0 Dir(s) 129,259,110,400 bytes free
Volume in drive C has no label.
Volume Serial Number is 830B-46FA
Directory of c:\batch
15/07/2013 04:00 13,224 WZUNZIP.EXE
1 File(s) 13,224 bytes
Directory of c:\batchbackup
15/07/2013 04:00 13,224 WZUNZIP.EXE
1 File(s) 13,224 bytes
Directory of c:\Program Files\WinZip
15/07/2013 04:00 13,224 WZUNZIP.EXE
Directory of c:\Program Files\WinZip
15/07/2013 04:00 2,571,688 WZCLINE32.DLL
15/07/2013 04:00 3,084,200 WZCLINE64.DLL
3 File(s) 5,669,112 bytes
Directory of c:\Program Files (x86)\WinZip
15/07/2013 04:00 2,571,688 WZCLINE32.DLL
15/07/2013 04:00 3,084,200 WZCLINE64.DLL
2 File(s) 5,655,888 bytes
Directory of c:\Windows
15/07/2013 04:00 13,224 WZUNZIP.EXE
Directory of c:\Windows
15/07/2013 04:00 2,571,688 wzcline.dll
15/07/2013 04:00 2,571,688 WZCLINE32.DLL
15/07/2013 04:00 3,084,200 WZCLINE64.DLL
4 File(s) 8,240,800 bytes
Total Files Listed:
11 File(s) 19,592,248 bytes
0 Dir(s) 129,259,110,400 bytes free
WinZip(R) Command Line Support Add-On Version 4.0 32-bit (Build 10562)
Copyright (c) 1991-2013 WinZip International LLC - All Rights Reserved
ERROR: option v is unsupported
Program is terminating!
WinZip(R) Command Line Support Add-On Version 4.0 32-bit (Build 10562)
Copyright (c) 1991-2013 WinZip International LLC - All Rights Reserved
ERROR: option v is unsupported
Program is terminating!
Translating, this is Win7 Home Premium, Here's my PATH, directory of .zip files, directory of all occurrences of WZUNZIP.EXE and WZCL*.DLL.
I did have an older version WZCLINE.DLL so I overwrote it with the 32-bit newer version. The run results do not vary whether this WZCLINE.DLL file is present or not.
The results of two attempted listings is shown.
I'm sure this used to work on earlier versions. It is documented as working with the version I have (Winzip 17.5) but no combination of the -v switch appears to be processed according to the documentation.
I've tried -v and -V and -vb, -vr, -vi, -vm, -vt - all with precisely the same complaint from WZUNZIP.
Sadly, WINZIP has started to ignore me, after first having requested the following:
Please provide some additional information.
- Please describe the exact steps you take to cause this problem to occur.
- What version of Windows and of WinZip are you running (you can check the
· WinZip version by clicking WinZip's Help, About WinZip menu item)?
- Are there any error messages that appear? If so, please include the full
· text of the error message and the title of the error dialog box.
- Does the problem happen consistently, or does it appear to happen randomly?
- Does it happen with all files, some files, or one file in particular? If
· the problem happens with one file in particular, can you tell me how to
· obtain a copy of the file?
- Are there any other applications running when the problem occurs?
Please provide the screenshot of the error message you are getting. Please use the following link which will gives you more information in this issue: http://kb.winzip.com/kb/entry/21/
Most of that information is in the report I sent them, so I really don't have much hope of getting competent support there. The only information I can provide in addition is
Yes, it happens consistently on every .zip I've tried it on. - And the Point,click and giggle version has no problem decoding those files.
No, nothing else happening on the system at all.
7zip appears to list the contents happily.
So - anyone with a cure for this error with WZUNZIP? How do I get a file listing for a .zip file
After navigating through the endless canned responses, I finally got to communicate with a technician.
The problem was isolated to my haing changed the PATH sequence, and WZUNZIP was locating prior DLLs on the revised path, hence re-installing the CLI add-on was ineffective.
Uninstalled WINZIP, located all the stray WZ* elements and deleted them, reininstalled and sanity was restored.
(posted for the sake of those who may encounter a similar problem - as evidently some have, given there have been responses)