Assembly & Symbol of exe file from visual studio were gone after build for debug purposes - c++

I am learning about reverse engineering on windows. I was following Reverse Engineering and Function Calling by Address. I did not download those source demo. I just write down a little c++ console and debug it my self with Ollydbg or xdbg64. Just for to know how windows' stack work.
#include <Windows.h>
#include <stdio.h>
void __cdecl mySecretFunction(int * param1, const char *param2,
DWORD param3, BYTE param4) {
// Do somethng
}
int main() {
// Do somethng and call mySmySecretFunction()
}
I have enable /DEBUG and choose Debug on Configuration on App properties page.
I ran App.exe and it works well. I debug with Ollydbg, it can run normally, but both disassembly and symbol of the exe are gone or missing. So I cant debug it.
So what I must to do/configurate in visual studio 2017 so I can debug my simple c++ console with external debugger like Ollydbg or x64dbg ?

The following steps worked for me with Visual Studio 2017:
Create an empty C++ project.
Add the source code you provided.
Go to your project properties, select Debugging.
Change Command to c:\x64dbg\release\x96dbg.exe (notice the 96), this starts x32dbg.exe or x64dbg.exe depending on your executable architecture.
Change Command Arguments to "$(ProjectPath)" arg1 arg2 where $(ProjectPath) is the previous contents of Command and arg1 arg2 is the previous content of Command Arguments.
Debug the executable by launching the program without debugging (Ctrl+F5). If you launch the debugger like usual you will be debugging x64dbg itself, which is probably not what you want.
There is no real integration with x64dbg and Visual Studio, this simply starts x64dbg with the right arguments to debug your application from Visual Studio and you would be much better served by loading the application in x64dbg once and then manually loading it for low-level debugging.

don't enable debug mode if you want to debug in olly-DBG. debug mode is for debugging in visual studio. in this mode you can see variables name and run program line by line. the line and varietals name have no meaning in olly-DBG. it is better that don't compile in debug mode.
you can't see your code beacuase you don't pause your program at winmain.
Go to option > Debugging option > Events and select Make first pause at:>WinMain (if location is known)
hope it help you.

I know this question is old. Anyways this's my own answer to your question.
Using the visual studio, you can integrate your debugger x64dbg to your project or current project like this.
You need to locate the part to your x64dbg program, either x64 or x86 version depending on the bit of the application you want to debug or build etc.
Provide an argument for this current project of yours. In this case, either by the full part to the executable of your project or better still in a more portable fashion, use the Microsoft macros as shown in the picture below.
And although you can provide the target initial directory for the program, but is optional. Then whenever you want to debug your application, all you need to do is just click the button and the debugger will start with the application.

Related

Debugging Library Code with Visual Studio's Linux support

I'm using Visual Studio 2017's integration to build and debug a CMake Linux application locally in the Windows Subsystem for Linux.
When running the application, Visual Studio uses an ssh connection to localhost to run cmake -DCMAKE_BUILD_TYPE="Debug" .. and make, then uses gdbserver to debug the application. This works fine for my application's own code, including breakpoints and line-by-line debugging.
This application links to a library file, libhypro.so.17.09, which is also part of a CMake project. This library is also built locally (stored in my Windows file system, built within Linux through the /mnt/c/ mount, just as the main application) in debug mode. CMake did discover that dependency automatically.
I'm having trouble debugging my calls to this library. For example, if I break just before a call to library code and choose to Step Into, this is where I end up:
Note that
the Call Stack has disappeared, showing [Unknown/Just-In-Time compiled code] instead,
I'm inside an unhandled exception (which I'd expect to hit eventually, but certainly not immediately after a Step Into) and
the Modules window indicates that no symbols are available.
In addition, I did set a breakpoint in the library's code, and Visual Studio (correctly) asserts that “the breakpoint will not currently be hit”. Also, Debug output prints Loaded '/mnt/c/Users/felix/git/hypro/build/libhypro.so.17.09'. Cannot find or open the symbol file.
I'm relatively certain that libhypro.so.17.09 does include debug symbols as nm -gC libhypro.so prints a lot of output.
My case appears to be similar to this question but I'm not specifying the library's path manually, it's discovered by CMake.
Why are gdb and, in turn, Visual Studio failing to debug the library's code?
If you are debugging in gdbserver mode, the default, try switching to gdb mode in the project properties / debugging page.
Basically, gdbserver mode is a nice idea that never quite delivered. Here's one discussion about it on the VCLinux GitHub site. As you'll see, gdb will become the default debugging mode once they've fixed the problems with console applications.

Application using a DLL, but Visual Studio 2010 not showing it in Modules window

