My workflow follows.
Configure the symbol file path and source code file path for WinDbg.
Open one source code file to be debugged later.
Press F9 and try to set breakpoint in the source code.
WinDbg pops up an error dialog, saying 'Debuggee must be stopped before breakpoints can be modified.'
Who can tell me why? My WinDbg version is 6.11.0001.404 (X86), Windows XP 64-bit. I am debugging a dll from within very complicated runtime system.
I wrote a simple exe and click to open it. Immediately after opening it, I open the source code file and set one breakpoint. It works in this case!
The hint is in the error, "Debuggee must be stopped before breakpoints can be modified". You have to break into the target process with Debug->Break before WinDBG will let you set a breakpoint. When you launch an EXE under WinDBG is starts off broken in, so you can set the breakpoint.
-scott
Related
I am trying to attach a debugger of Cheat Engine to an application that wrote by me with C# VS2015. It always displays a message of debugger timeout, no matter what debugger mode I selected. How to attach a debugger of cheat engine successfully?
Error Message Capture:
https://postimg.cc/jDC1CYkC
https://i.postimg.cc/8zbgK1Rd/debugger-time-out.png
Download x64dbg and SyllaHide
Copy x64 of SyllaHide to x64dbg folder
Open x64dbg and attach the application you want.
Go to the "Dump1 view" of "CPU" tab. Press Ctrl+G, enter the address you want to set a breakpoint. And then move the cursor over the address and Right click select breakpoint, then select "Hardware, ACESS"
If the value is changed, the debugger will locate the induction and stop at there.
If I try to start debugging through the command "Open" of x64dbg, debugging stops without ever starting and a series of missing DLL errors are shown on the screen.
If I just open the program from WIN and THEN I use the attach command by selecting the process, debugging works.
Unfortunately I wanna "investigate" from the moment the program starts and not when it is already started.
How can I solve it ?
You need some anti-anti-debugging plugins (such as ScyllaHide) for x64dbg mentioned in this page to counter anti-debugging attempts and do some patching if needed:
https://github.com/x64dbg/x64dbg/wiki/Plugins
I have a windows service that was written in VB6 that I want to attach to and debug in WINDBG.
The service is compiled without optimizations (also all boxes in "Advanced Optimizations" are unchecked), and "Create Symbolic Debug Info" is checked. I have the source file of a class I want to set breakpoints in. I can set breakpoints on some lines but not all... even though the lines where I can't put a breakpoint at don't have anything exotic, simple variable assignments and such.
Regardless, the breakpoints I can set are hit when I run the service with the g command, but when I start to "step over" (F10), the code does some strange leaps and doesn't (or at least doesn't appear to) evaluate all lines...
It seems to me that the source file and the symbols file are out of sync, but I just compiled the project and moved the files over to the computer where I want to debug... What could cause the source files and the pdb/dll file of the project to be out of sync?
I need to debug a process (starting from an external exe) that terminates immediately after start, so I don't have time to attach. How can I debug it?
UPD I don't have source code of that external exe; I can decompile it, but it's impossible to compile it back
You need to launch your process for debug in a suspended state. Visual Studio is capable of that, just invoke the debugger like this:
devenv /debugexe yourprog.exe <arguments>
The process will start suspended so you'll be able to iterate through first instructions before the crash.
See the detailed answer here.
You just need to open Visual Studio, go to File -> Open -> Project / Solution
and select the exe.
Press F5 and you will see the exception in the Output window. If you go to the Debug -> Exceptions window and select everything you will see the first chance exception before it shutdowns the application.
Note that you don't need the source code at all to do this.
Hope it helps.
You need to start it with the debugger. This will start the program with the debugger already attached.
If you cannot do that with Visual Studio, you can use the Windows Debugging Tools, part of the Windows Driver Kit. Note that the linked kit is for Windows 8.1, you may need to find older versions if you're not on Windows 8.
You can enable debug mode runtime by placing some piece of code.
write a method as below:
[Conditional("DEBUG_SERVICE")]
private static void DebugMode()
{
Debugger.Break();
}
and call this method where you want to start debugging, for example in the OnStart event.
you have to build your code with debug mode. dont forget to remove this piece of code after debugging and want to release.
Is there a way to follow a program's execution through DLL code in hex?
For example, I want to see what sections have just been read when I press a button. It has to work for x64 DLL's.
Thanks!
Yes you load the process into debugger and single step it.
Load the project in visual studio.
Press 'Play' or F5 to start the program in the debugger.
You will need to eventually halt execution sometime so you can start stepping through code or assembly code. You can do this by inserting a breakpoint, or breaking the execution by hitting the break command in the visual studio IDE.
Once halted, you can right click in the code view window, and select "Show Disassembly". Then it will show you the machine instructions.
Also in the watch window in the visual studio debugger, the right click pop up menu has an option to display all variables as hexidecimal. I'm beginning to prefer hex myself lately, because I can see invalid memory patterns easier.
You can use the tool at http://ircdb.org to log function calls arbitrary DLLs.
It's name is SocketSpy, because initially it was created for tracing winsock.dll only, but it does allow you to trace other dlls.
From http://fixunix.com/programmer/95098-tracing-library-dll-calls-win32.html
Use Option->Default Break Point List
Menu to add or remove soft breakpoints
from attached DLLs. Put soft
breakpoints only at function you need
to maximize execution time.
Soft breakpoint means that socketspy
does not stop at this breakpoint, only
log breakpoint information. Hard
breakpoint means that socketspy DOES
STOP at this breakpoint, and
Breakpoint dialog is opened. Specify
what calls should be captured ALL,
FROM EXE FILE or from DLLs (Combobox).
Specify log file File->Open Log File
menu if you want to save function
DLLs' calls into the text file, enable
logging (check box).
Then select a new or already action
process (Select Process button). The
tool can be used in NT/2000/XP only
Alternatively, there is StraceNT, which can trace arbitrary Dlls. It is available for free from http://www.intellectualheaven.com/default.asp?BH=projects&H=strace.htm
I've not used it, but I once stumble upon an Intel tool, which samples the context of the Instruction Pointer, and is able to use symbol files to convert IP to an actual function name... VTune maybe?
I guess there might be other such tools
UPDATE: aka. "statistical profilers"...
Debugging using IDE does not show you the assembly language equivalent of the execution of an IL instruction. You need to write your own hooks to a proper disassembler.