In the XP days I use DrWatson to do post mortem asm dumps of apps that crashed. I have not found a viable replacement in win7 64 yet but to confess I have not looked all that hard. What was useful to me was the asm crash dump that showed which instruction had generated the exception. I tried ProcDump but it does not output the type of dump that I need.
Any suggestions on what I can use as a post mortem degugger ?
I had good luck with their 32 bit debugger.
Maybe this will help.
Andy
http://www.ollydbg.de/
Perhaps that could help you (http://dobrzanski.net/2010/04/17/windows-error-reporting-first-steps-in-postmortem-debugging-how-to-collect-mini-dump/)
Your response to a post mortem debugger got me to thinking.
I have run Windows for 15 yrs. plus.
For about the last 2 yrs., my primary O.S. has been Linux Puppy Slacko.
(I still use Win XP on occasion.)
First 6 months was very frustrating learning it.
But slowly I learned what it had to offer.
1. No need to defrag my hard drives.
2. When a program failed, it just exited without needing a reboot.
3. Never needed any patches.
4. Internet speeds were 3-4X faster than Windows.
5. Console use was extremely useful and VERY advanced.
Example
# Turn OFF the touchpad
synclient TouchpadOff=1
Hutch,
Olly can easily be configured as JIT debugger. I use it a dozen times a day, for example when testing that VB stuff (http://masm32.com/board/index.php?topic=4976.0). There, I call a Masm or MB dll function from Visual Basic, and guess what? it happens to contain an int 3. VB stops working, after some seconds Windows shows a box saying VB is damn broken, click debug and voilà, Olly lets you walk inside VB's digestive tract. It's fun, but make sure you saved your VB code before trying that because unsaved changes are lost. Same applies for VBA - you can walk through MS Word but make sure you saved your changes before.
Choosing the Best Tool (https://msdn.microsoft.com/en-us/library/windows/hardware/ff539117%28v=vs.85%29.aspx)
Enabling Postmortem Debugging (https://msdn.microsoft.com/en-us/library/windows/hardware/ff542967%28v=vs.85%29.aspx)
Collecting User-Mode Dumps (https://msdn.microsoft.com/en-us/library/windows/desktop/bb787181%28v=vs.85%29.aspx) with WER ( with Community Additions)
one interesting comment by Butter550 :
Quote
DrWatson worked on Win2008R2
I took DrWatson32 from XP and worked on Win2008R2. Note Watson32 is not shipped with R2. Once you have the EXE, run this command to install.
drwtsn32 -i
WER took hours of experimentation and did not work in the end. Then Watson worked on first shot. MS is so over-engineering. They should go back to basics
I have got WinDbg installed using the -I option and it works when a running application has an exception but I have not yet found out how to get a disassembly the includes the instruction where the exception occurred, something the DrWatson used to do easily. When you try the disassembly option on its UI interface it says no symbols available so I downloaded the massive symbol installation that installed 1.3 gig of symbols and the PHUKING thing still does not display a disassembly.
Is anyone familiar with using "WinDBG" so that when an exception occurs, instead of a pile of useless information popping up, you actually get a bare disassembly of a range of instructions leading up to the instruction where the exception occurred ?
For debugging i use these tools
Ollydbg
idapro
Rosasm
The 3 of them shows the disassembly code. Btw...ida uses windbg as well.
Are you trying to disasm/debug some app in specific or is a general issue ?
guga,
I have no problems with disassemblers from the DUMPPE in MASM32 to IDA Pro but what I am after is the disassembly of an exception when it occurs as you could do with the old DrWatson.
Quote from: hutch-- on January 06, 2016, 12:29:59 AMwhat I am after is the disassembly of an exception when it occurs as you could do with the old DrWatson.
Can you elaborate...?
For example, I call a dll routine from VB, which of course crashes at INT 3:
InstrMb proc src$, match$ ; $export
mov eax, src$
mov ecx, match$
mov eax, [eax] ; [eax+4] is Ansi, [eax+4] is Unicode copy
mov ecx, [ecx]
INT 3 ; greetings to Olly
xchg eax, Instr_(FAST, eax, ecx, 0)
ret
InstrMb endpA second later, Windows greets me as below, and when clicking on "debug", Olly gives you access to each and every detail of this "event". Hit F8 a few times, and the retn8 lets you jump into VB. What else do you need?
This is Olly 2.01 (http://www.ollydbg.de/version2.html) with Options/Options/Debugging/Just-in-time set to <This copy of OllyDbg>.
You mean when a app crashes and the VisualStudio debug open it, right ? try setting idapro as the default debugger, instead. On this way, whenever a app crashes, what will be loaded for you to debug that piece of code is ida instead Visualstudio (or olly also can be used like that i presume. Try the settings JJ suggested.)
if it is not...sorry, i don´t remember how dr. watson works.
DrWatson produced a crash dump that had a disassembly up to the point where the exception occurred. It was very useful when developing algorithms of pure mnemonic code as it was very easy to identify the location in the algo that you were writing where the exception occurred. What I need is the crash dump disassembled so I can quickly find the crash location. I can do it the old way but this is a lot easier and faster to use.
Quote from: hutch-- on January 05, 2016, 11:51:14 PM
...
Is anyone familiar with using "WinDBG" so that when an exception occurs, instead of a pile of useless information popping up, you actually get a bare disassembly of a range of instructions leading up to the instruction where the exception occurred ?
Hutch , I used WinDbg much . Can you , please , post that " useless information " here .
When you have your app launched in WinDbg - you have full control over it .
You may create dump .dump (Create Dump File) (http://masm32.com/board/index.php?action=post;topic=4980.0;last_msg=53601#postmodify)
or view the call stack - Viewing the Call Stack in WinDbg (https://msdn.microsoft.com/en-us/library/windows/hardware/ff539042%28v=vs.85%29.aspx)
I think that every post mortem debugger stops at the place where exception occurred
I get this so far.
Microsoft (R) Windows Debugger Version 10.0.10586.567 X86
Copyright (c) Microsoft Corporation. All rights reserved.
*** wait with pending attach
Symbol search path is: srv*
Executable search path is:
ModLoad: 00400000 00404000 K:\asms\asm4\pdtest\pdtest.exe
ModLoad: 77650000 777d0000 C:\Windows\SysWOW64\ntdll.dll
ModLoad: 76c80000 76d90000 C:\Windows\syswow64\kernel32.dll
ModLoad: 75460000 754a7000 C:\Windows\syswow64\KERNELBASE.dll
ModLoad: 75060000 7510c000 C:\Windows\syswow64\msvcrt.dll
(a7c.10e8): Access violation - code c0000005 (!!! second chance !!!)
*** WARNING: Unable to verify checksum for K:\asms\asm4\pdtest\pdtest.exe
*** ERROR: Module load completed but symbols could not be loaded for K:\asms\asm4\pdtest\pdtest.exe
eax=00000002 ebx=7efde000 ecx=283a0000 edx=0008e3c8 esi=00000000 edi=00000000
eip=00000000 esp=0018ff7c ebp=0018ff84 iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202
00000000 ?? ???
this is roughly what a DrWatson crash dump looked like.
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
call main
inkey
exit
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
main proc
LOCAL padd :DWORD
; -------------------------------
; invalid library handle
; with non existent function name
; -------------------------------
mov padd, rv(GetProcAddress,0,"fakename")
;;;; inkey "crash after the next keypress"
; --------------------------------
; attempt to call invalid function
; --------------------------------
call padd ; <--------<<< generate exception here
ret
main endp
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
DrWatson crash dump used to look something like this.
00401000 start:
00401000 E820000000 call fn_00401025
00401005 6800304000 push offset off_00403000 ; 'Press any key to continue ...',000h
0040100A E831000000 call fn_00401040
0040100F E86C000000 call fn_00401080
00401014 681E304000 push offset off_0040301E ; 00Dh,00Ah,000h
00401019 E822000000 call fn_00401040
0040101E 6A00 push 0
00401020 E8FD000000 call jmp_ExitProcess
00401025 fn_00401025: ; Xref 00401000
00401025 55 push ebp
00401026 8BEC mov ebp,esp
00401028 83C4FC add esp,0FFFFFFFCh
0040102B 6824304000 push offset off_00403024 ; 'fakename',000h
00401030 6A00 push 0
00401032 E8F1000000 call jmp_GetProcAddress
00401037 8945FC mov [ebp-4],eax
0040103A FF55FC call dword ptr [ebp-4] ; <--------<<< crash occurs here
Quotetry setting idapro as the default debugger
We have 1129 USD / 1019 EUR. for the Pro version?? :lol:
Olly is enought to debugging
But Jochen has right to set Olly to default debugger is very nice :t
Quote from: ragdog on January 06, 2016, 08:03:20 PM
Quotetry setting idapro as the default debugger
We have 1129 USD / 1019 EUR. for the Pro version?? :lol:
Olly is enought to debugging
But Jochen has right to set Olly to default debugger is very nice :t
IDA is sure proud of their program. :-)
$1129 is extremely expensive.
Found advanced reference on google books :
Memory Dump Analysis Anthology, Vol.2 (https://books.google.ru/books?id=G_raAgAAQBAJ&lpg=PA29&ots=LgSOk0WEE7&dq=WINDBG%20script%20chapter&hl=ru&pg=PA38#v=onepage&q&f=false)
Part 2:Professional Crash Dump Analysis , page 38
All at Once: Postmortem Logs and Dump Files
Note that the author downloads debugging symbols from the symbols server
A VEH in the program being debugged can catch the exception, but I see no non-clumsy way to generate a disassembly.
WinDbg itself can handle exceptions so it's not a problem.
Yesterday I tried to generate in-process minidump as shown in C++ on this page (https://msdn.microsoft.com/ru-ru/library/windows/desktop/ee416349%28v=vs.85%29.aspx) . It doesn't work for single threaded app at least ( next time I'll see if creating a worker thread helps to achieve the goal ) . Then I started experimenting with custom post-mortem "debugger" - simple test program that receives crashed process ID and event handle . Now I have to get a process name from PID ( through enumerating all processes , I think) and learn how to deal with event handle ( no idea at the moment).
Bookmarking an excellent article Prolific Usage of MiniDumpWriteDump (Automating Crash Dump Analysis Part 0) (http://blogs.msdn.com/b/joshpoley/archive/2008/05/19/prolific-usage-of-minidumpwritedump-automating-crash-dump-analysis-part-0.aspx)
Now that I have recently spent some time on algorithms, I am getting something like a useful result from WinDBG, the first try is useless but on the second try it shows one line of assembler, the instruction that failed which is exactly what I need.