I have a program I made using Visual Studio that won't start unless VS is debugging. Where should I look for problems?
The program works when debugging through VS but won't start from the debug folder. The program works fine when debugging. No output is given.
For this sort of startup problem I'd suggest running your app in Windbg (part of the Debugging Tools for Windows). Do File -> Attach to executable and then hit F5. You should get more informative output there. I suspect it's a dll dependency or manifest problem. Another useful tool is the Dependency Walker which may highlight some dlls that are on Visual Studio's path but not your default path, which may also explain the error. Another thing to try is check that all types of debug output are being shown in Visual Studio: right-click to get the context menu in the debug output window and ensure it's showing exception messages and module load messages.
Try turning on Stop on Exceptions
Debug - Exceptions - Common Language Runtime Exceptions (thrown and user unhandled)
Related
Want to debug an executable under debugger. How to do it in visual studio.
Windbg has an option of open executable. But I find this is missing in VS 2010.
The question is not exactly same as
Debug exe in visual studio 2010
as I am not really interested in image file execution to debug a start up.
Rather want to just debug the exe under debugger, once it is broken, want to
set some break points and understand the flow of execution.
Albeit image file execution is a workaround for this.
I am not sure if this question is naive; But this is a very straight line use case scenario, I find missing in MS VS 2010.
You did not specify it in the question, but I assume you do not have the source code. Just use File/Open Project/Solution, select EXE file and Open it. Then select Debug/Start debugging. The other option is to run the EXE first and then Select Debug/Attach to process.
If what your asking is how do you attach VS to the exe you want to run then you can follow these steps:
Run the executable
In VS navigate to Debug -> Attached to Process
Find your process created by running your executable and click "attach".
However, if the executable you are trying to run fails almost immediately or runs quickly and exits then you could try the following steps:
Set a debug point at the start of the code
Switch your build to Debug and run the application.
If your application is running in Debug, but failing when you execute the exe then you could try these steps to see if the your app will give more information in a console window or other.
Make sure your build is set to Release.
Navigate to Debug -> Start Without Debugging
If you have the source code, you can use Debugger.Launch();
You put it anywhere in your code, build the .exe and then once it gets launched (by Process.Start for example) and reaches Debugger.Launch();, a window will be asking you how you want to attach to the process.
Typically, you'll attach to some Visual Studio instance and it'll automatically pause the debugger where Debugger.Launch(); has been placed.
You can then open the project's files (File -> Open -> File...) and place breakpoints wherever you want.
I see that with the 'Attach to Process', one can debug the process by setting up break point in Visual Studio IDE.
I think it's pretty cool, and I'm curious what's the mechanism that enables it. I also found that gdb and Mac's Xcode supports the technology.
Q1 : Can anyone explain how does this work? How can the process mapped to a breakpoint in an IDE or gdb environment?
Q2 : Are there other compiler/debugger options than /Zi or -g (adding debug info)?
Q3 : Is this the way to debug dll (dynamic library)?
ADDED
I found this one with MSDN - http://msdn.microsoft.com/en-us/library/c6wf8e4z.aspx
The most common scenario I know of is using a browser to debug web code. In these cases, you start Visual Studio in debug mode and then attach to the browser and call the page in question. When the page is called it starts running the code in the debugger. Essentially, the debugger watches the process and when it hits code in VS, it starts debugging.
The same is true with other applications that are calling code you are running in Visual Studio. When you cross the boundary to the code, the debugger catches the call and starts running code in VS.
I use it fairly frequently when developing plugins for existing applications (Maya, Reaper, etc). As a general rule, plugins can't be run independently, so in order to debug them I have to run the host program and use "Attach to Process" to run the debugger on my plugin, at which point I can set breakpoints and all that other debugging goodness. You need to have debugging symbols and al that for the plugin, but you don't need to have them for the host application.
I have a solution comprising of about 6 projects, and when I debug on one machine, any un-handled exceptions that occur cause the environment to break at the point that exception is thrown, allowing me to debug it.
However, on a different machine with the same solution (in the same version of VS), all I get when an exception is thrown is the "Visual Studio Just-In-Time debugging" window popping up, which tells me the name of the exception, and little else - it offers to open a new visual studio instance in order to debug it, but that doesn't work, because it is already being debugged by the IDE!
What is going on, and how can I get back to visual studio telling me where the exception happened?
Cheers
You might want to check Exceptions in the Debug menu (mapped by default to Ctrl+Alt+E) and verify that both machines have the same exceptions selected.
Probably on the second machine you have less exception types selected in that window. When one of the exceptions that are not selected is thrown:
the debugger does not handle it because it has been instructed not to
the exception gets passes to the OS
the OS launches the default system-wide debugger which is the "Visual Studio Just-In-Time debugging" launcher if you installed VS2005 on that machine.
Sounds like it can't find the debug info.
Try copying the PDB files to your output directory.
I've had this problem as well - two machines, identical exception settings, different behaviours. The solution for me was to set the Debugger Type in the project properties on the "bad" machine to Mixed, even though the application only contains managed code. On the "good" machine exceptions are caught in Visual Studio using the Managed Only setting.
Our buildserver (TeamCity, much recommended), runs our a whole bunch of testsuites on our finished c++ program.
Once in a whole, a test causes our program to crash, often bringing up a VisualStudio dialog offering me to JustInTime debug the crash. The dialog stops the buildserver from progressing. Instead of the build marked as failed, it just hangs. I've turned off the Just In Time debugging feature in VisualStudio, but when it's turned off, you still get a message "Couldn't JustinTime Debug this, you can turn it on in the options".
Does anybody know of a way to ensure that any unhandled exception in a program does not result in any modal dialog?
This MSDN article explains how to disable Just-In-Time debugging on a Windows server. I've included the relevant portion of the article below:
After Visual Studio is installed on a server, the default behavior when an unhandled
exception occurs is to show an Exception dialog that requires user intervention to
either start Just-In-Time debugging or ignore the exception. This may be undesirable for
unattended operation. To configure the server to no longer show a dialog when an
unhandled exception occurs (the default behavior prior to installing Visual Studio), use
the registry editor to delete the following registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\DbgManagedDebugger
On a 64-bit operating system also delete the following registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\DbgManagedDebugger
Delete (or rename) c:\windows\system32\vsjitdebugger.exe.
I tried deleting the registry keys, and I tried unchecking all the boxes in the Visual Studio options, but neither worked.
To be clear, my situation wasn't a C++ one. I was using Micro Focus COBOL for Visual Studio 2010, and by using the registry and VS options suggestions I managed to get rid of the "Want to debug?" dialog, but that resulted in a different dialog to hold up my automated process:
Visual Studio Just-In-Time Debugger
An unhandled exception ('COBOL runtime: Fault detected') occurred in CASDBC.exe [3564]. Just-In-Time debugging
this exception failed with the following error: No installed debugger
has Just-In-Time debugging enabled. In Visual Studio, Just-In-Time
debugging can be enabled from Tools/Options/Debugging/Just-In-Time.
Check the documentation index for 'Just-in-time debugging, errors' for
more information.
OK
I would not recommend to edit/remove regs. Usually the registry is a mess to play with.
The solution that helps me is a quite simple. I`ve just added JIT debugger to my Visual Studio. Steps are:
Open Windows Control panel
Programs
Programs and Features
Find Visual Studio 2017
Click Change. On a new opened window navigate to the Individual Components tab
Check Just-In-Time debugger checkbox
Click modify
After VS reload the error should be fixed.
In my case , on win2012 server, I tried:
removing registry keys
deleting the exe for the jit debugger from c:\windows\system32
and it still came up!
I rebooted, etc.
Was making my web site in IIS stall until dialog was acknowledged!
Final solution, which did work: In control panel, in Programs: Uninstalled "Microsoft Visual Studion 2010 Shell (Isolated)" Uninstalled that, and problem solved.
(Whether SQL Management Studio still works.... I do not know!)
In the Window for the question
Do you want to Debug using the selected debugger?
Click YES (new window opens) > OPTIONS (top row menu) > DEBUG
Then in the New window remove the TICK which shows ENABLE JUST IN TIME DEBUGGER.
After disabling the JUST IN TIME debugger close the window or click OK
Your problem will be solved. I've tried this and got rid of the JUST IN TIME POP UP messages.
Best Solution for this problem is so simple
2 steps to make it done
open cmd prompt
type : regedit
go to path-->HKEY_LOCAL_MACHINE-->SOFTWARE-->Microsoft-->Windows NT-->CurrentVersion-->AeDebug
You can find now the file : Debugger
right click , Modify
copy and paste this text inside it:
drwtsn32 -p %ld -e %ld -g
click ok and voila :)
If an application†crashes,
I hit "Debug" and Visual Studio is my currently registered Just-In-Time (JIT) debugger:
Visual Studio appears, but there's no way to debug anything:
I do not see any disassembly
I do not see any registers (assuming it runs on a CPU with registers)
The call stack is empty (assuming the CPU has a stack pointer)
I do not see any symbols (assuming it had any)
I do not see reconstructed source code from reflection (assuming it was managed)
Other JIT debugger products are able to show disassembly, but they are either command-line based (Debugging Tools for Windows), or do not support symbols (OllyDbg, Delphi). Additionally, my question is about debugging using Visual Studio, since I already have it installed, and it is already my registered JIT.
How do you debug a program using Visual Studio?
Alternatively: has anyone written a graphical debugger that supports the Microsoft symbol server?
†Not, necessarily, written in Visual Studio.
Edit: Changes title to process rather than application, since the latter somehow implies "my application."
Edit: Assume the original application was written in assembly language by Steve Gibson. That is, there is no source code or debug information. Visual Studio should still be able to show me an assembly dump.
Looking at the screenshot it appears that Visual Studio is currently debugging in Run mode - you need to break execution of the process before it makes sense to look at things like the call stack, etc...
To break execution of the process you either need to hit a breakpoint, or you can break execution of the process at any time by using the Pause / Break all toolbar item (Control + Alt + Break).
Then you should be able to access the following windows under the Debug -> Windows menu:
The disassembly window
The registers window
The call stack window
The modules window shows a list of loaded modules along with where their corresponding symbols are loaded from (if loaded)
Some other useful windows:
The processes window is useful if you are debugging more than one process at a time
The Threads window
The Memory window (there are four of them)
The Locals window
Some of these might not be visible by default depending on which window configuration you selected when you first started Visual Studio - if you can't find them then right click on the toolbar and goto customise to add them.
Visual studio doesn't reconstruct soucre code from disassembly - you really need to have the original source code available to you, otherwise the symbols almost certainly won't match the source code you are debugging.
If you are debugging unmanaged modules without source code then I recommend you at least try WinDbg - its user interface is a bit clunky at times, and it does have a steep learning curve, however it is a very powerful debugger supporting many features that Visual Studio doesn't - it may be more suited to the sort of debugging you need to do.
(Visual Studio is a fantastic debugger, however it's primarily used to debug modules where the source code is available and so it lacks certain features in favour of a better user experience).
Assuming this is your application that you wrote in VS, just press F5 to run the program and either use a breakpoint, or manually break the program to start debugging.
The problem in the last screenshot is that Visual Studio did not enter break mode automatically. That seems like a bug. If you hit the 'pause' button on the toolbar, it would enter break mode, giving you disassembly, and a callstack.
According to that last screenshot you were actually attached to the program ... the output windows shows it loaded stripped symbols for OLE and the crt.
You can debug a program with Visual Studio if you have the debug information available for this program. It's the difference between compiling a Release version (normally without debug information) and compiling a Debug version.
This dialog to debug a program is handy if you are testing the debug version of your self-written program. You can attach it "on-the-fly" to your Visual Studio debugger and look for the problem.
If it is not your program or it is your program, but does not provide debugging information which Visual Studio can understand, then you are out of luck.
Use menu Debug -> Windows -> Disassembly (I think the keyboard shortcut is Alt + 8, but I am configured for VC 6.0 bindings, because that's how I roll, and it may have changed).
You can get public symbols for the operating system from http://msdl.microsoft.com/download/symbols. Add it to the list in menu Tools -> Options -> Debugging -> Symbols -> Symbol file locations.
Also, make sure you are running in the same integrity level as the application. Or always run Visual Studio as Administrator.
I guess you are already in the Debug mode. The "Run" button is disabled. Just go to Debug -> windows -> Disassembly to view disassembly.