There is an IMViewer.exe process in memory and open them file IMMAIL.IMM
vol.py -f d:\dump\dump\CRM-20180416-165859.dmp --profile=Win2012R2x64_18340 --kdbg=0xf80173c3f8e0 dlllist -p 8256 > dlllist.txt
IMViewer.EXE pid: 8256
Command line : "C:\Program Files (x86)\Inbit\Inbit Messenger Server\IMViewer.exe" "C:\Program Files (x86)\Inbit\Inbit Messenger Server\USER_ACCT\00001\IMMAIL.IMM"
Note: use ldrmodules for listing DLLs in Wow64 processes
Base Size LoadCount Path
------------------ ------------------ ------------------ ----
0x0000000000400000 0x208000 0x0 C:\Program Files (x86)\Inbit\Inbit Messenger Server\IMViewer.exe
0x00007ffca1a20000 0x1ad000 0x0 C:\Windows\SYSTEM32\ntdll.dll
0x0000000077850000 0x4b000 0x0 C:\Windows\SYSTEM32\wow64.dll
0x00000000777e0000 0x68000 0x0 C:\Windows\system32\wow64win.dll
0x00000000777d0000 0x9000 0x0 C:\Windows\system32\wow64cpu.dll
Execution
vol.py -f d:\dump\dump\CRM-20180416-165859.dmp --profile=Win2012R2x64_18340 --kdbg=0xf80173c3f8e0 dumpfiles -r IMM$ -i --name -D FileHandles/
does not find the file .IMM in memory.
The file IMMAIL.IMM is open and I can use it, but it was deleted from the disk and it could not be restored. Program IMViewer.EXE - Viewer and I cannot save the file IMMAIL.IMM. I wanted to find the file IMMAIL.IMM in memory and save it using dumpfiles, but the file can't be found. What can I do to find a file IMMAIL.IMM in memory?
Kinda new to this but this may help `Vol.py -f {file} --profile{profile} filescan | grep .ILL [ or the absoulute name fo the program instead ] and extract the file
Related
I'm trying to debug an issue with what may be handle leak. I have a dump created on a remote windows machine and I would like to see the handles information. I'm using WinDbg. I have seen some articles from the MSDN and from other sources, like https://www.codeproject.com/Articles/6988/Debug-Tutorial-Part-5-Handle-Leaks, but I can't get it to work, so I need some help.
I tried the next
Using !handles or !devhandles - these have failed. I either get no export handles found or a failure to load kdexts. Apparently kernel debugging is not enabled.
I found winxp/kdexts.dll in my path (given from .chain command) but it wouldn't load - .load kdexts yields `DebugExtensionInitializeFailed1 with error code 0x80004005.
Using !handle - with !handle -? I get help for the command but when I try something else, I get "Unable to read handle information". For example,
!handle - I expected a full list of handles
!handle 0 0
!handle 0 0 file
My setup
The remote process is Windows server 2012 (64bit), just as my own machine
I'm using the latest WinDbg from the windows sdk 10
I have a full dump, created by right-clicking task manager
I need some help if possible
Do I need to do kernel-debugging in order to view the list of handles from the dump?
Is it possible at all to do kernel-debugging on a full dump created from task-manager? Or is it required that the dump be taken differently?
How can I know if a given dump file includes the handle information?
How can I use the !handle command properly?
Is there any other alternative, such as using visual studio, another utility, etc.?
I'd appreciate any help
!tamir
your dump was probably a dump taken without handle information
you may use dumpchk.exe that comes with windbg installation to see if Handle Stream exists in the dump
if you have control over dump creation check how to use .dump /ma with windbg
or you may also explore sysinternals procdump.exe
and also make sure you are using the correct bitted debugger for the dump in question
a sample path
D:\>dir /s /b "c:\Program Files (x86)\Windows Kits\10\Debuggers\cdb.exe"
c:\Program Files (x86)\Windows Kits\10\Debuggers\arm\cdb.exe
c:\Program Files (x86)\Windows Kits\10\Debuggers\arm64\cdb.exe
c:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe
c:\Program Files (x86)\Windows Kits\10\Debuggers\x86\cdb.exe
here is a sample dump creation with and without handle stream in the dump
:000> .dump /ma d:\madump.dmp
Creating d:\madump.dmp - mini user dump
Dump successfully written
0:000> .dump d:\nomadump.dmp
Creating d:\nomadump.dmp - mini user dump
Dump successfully written
0:000> q
analysing both the dumps with dumpchk and checking for streams present
dumpchk nomadump.dmp > nomachk.txt
dumpchk madump.dmp > machk.txt
D:\>type machk.txt |grep -i number.*stream
NumberOfStreams 17
D:\>type nomachk.txt |grep -i number.*stream
NumberOfStreams 13
diff
D:\>diff -y machk.txt nomachk.txt
Microsoft (R) Windows Debugger Version 10.0.17763.132 AMD64 Microsoft (R) Windows Debugger Version 10.0.17763.132 AMD64
Loading Dump File [D:\madump.dmp] | Loading Dump File [D:\nomadump.dmp]
User Mini Dump File with Full Memory: Only application d | User Mini Dump File: Only registers, stack and portions of me
----- User Mini Dump Analysis ----- User Mini Dump Analysis
MINIDUMP_HEADER: MINIDUMP_HEADER:
Version A793 (A063) Version A793 (A063)
NumberOfStreams 17 | NumberOfStreams 13
Flags 441826 | Flags 40000
0002 MiniDumpWithFullMemory <
0004 MiniDumpWithHandleData <
0020 MiniDumpWithUnloadedModules <
0800 MiniDumpWithFullMemoryInfo <
1000 MiniDumpWithThreadInfo <
40000 MiniDumpWithTokenInformation 40000 MiniDumpWithTokenInformation
400000 MiniDumpWithIptTrace <
if you feel enterprising take a look here for some hints to deciphering a dump without windbg /dbgeng
forgot to post the result of doing !handle on both dumps
D:\>cdb -c "!handle;q" -z nomadump.dmp |awk /Reading/,/quit/"
0:000> cdb: Reading initial command '!handle;q'
ERROR: !handle: extension exception 0x80004002.
"Unable to read handle information"
quit:
D:\>cdb -c "!handle;q" -z madump.dmp |awk /Reading/,/quit/"
0:000> cdb: Reading initial command '!handle;q'
Handle 0000000000000004
Type File
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxSNIPxxxxxxxxx
Handle 0000000000000128
Type Mutant
Handle 000000000000012c
Type
Handle 0000000000000180
Type File
70 Handles
Type Count
None 27
Event 13
File 8
Directory 2
Mutant 1
Semaphore 2
Key 6
IoCompletion 2
TpWorkerFactory 2
ALPC Port 1
WaitCompletionPacket 6
quit:
Check the tool which was used for creating the crash dump. Perhaps it provides an option to include handle data.
Task Manager includes handle data by default
Visual Studio includes handle data by default
In WinDbg, .dump can be used with the /mh switch to include handle data. /ma is a shortcut for /mfFhut, so it also includes handle data.
ProcDump automatically includes handle data.
Windows Error Reporting LocalDumps can be configured with a Registry value called CustomDumpFlags.
If you create the dump programmatically yourself with MiniDumpWriteDump(), use MINIDUMP_TYPE::MiniDumpWithHandleData.
After running a set of tests with drmemory overnight I am trying to resolve the error stacks by providing pdb symbols. The pdb's come from a large samba-mapped repository and using _NT_SYMBOL_PATH at runtime slowed things down too much.
Does anyone know of a tool that post-processes results.txt and pulls new symbols (via NT_SYMBOL_PATH or otherwise) as required to produce more detailed stacks ? If not, any hints for adapting asan_symbolize.py to do this ?
https://llvm.org/svn/llvm-project/compiler-rt/trunk/lib/asan/scripts/asan_symbolize.py
What I came up with so far using dbghelp.dll is below. Works but could be better.
https://github.com/patraulea/postpdb
ok this Query does not pertain to use of windbg or doesn't have anything to do with _NT_SYMBOL_PATH
Dr.Memory is a memory diagnostic tool akin to valgrind and is based on Dynamorio instumentation framework usable on raw unmodified binaries
on windows you can invoke it like drmemory.exe calc.exe from a command prompt (cmd.exe)
as soon as the binary finishes execution a log file named results.txt is written to a default location
if you had setup _NT_SYMBOL_PATH drmemory honors it and resolves symbol information from prepulled symbol file (viz *.pdb) it does not seem to download files from ms symbol server it simply seems to ignore the SRV* cache and seems to use only the downstream symbol folder
so if the pdb file is missing or isnt downloaded yet
the results.txt will contain stack trace like
# 6 USER32.dll!gapfnScSendMessage +0x1ce (0x75fdc4e7 <USER32.dll+0x1c4e7>)
# 7 USER32.dll!gapfnScSendMessage +0x2ce (0x75fdc5e7 <USER32.dll+0x1c5e7>)
while if the symbol file was available it would show
# 6 USER32.dll!InternalCallWinProc
# 7 USER32.dll!UserCallWinProcCheckWow
so basically you need the symbol file for appplication in question
so as i commented you need to fetch the symbols for the exe in question
you can use symchk on a running process too and create a manifest file
and you can use symchk on a machine that is connected to internet
to download symbols and copy it to a local folder on a non_internet machine
and point _NT_SYMBOL_PATH to this folder
>tlist | grep calc.exe
1772 calc.exe Calculator
>symchk /om calcsyms.txt /ip 1772
SYMCHK: GdiPlus.dll FAILED - MicrosoftWindowsGdiPlus-
1.1.7601.17514-gdiplus.pdb mismatched or not found
SYMCHK: FAILED files = 1
SYMCHK: PASSED + IGNORED files = 27
>head -n 4 calcsyms.txt
calc.pdb,971D2945E998438C847643A9DB39C88E2,1
calc.exe,4ce7979dc0000,1
ntdll.pdb,120028FA453F4CD5A6A404EC37396A582,1
ntdll.dll,4ce7b96e13c000,1
>tail -n 4 calcsyms.txt
CLBCatQ.pdb,00A720C79BAC402295B6EBDC147257182,1
clbcatq.dll,4a5bd9b183000,1
oleacc.pdb,67620D076A2E43C5A18ECD5AF77AADBE2,1
oleacc.dll,4a5bdac83c000,1
so assuming you have fetched the symbols it would be easier to rerun the tests with a locally cached copies of the symbol files
if you have fetched the symbols but you cannot rerun the tests and have to work solely with the output from results.txt you have some text processing work (sed . grep , awk . or custom parser)
the drmemory suite comes with a symbolquery.exe in the bin folder and it can be used to resolve the symbols from results.txt
in the example above you can notice the offset relative to modulebase like
0x1c4e7 in the line # 6 USER32.dll!gapfnScSendMessage +0x1ce (0x75fdc4e7 {USER32.dll+0x1c4e7})
so for each line in results.txt you have to parse out the offset and invoke symbolquery on the module like below
:\>symquery.exe -f -e c:\Windows\System32\user32.dll -a +0x1c4e7
InternalCallWinProc+0x23
??:0
:\>symquery.exe -f -e c:\Windows\System32\user32.dll -a +0x1c5e7
UserCallWinProcCheckWow+0xb3
a simple test processing example from a result.txt and a trimmed output
:\>grep "^#" results.txt | sed s/".*<"//g
# 0 system call NtUserBuildPropList parameter #2
USER32.dll+0x649d9>)
snip
COMCTL32.dll+0x2f443>)
notice the comctl32.dll (there is a default comctl.dll in system32.dll and several others in winsxs you have to consult the other files like global.log to view the dll load path
symquery.exe -f -e c:\Windows\winsxs\x86_microsoft.windows.common-
controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll -a +0x2f443
CallOriginalWndProc+0x1a
??:0
symquery.exe -f -e c:\Windows\system32\comctl32.dll -a +0x2f443
DrawInsert+0x120 <----- wrong symbol due to wrong module (late binding
/forwarded xxx yyy reasons)
I have a single DLL or EXE file and I'd like to acquire the symbols (PDB file) for it, i.e. download from the symbol server.
Note: The DLL is not a module which is part of a crash dump, so opening the dump and doing .symfix and .reload is not possible.
I have tried
symchk /os /if "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll"
/su "SRV*e:\debug\symbols*http://msdl.microsoft.com/download/symbols"
but it just says
SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1
and there are no symbols in my symbol folder.
You have used /if which sounds plausible, but actually it needs to be /id for a dump file:
symchk /os /id "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll"
/su "SRV*e:\debug\symbols*http://msdl.microsoft.com/download/symbols"
SYMCHK: FAILED files = 0
SYMCHK: PASSED + IGNORED files = 1
The output is the same, but the symbol folder contains the PDBs now.
It is similar in WinDbg:
choose File | Open Crash Dump ... or press Ctrl+D
for the file name filter, instead of Crash Dump Files select All files
choose the DLL or EXE of your interest. WinDbg will e.g. say
Loading Dump File [C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll]
although it is not really a dump file
issue the typical commands .symfix and .reload. If symbols are present on the symbol server, they will be downloaded.
Looking at what you're "debugging", you'll see that it's the DLL:
0:000> |
. 0 id: f0f0f0f0 examine name: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
0:000> ||
. 0 Image file: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
0:000> lm
start end module name
00000001`80000000 00000001`80988000 clr (pdb symbols) e:\debug\symbols\clr.pdb\5706A2AA257A45FDAC5776EDDC7BBA542\clr.pdb
And also some other commands work:
0:000> x clr!*
00000001`80123e28 clr!SafeHandle::Init (<no parameter info>)
00000001`808f5e80 clr!HillClimbingLogSize = <no type information>
00000001`80064af0 clr!IsTimerSpecialThread (<no parameter info>)
...
0:000> u clr!SafeHandle::Init
clr!SafeHandle::Init:
00000001`80123e28 4883ec28 sub rsp,28h
00000001`80123e2c 488b059d4b7c00 mov rax,qword ptr [clr!g_Mscorlib+0x10 (00000001`808e89d0)]
00000001`80123e33 488b80e0070000 mov rax,qword ptr [rax+7E0h]
00000001`80123e3a 4885c0 test rax,rax
...
I'm attempting to uncompress several .gz files using 7-Zip from the command line. My files are in directories like so:
Desktop/copyto/1/
file1.gz
file2.gz
Desktop/copyto/2/
file1.gz
file2.gz
file3.gz
I would like to recursively uncompress all the .gz files into each's orginal location and as well as deleting the remaining .gz files when they are done uncompressing.
I have tried the following command with no luck:
7z.exe x C:\Users\MYUSERNAME\Desktop\copyto\*\*.gz -r
I assumed that this would extract recursively. I get the error:
Processing archive: C:\Users\MYUSERNAME\Desktop\copyto\1\file1.gz
Can not open output file file1
Sub items Errors: 1
Any idea what's going on?
Given your command line, my guess is that your current working directory isn't any subdirectory of your home directory (C:\Users\MYUSERNAME) or the public user directory (C:\Users\Public), which means you probably don't have access rights. For example, if I run the following from C:\Program Files\7-Zip, I get the same error with a 7-Zip file:
C:\Program Files\7-Zip>7z x C:\Users\MYUSERNAME\Desktop\migrated\annex_k.7z -r
7-Zip [64] 9.38 beta Copyright (c) 1999-2014 Igor Pavlov 2015-01-03
Processing archive: C:\Users\MYUSERNAME\Desktop\migrated\annex_k.7z
ERROR: Can not open output file : .\annex_k\include\annex_k\errno.h
Skipping annex_k\include\annex_k\errno.h
ERROR: Can not open output file : .\annex_k\include\annex_k\handler.h
Skipping annex_k\include\annex_k\handler.h
...
Extracting annex_k\include\annex_k
Extracting annex_k\include
Extracting annex_k
Sub items Errors: 10
Archives with Errors: 1
Sub items Errors: 10
Kernel Time = 0.031 = 39%
User Time = 0.031 = 39%
Process Time = 0.062 = 78% Virtual Memory = 3 MB
Global Time = 0.080 = 100% Physical Memory = 4 MB
Notice that not even an annex_k directory was created:
C:\Program Files\7-Zip>dir /b
7-zip.chm
7-zip.dll
7-zip32.dll
7z.dll
7z.exe
7z.sfx
7zCon.sfx
7zFM.exe
7zG.exe
descript.ion
History.txt
Lang
License.txt
readme.txt
The solution is to extract to a directory in which you have access rights. You can specify an output directory using something like -oC:\Users\MYUSERNAME\Desktop\copyto\1. If you absolutely need to do this in a directory in which you don't have write access ordinarily, you'd need to run the command prompt as an administrator and extract the file as usual.
How can I read name of source file and send it as archive name in 7zip using cmd archive option.
Now I use:
7z a -t7z V:\archive.7z V:\Backup\*.bak
I want to check bak namefile in V:\Backup (there is always only 1 file) and send it as archive.7z - for example if in V:\Backup is 1 file named "20131028_1100.bak" I want to name archive "20131028_1100.7z"
I found this to work:
Get-ChildItem *txt | ForEach-Object {.\7zr.exe a -t7z $($_.Name).replace('.txt','.7z') $_.FullName}
Example:
PS C:\tools> ls
Directory: C:\tools
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 2022/08/01 11:00 578048 7zr.exe
-a---- 2022/08/01 11:02 7 hello.txt
PS C:\tools> Get-ChildItem *txt | ForEach-Object {.\7zr.exe a -t7z $($_.Name).replace('.txt','.7z') $_.FullName}
7-Zip (r) 22.01 (x86) : Igor Pavlov : Public domain : 2022-07-15
Scanning the drive:
1 file, 7 bytes (1 KiB)
Creating archive: hello.7z
Add new data to archive: 1 file, 7 bytes (1 KiB)
Files read from disk: 1
Archive size: 133 bytes (1 KiB)
Everything is Ok
PS C:\tools> ls
Directory: C:\tools
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 2022/08/01 11:00 578048 7zr.exe
-a---- 2022/08/01 11:20 133 hello.7z
-a---- 2022/08/01 11:02 7 hello.txt
PS C:\tools> ls
you need a .bat script that execute a FOR command like this:
for %%X in (*) do "7zip\App\7-Zip\7z.exe" a "%%~nX.zip" "%%X"
%%X will catch the file name of every file contained in the folder where you will execute the script (in this case V:\Backup\ and only 1 file would be processed), so %%~nX.zip will take that file name
7zip keep source file name to archive
As "capa" said, it is necessary to use shell commands, because 7zip does not provide a command for this case.
The following edited command is available in order to operate with *.bak files and it is working for "7z" compression extension. It is more efficient than "zip" format in compression rate.
7z Format
FOR %%I IN (.bak) DO "c:\Program Files\7-Zip\7z.exe" a -t7z %%~nI.7z %%~nI.
zip Format
FOR %%I IN (.bak) DO "c:\Program Files\7-Zip\7z.exe" a -tZip %%~nI.zip %%~nI.
In the above commands the " * " symbol before .bak is not appeared. Please add it!
Also add the " * " to the end of each command.
*Create a "bat" file for example "compressbak.bat" on *.bak files directory, copy and paste the preferred command(7z or zip), "Save" the content on "compressbak.bat"! This will create named archives of *.bak files in the same folder that *.bak files saved. Also if you running on Windows x64 and you have a x86 version of 7-Zip you have to follow the right path in order to call the 7z.exe file. "c:\Program Files (x86)\7-Zip\7z.exe"
Folder and bat file content!
I hope that it helps you!!!