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.
Related
hope someone can help.
I'm currently writing a 2D game engine in c++. When I run the application from within Visual Studio 2008 using either debug or release all goes fine.
When I then run the executable files (either debug or release) from Windows Explorer, neither work and just display a blank Window.
Does anyone know what is causing this?
Load project into VS 2008
Change configuration to "Debug"
Click the "Start Debugging" button
Application compiles and builds, all is ok
Application runs, all is ok
Close Application
Output window in VS shows "The program '[16672] Mouse Engine v2.exe: Native' has exited with code 0 (0x0)."
Open Windows Explorer window and locate executable file from the Debug folder in project.
Run executable, blank window is shown.
Change configuration to "Release"
Click the "Start Debugging" button
Application compiles and builds, all is ok
Application runs, all is ok
Close Application
Output window in VS shows "The program '[18872] Mouse Engine v2.exe: Native' has exited with code 0 (0x0)."
Open Windows Explorer window and locate executable file from the Release folder in project.
Run executable, blank window is shown.
Some things to look for are missing dependencies such as config files and data files that your program can't find.
You can also try Dependency Walker to make sure all your dll's are available. http://www.dependencywalker.com
There are a few things to check to resolve this sort of problem.
Check all variables are initialised. Seems obvious but this can be crucial. I found best way to solve this is to #DEFINE _LOG at start and output variable values to a log file in each function using #IFDEF _LOG. This way you can turn it on or off.
If your application is just a blank window, check if it is running (using CPU time). This is a good indication that something is preventing it to find any image or font files.
Check that the Debug or Release folder structure matches that within your project folder to ensure links to files and textures work.
Make sure in project preferences to set the Runtime Library entry to Multi-threaded (/MT). This should make your application less dependent on additional dll’s.
Check for problems in your code. See point 1 with using log files to help with this.
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.
I have configured my windows 7 to create mini dump files on crashes but when my application crashed, no dump file was created. The search for answer left me rather confused as to when are dump files created, when windows crashes or my application crashes?
In my case, I am looking for dump file when my application crashes. I receive a typical crash dialog that states:
TheApp Application has stopped working
Windows can check online for a solution to the problem
-> Check online for a solution and close the program
-> Close the program
-> Debug the program
So can I generate dump file for my application when it crashes? I can't produce this bug on development machine so I want to walk back from dump file. Is there any other option to trace the source of bug (to source code)?
First of all, there are different places to configure a "create a minidump on crash" setting, which are totally different.
You can configure Windows to create a kernel dump file when Windows crashes, i.e. when a Bluescreen of death (BSOD) occurs. This is done in the following screen on Windows 7:
You can configure Windows to create a user mode dump file when an application crashes, i.e. instead of the "Windows Error Reporting" dialog which would normally appear. To do so, and you know that in advance, then configure a Registry key called LocalDumps (MSDN). By default, dumps will be created below %LOCALAPPDATA%\CrashDumps and they will have the naming scheme app.exe.<PID>.dmp.
For the sake of completeness, there might be other triggers. The only sure way to tell is: when the method MiniDumpWriteDump (MSDN) is called.
I'm quite sure that you want option 2 of the above. If you have trouble with it, see whether all the conditions for LocalDump are fulfilled.
The answer given by #antlersoft does not work, for the reasons I have posted in my blog: at the time the dialog is shown, Windows has triggered a breakpoint to stop the application and it has injected a callstack of Windows Error Reporting. All in all, not a good starting point for debugging.
What would work is:
attach a debugger of your choice
press "Go" in the debugger
press the "Debug" button of the WER dialog
confirm the warning about the debugger which is already attached
click "No" when asked to start debugging using the selected debugger
Using Task Manager to create a crash dump is not recommended, since it will not consider the bitness of the application, which may cause trouble later. See ways to create good and useful crash dumps.
Minidump is created when Windows crashes. It's not intended to application crash.
If you want to debug crashes of your application, you may attach it to a debugger after it is started. Clicking on the "Debug" button when application crashes do the same. You can use the debugger of MS Visual Studio to do that, for example.
See this page for help on attaching a process to MS Visual Studio debugger:
https://msdn.microsoft.com/en-us/library/3s68z0b3.aspx
EDIT: following text removed, as this may not work as expected (comment from Thomas)
You can also create a dump file from task manager, however you will still need a debugger to analyze it and, actually I am not sure you will be able to get the dump file at the point application crashes. The best way, if you can, is to debug the process on the target machine by attaching it to debugger either after it is started or when crash occurs.
When you get the crash dialog, go to Task Manager, find the process, right click on the process, and select "Create dump file". The dump file is created in the AppData/Local/Temp folder for the user; it will be named %AppData%\Local\Temp\.DMP; if you create multiple it will be -1.DMP, etc. You can move the dump file to your development machine and open it within Visual Studio. Visual Studio will then act as if you had hit "Break all" at the point of the crash while running the process in the debugger.
I am trying to find an easier way to test my command line application. It has arguments so I run it from a command prompt. My process is this:
Build
Go to the output
Open command prompt
Change directory
Run it
There has to be an easier way not only to debug but to open a command prompt in the current folder.
Thank you for your time.
If you go to the project properties, Debugging settings, you can set the working directory and parameters. If you use the same parameters all of the time, you can enter those in on that screen as well. Then just F5 or Ctrl+F5 to run.
Set a breakpoint at the end of the code to keep it from going away after it is done.
See Debugging with command-line parameters in Visual Studio
Alternatively, you should be able to use a shell script (or Python os.system()) to automate some of those steps.
To open a command prompt in the current directory using explorer, you can shift+right click->Open Command Window Here. That will save a little time.
If you're using Visual Studio, pressing F5 will run the code in the debugger, and Ctrl+F5 will run the code normally. Just remember to include a cin.get() statement at the end or the terminal window will close before you can read the output.
Other IDEs should have similar functions. Check in the Run or Debug menu.
EDIT: Sorry, didn't see that you're asking about running it with arguments. In VS, in Project Properties there are the Debugging settings. Within that, there is a field called Command Arguments. These will get passed to the application when you run it from within VS.
In project properties under debugging you can set the command line arguments (and environment variables) when debugging,
There is an extension called PowerCommands for Visual Studio 2010 that can be installed from Tools -> Extension Manager. It includes a Open Containing Folder and Open Command Prompt functionality that gets added to your right-click menu in the Solution Explorer.
I'm trying to debug shell extension (IContextMenu) in Windows 7 with Visual C++ 2008. I have set DesktopProcess=1 in the registry and set host app to explorer.exe. But when I start the debugger, it launches explorer.exe and then detaches from the process. DllMain of the shell extension isn't called.
The same code with exactly the same settings launched in debugger without any problems in Windows XP + Visual C++ 2008.
Any thoughts how to debug the shell extension in Win7?
I've found a nice workflow that I think is the fastest way to rapidly iterate the code-build-test cycle when developing shell extensions. The following should work on any Windows version.
First prepare - set the start program of your shell extension project to be c:\windows\explorer.exe and also set it to be the start-up project.
Then, whenever you want to debug your shell extension perform the following steps:
Click on the task bar and press Alt-F4 - this will bring up the shut down dialog
Press Ctrl-Alt-Shift-Escape - this combination will close explorer.
Use Alt-Tab to go back to Visual Studio and press F5 - explorer will now launch with the VS debugger attached to it from the very beginning.
When done, just stop the debugger session. This will kill the debugged instance of explorer and will also automatically start a normal instance of it. This will also unlock the shell extension DLL so that you can build it again.
Caveat on Vista and 7 - be sure to run the Visual Studio that you use for debugging in non-Administrator mode (non-elevated), so that the explorer is started in its usual non-elevated mode.
Try launching explorer and THEN attaching the debugger to it.
You could try putting a DebugBreak() call in your code. This should launch the just-in-time debugger at the call and give you an idea of what is going on.
You should take a look at gflags.exe, part of the standard debugging tools sdk. It's got all the options you need to configure (global)flags for any process startup/services/heap/pool-tagging/stacktrace's-on-allocation etc...
Debugging Explorer.exe is usually overkill for extensions that operate in a shell view.
I personally use a little app I made that hosts an instance of IExplorerBrowser similar to this example. If your IContextMenu item is not the default item then you can just use Notepad.exe and its open file dialog...