I need to debug a running program running on windows.
It some times crashes with "memory access violation".
With windbg (usage of IDE not possible) I attached to running process (it is a requirement the program shall not stop)
The command line is
windbg -g -p <pid>
The problem is that I now catch all first chance exceptions but I am only interested in any second chance exception (do not care which type of exception).
How can I setup windbg to catch any second chance exception?
WinDbg will catch second chance exceptions by default, so you just need to turn off the first chance exceptions. Doing this for a single type of exception is simple:
0:000> sxd av
0:000> *** Check the setting
0:000> .shell -ci "sx" find "av"
See set all exceptions to set all exception types to second-chance only.
Since it does not seem to be an option to perform those commands at debug time, you can also try to configure a Workspace that has exception handling disabled and then reuse the workspace. For understanding the concept of Workspaces, the MSDN article Uncovering how Workspaces work was really helpful. It is a set of experiments that you should do yourself once.
With that background knowledge, attach to any process
0:000> .foreach(exc {sx}) {.catch{sxd ${exc}}}
0:000> *** perhaps some other useful workspace relevant commands here
0:000> *** e.g. .symfix seems useful
0:000> *** File / Save Workspace As ...
0:000> *** Enter a name, e.g. myworkspace
0:000> q
Restart WinDbg with the -W myworkspace command line switch. Attach to any process. Check if your setting have been applied (e.g. sx, .sympath). If everything is fine, you can start debugging.
Related
I run
C:\Users\io\simics-projects\my-simics-project-1>simics.bat targets\qsp-x86\firststeps.simics
I then run "run" and let the system proceed all the way to the clear linux shell prompt. I then run "stop" to pause the simulation. But I get an error of "No current debug object". I would think a simple stack trace would simply follow the %rbp frame pointers backwards on the stack and display what's there. Why isn't it?
simics> run
Autologin as "simics" was done on "board.mb.sb.com[0] - serial console".
running> stop
simics> bt
No current debug object
(I also just noticed the same happens when I just try "step-out". Which again, I would think would simply step through instructions until after it hits a "ret"...)
I think the debugger is not enabled. To do so, the command is
enable-debugger
In gdb I can type watch &variable, then continue and gdb will break whenever something writes to that address.
I am using vscode to debug and want to do the same thing (This is different from the watch window, which will only show variable values after a breakpoint has been hit). Is it possible?
I can manually add a breakpoint by clicking the '+' and enter &variable but it never becomes active and says the module has yet to be loaded. I've tried manually entering -exec watch &variable in the debugger console window, but after continuing execution with the play button it hangs (vscode thinks the program is running again but it's not).
There are some github issues for this but they're closed without reason:
https://github.com/microsoft/vscode/issues/55931
https://github.com/microsoft/vscode/issues/47117
https://github.com/microsoft/vscode-debugadapter-node/issues/38
I had luck watching on an address. For example, if my target variable was at address 0xb79b90, I would execute -exec watch *0xb79b90 in the gdb terminal. Then I'd double check it was added as a hardware watchpoint with -exec info watch.
After continuing execution, the debugger would halt with an exception once the watchpoint is hit. vscode would display the line after the value was changed. I could then continue from there if necessary.
When I use below command to show the stack, I just get the hex address, even through the module is loaded (checked with command lm m xx):
0:014> k
Child-SP RetAddr Call Site
00000000`88f9b0e0 00000000`305e8a60 0x36f038d
00000000`88f9b0e8 00000000`305e8a60 0x305e8a60
Can anybody tell me why?
This is e.g. normal for .NET applications. The intermediate code is part of the assembly / DLL which you can see by lm.
However, the intermediate code never gets executed itself. It is processed by the JIT compiler at runtime. The JIT compiler allocates some memory (outside of the DLL) and emits assembler code there.
Since that part of memory is not related to the DLL immediately, WinDbg shows it as hex addresses only.
To work with .NET, load the SOS extension and use commands like
.loadby sos clr
!dumpstack
!clrstack
or SOSEX with commands like
.load <full path to>\sosex.dll
!mk
I'm trying to write a program to automate getting the call stack from crash dumps. It runs cdb.exe:
cdb.exe -i "{binaries path}" -y "{binaries path}" -srcpath "{source files path}" -z "{dmp file path}" -lines
I then feed some commands to CDB's standard input:
.symfix+ c:\\symcache
.ecxr
k
q
For many dumps this succeeds in printing the call stack, however some dumps do not work. The dumps that don't work output this error:
Unable to load image C:\Windows\System32\igdumd32.dll, Win32 error 0n2
*** ERROR: Module load completed but symbols could not be loaded for igdumd32.dll
However, Visual studio is able to figure out the call stack just fine. In the Visual Studio call stack, igdumd32.dll is at the bottom of the stack:
igdumd32.dll!0c70c570()
[Frames below may be incorrect and/or missing, no symbols loaded for igdumd32.dll]
I'm not sure if the symbol not loading is the problem or not, but I can't figure out why CDB can't get the call stack while Visual Studio can.
"Frames below may be incorrect and/or missing"
Sometimes this means what it says, annoyingly. I've no idea what VS does to get around it. So far the best I have for cdb is to, instead of k, run kd (the cdb command, not kd the kernel debugger program!) to get the raw stack data, then discard the junk lines between the useful ones.
You'll probably want to supply a number of lines (in hex) after kd to get enough output to contain the whole call stack.
e.g.
kd 200
Oh, this doesn't work for dumps generated from 64-bit processes because kd uses the wrong word size (afaict this is a bug). I'm currently looking for a way to work around this cleanly. For one thread you should be OK with something like:
dps #esp L200
This uses the esp register to access the stack, which is not portable but works for me. You may need a different register.
I have a running Perl process that’s stuck, I’d like to poke inside with a debugger to see what’s wrong. I can’t restart the process. Can I attach the debugger to the running process? I know I can do gdb -p, but gdb does not help me. I’ve tried Enbugger, but failed:
$ perl -e 'while (1) {}'&
[1] 86836
$ gdb -p 86836
…
Attaching to process 86836.
Reading symbols for shared libraries . done
Reading symbols for shared libraries ............................. done
Reading symbols for shared libraries + done
0x000000010c1694c6 in Perl_pp_stub ()
(gdb) call (void*)Perl_eval_pv("require Enbugger;Enbugger->stop;",0)
perl(86836) malloc: *** error for object 0x3: pointer being realloc'd was not allocated
*** set a breakpoint in malloc_error_break to debug
Program received signal SIGABRT, Aborted.
0x00007fff8269d82a in __kill ()
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on"
Evaluation of the expression containing the function (Perl_eval_pv) will be abandoned.
(gdb)
Am I doing it wrong? Are there other options?
P.S. If you think you could benefit from a debugger attached to a running process yourself, you can insert a debugger back door triggered by SIGUSR1:
use Enbugger::OnError 'USR1';
Then you can simply kill -USR1 pid and your process will jump into the debugger.
First, please use a DEBUGGING perl, if you want to inspect it with gdb.
Please define "stuck". Busy or non-busy waiting (high or low CPU), eating memory or not?
With while 1 it is busy waiting. I usually get busy waiting (endless cycles) on HV corruption in Perl_hfree_next_entry() since 5.15. Non-busy waiting is usually waiting on a blocking IO read.
I get the correct:
`0x00007fba15ab35c1 in Perl_runops_debug () at dump.c:2266`
`2266 } while ((PL_op = PL_op->op_ppaddr(aTHX)));`
and can inspect everything, much more than with a simple perl debugger. With a non-threaded perl you have to type less.
`(gdb) p Perl_op_dump(PL_op)`
and so on.
If you have to do with perl: Inside the pp_stub function it is not a good idea to enter the Enbugger runloop, you should be in the main runloop in dump.c. Set a breakpoint to the shown line.
"error for object 0x3" on eval sound like internal corruption in the context, so you should look at the cx and stack pointers. Probably because you started it in a bad context.
I've never used gdb, but maybe you could get something useful out of strace?
strace -f -s512 -p <PID>
http://metacpan.org/pod/App::Stacktrace
“perl-stacktrace prints Perl stack traces of Perl threads for a given Perl process. For each Perl frame, the full file name and line number are printed.”