I feel like this is a stupid question, but I can't seem to figure out the answer. I've currently got a C++ application that's loading & utilizing a DLL (I compiled both the application & the DLL with VS 2010). I'm positive it's using the DLL, because a) if I rename the DLL, I get a not found exception, and b) it's displaying output that only comes from (and I can change it to see the output change) inside the DLL.
My problem is that in Visual Studio's Modules window while debugging, the DLL does not appear to be loaded. Because of this, obviously its got no symbols and I can't set breakpoints... But this doesn't make any sense to me as it's clearly using the DLL.
I've seen several other similar questions, and the answer has generally been too look at whether the code is native, managed, or mixed, and set the "Attach to Process" field accordingly. I've tried all the options there, and made sure my Debugger Type is set to "Mixed" (though I've tried it with Native & Managed as well, just to verify none of these solve the issue).
Does anyone have any suggestions?
Thanks in advance!
This happened to me and I found the project->properties->Debug page and clicked the box to Enable native code debugging. I was doing a C# project accessing a C++ / native dll
budward
I have some ideas:
check output windows it the DLL symbols are missing.
Make sure dllname.pdb file exist beside the DLL
make sure visual studio solution has two projects (EXE,DLL) projects
switch to DEBUG mode instead of RELEASE mode.
run process explorer (download it from MS) and check the path of the DLL that is bonded to the EXE in runtime.
Finally the ultimate solution:
Open Process Explorer and search for your DLL name.
Find which EXE is using it.
Goto VS and attach your debugger to that EXE.
I hope any of those fix your issue

What does this error message mean?

In C++, on this site: http://msdn.microsoft.com/en-au/visualc/bb985511.aspx
I downloaded the code sample and went to Debug and it came up with a messagebox with 2 textboxes in it and told me to specify the executable file to debug. So I did, and then I clicked browse, but there is NO executable because the stupid thing hasn't created one yet.
I'm using visual studio c++ 2008; what's up with that weird message?
This message generally comes up when you try to debug into a system DLL or 3rd party code. Set a breakpoint with F9 and hit F5 and see if stop in your code in debug. Also make sure you are building the debug version.
happy coding.
That project builds a DLL. If you're going to debug a DLL, you need to provide a .EXE that loads the DLL.

Native C/Managed C++ Debugging

I have a native C Dll that calls 'LoadLibrary' to load another Dll that has the /clr flag turned on. I then use 'GetProcAddress' to get a function and call it on dynamically loaded dll. I would like to step into the dynamic library in the debugger, but the symbols never load. Any idea?
And I should have said I'm using Visual Studio 2008.
Update: Thanks to some tips below, I changed the project debugging to Mixed. It didn't work, but I think I know why. I am developing an addin to an existing application. The app I'm connecting to starts one exe then it starts another. So I have to use "Attach to process" to fire up the debugger. My guess is launching the debugger that way will default to "Auto". Is there a way to change the default behavior of VS to use "Mixed" debugging?
This is from VS2008, but if I remember correctly VS2005 was similar. In the native project's properties, under "Configuration Properties->Debugging" there is a "Debugger Type" which is set to "Auto" by default. You'll need to change it to "Mixed", because VS isn't smart enough to realize you need managed debugging
I've had mixed experiences with doing similar things like this in VisualStudio. You might consider using ProcMon to see where VisualStudio is looking for the PDB file. Alternatively, you might try using WinDbg. It seems to do better at loading symbols and if it doesn't, you can explicitly load them yourself. Using WinDbg involves riding a steep learning curve, but if you're burning time right now, isn't it worth it?
You can also run the exe on its own and from the source of the managed dll, attach to the process to debug it.
Modify the mixed-mode dll to throw a CLR exception where it enters the first code you're interested in debugging. This should give you an opportunity to launch the managed debugger.
In VS2005, there are per-project options to enable native and CLR debuggers separately. You might need to enable the CLR debugger for the native dll project from which you start the debugger.

Run .exe outside IDE but use break points inside IDE

Using VS .NET 2003. Would like to run the .exe from outside the IDE (i.e. command prompt or double clicking .exe icon in windows) However, still want break points to hit in the IDE.
How do I set this up?
(Running from outside IDE but IDE seeing it as run from "Debug" -> "Start")
Thanks.
On the Debug menu, choose the "Attach to process" option to attach a debugger to your externally-running application.
Visual Studio enables Just In Time Debugging by default. If you haven't turned it off you can call DebugBreak() and you will get a popup allowing you to attach a debugger. If you don't attach a debugger then the program will exit, so you could try wrapping the DebugBreak call in a MessageBox or some other conditional code based on an environment variable or config item.
Since it is C the call to DebugBreak() is correct - this will give you a nasty error dialog (different look depending on the OS), which should have a 'Debug' option. If you click this you should get a dialog to select one of the installed debuggers (VS.NET shoud be among them). Selecting it should bring you to the DebugBreak() line. However this can fail if the debugger can not find the pdb files for your app - in that case you will just get the disassembly view and no source code view.
You can also use WinDBG and the 'Open executable option' - again it will need the pdb files to yield anything useful.