I am debugging stm32F4 using Visual Studio code . But sometimes the Cortex-debug extension fails to launch debug session . The control gets stuck in the Reset Handler (code below)
.section .text.Reset_Handler
.weak Reset_Handler
.type Reset_Handler, %function
Reset_Handler:
ldr sp, =_estack /* set stack pointer */
And the Visual Studio Code the below error
Error: A serious error occurred with gdb, unable to continue or interrupt We may not be able to recover from this point. You can try continuing or ending session. Must address root cause though
Related
I am taking Assembly this semester. I am trying to use DumpRegs to display my registers, however, I get an error when running without debugging. The program builds (successfully it says), hangs and then my cmd prompt displays: "The system cannot execute the specified program."
If I debug, Visual Studio says "Insufficient resources exist to complete the requested service", then my antivirus attempts to quarantine "Generic RX BM-OC!257C1442E357 " at the time of running. I just ran a scan and I have no viruses, only downloads have been the Irvine library off of his site earlier today. Any ideas? I'm on a 64 bit machine, but their site said it was tested for 32 bit and 64 bit machines.
Here is the incredibly simple code:
include Irvine32.inc
.code
main PROC
mov eax,5
add eax,6
call DumpRegs
exit
main ENDP
END main
I have an Xcode project with a single Scheme that does nothing more than launch an OS X app in Debug configuration. The app is not built by the project, and the project does not have any targets. The Xcode project just launches the app from a Scheme. The app was originally built in Debug mode, via an external command-line build script, and contains a number of dynamic libraries (dylib's) in addition to the main executable.
After launching the app in this way through Xcode, if the app is stopped by an assertion statement (or is simply manually paused), the resulting call stack reveals nothing more than address pointers. There are no symbols displayed:
However, if I force the assertion to continue, the app crashes and produces a fully-symbolicated crash report, despite an absence of dSYM files anywhere in the app distribution.
[Edit]: In addition, many of the symbols appear at the top of the Debugger Source Editor in many (but possibly not all) of the calls in the stack:
rendersystemtest`CMaterialSystem2AppSystemDict::SetupMaterialSystem:
rendersystemtest[0x1cfb99] <+1753>: movb $0x1, -0x51(%rbp)
rendersystemtest[0x1cfb9d] <+1757>: movq 0x85c4e4(%rip), %rax ; (void *)0x0000000000000000
rendersystemtest[0x1cfba4] <+1764>: movb -0x51(%rbp), %cl
rendersystemtest[0x1cfba7] <+1767>: movq (%rax), %rax
rendersystemtest[0x1cfbaa] <+1770>: cmpq -0x8(%rbp), %rax
rendersystemtest[0x1cfbae] <+1774>: movb %cl, -0x101(%rbp)
So, the symbols exist somewhere, they are just not being shown in the UI call stack.
Furthermore, this lack of call stack symbols is a recent result. Previously, the same executable displayed a symbolicated call stack when paused or stopped by an assertion:
My questions are:
What could have caused Xcode to stop showing symbols in the UI call stack?
If the symbols are available for a crash report, why can't Xcode display them in the UI call stack?
[Edit]: Why is Xcode displaying the symbol in the Debugger Source editor, but not in the call stack itself?
[Edit 2016-11-05] After further research, this seems to be environmental...and possibly related to an update to macOS Sierra. This problem does not occur on a similar MacBook running El Capitan.
Still have no idea what the root cause is though. Any input would be appreciated.
I found a guide how to bypass it in ollydbg:
see here
But how to do that for an x64 application?
I have found following:
How must i manipulate this to don't get it detect the debugger?
You can do it the same way as described in the guide (i.e. by patching the code of IsDebuggerPresent).
Or you can set a breakpoint at the "movzx eax, byte ptr ds:[rax+2]" instruction, and when the program stops at the breakpoint, go to RAX+2 in the Dump pane and then change the byte from 1 to 0.
Well i'm in the situation where my dll file passes all the tests but somehow on the production server it sometimes does crash at the least expected moments.
There is actually no possibility to run a debugger but there is a generated stacktrace file:
An exception occured at address 0x0045DA51 in module my.dll
Registers:
EAX: 0x61A881BC
//data......
EFLAGS: 0x00010206
Stack:
+0000: 0x0379F5E4 0x00000000 0x01F1B968 0x00000001
+0010: 0x00000007 0x01F1BCA8 0x00454622 0x742F3500
+0020: 0x00000034 0x00000001 0x00000009 0x00000002
+0030: 0x00000000 0x00000240 0x61A881BC 0x000000A4
+0040: 0x00000000 0x60104F70 0x01F1C15C 0x60104F7D
//more data..
Is there any possibility to load this data into visual studio 2013 to perform some offline debugging (not runtime debugging, I don't know how to call it)?
You should see a crashdump somewhere, a .dmp file. You can export that through sysinternals PrcessExplorer, not sureif that's possible with the default task manager, but that's of course before the crash. I unfortunately don't know anymore how to force a process to generate a .dmp file on crash..
But once you have the .dmp file, you can open it in VS (I think since 2010, maybe 2012).
There are two kinds of dumps, a minidump (basically just including the point of the execution at that point) which is usually < 1 MB, and a "full dump", which incorporates the whole working set of the process afair, which can easily be hundreds of megs. The minidump usually is enough to get started.
Sorry for the incomplete answer, but maybe it gets you on the right track (no time to investigate on my own right now).
I am debugging a driver in a VirtualBox VM, with WinDbg attached to the target via COM port exposed to the host as a named pipe.
Debugging works fine - I can pause the target, set breakpoints, step through source files .etc
When my driver encounters a fatal error WinDbg dumps the following output to the console:
*** Fatal System Error: 0x00000050
(0xFFFFF88004126840,0x0000000000000001,0xFFFFF88003E12690,0x0000000000000000)
Driver at fault:
*** MYDRIVER.sys - Address FFFFF88003E12690 base at FFFFF88003E12000, DateStamp 51249ae5
.
Break instruction exception - code 80000003 (first chance)
A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.
A fatal system error has occurred.
Connected to Windows 7 7601 x64 target at (Wed Feb 20 09:57:54.670 2013 (UTC + 0:00)), ptr64 TRUE
Loading Kernel Symbols
...............................................................
................................................................
..............
Loading User Symbols
.....
Loading unloaded module list
.....Unable to enumerate user-mode unloaded modules, Win32 error 0n30
Loading Wow64 Symbols
..........................................................
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 50, {fffff88004126840, 1, fffff88003e12690, 0}
The little status box on the debugger command line is blank, and the debugger does not respond to the commands I type in.
I want to see the call stack and inspect the machine state, but the debugger remains unresponsive. Pressing BREAK/CONTINUE seems to have no effect.
I don't understand - what is the state of the debugger at this point?
I have a suspicion that my whole debugging setup is just very, very slow.
Debugging via com port is very slow, you must switch to virtualkd - http://virtualkd.sysprogs.org/ (its use shared memory between host and guest and much much faster). And don`t press anything while you waiting, its slow down process a little bit more.
In general com is outdated and while debugging, without vm, all use firewire or usb interfaces.