I'm using Visual Studio 2012 to write in assembly and I'm currently using the PUSH/POP instructions.
I would like to know where does sit the value being pushed to the stack by the PUSH instruction.
I've tried the Memory Tab by locating the ESP address but didn't find anything there.
Can please someone tell if it is possible and how to reach/locate the pushed values in debugging mode?
Thank you,
Guy
On the topmost toolbar in Visual Studio:
"Debug > Windows > CallStack"
Note that this is only available with the debugger attached to a process.
[Frames below may be incorrect and/or missing, no symbols loaded for
ntdll.dll]
MSDN article: Using the Call Stack.
That error message indicates there are no debug symbols available for the project to use. Make sure that you are in debug mode, not release.
Also if you are using "debug > attach to process" make sure the .pdb (symbol files) are available.
Either:
make sure the .PDB files for your DLLs are in the same directory as the process executable that you are attaching the debugger to.
OR
open Debug > Windows > Modules
Check Symbol Status ("Cannot find or open PDB file" means they aren't loaded)
Locate your DLL
Right click it and
select "Load Symbols From > Symbol Path"
Related
I used to work with VS 2008 but I am missing the following feature in VS 2010 when debugging MFC C++ app:
whenever an assertion occurs, VS 2008 automatically opens the source file and focus the line with an assertion expression
in VS 2010 I have to mark the file name and line of assertion and then manually open the source file and scroll to the expression
Is there some option or registry setting how to enable such behaviour in VS2010 like it works in VS 2008 ?
The first setting that really matters in in the Project + Properties, General page, "Use of MFC". You'll have no trouble if you select the "Use MFC in a static library" setting. This causes the linker to generate the debugger .pdb file entries for MFC symbols, giving the debugger an easy time to find the MFC source code files on your machine.
This isn't always practical however, the "Use MFC in a shared library" setting is the normal one. Which will load the MFC dll from c:\windows\system32, put there when you installed VS. Getting a .pdb for this DLL requires enabling the Microsoft symbol server, Tools + Options, Debugging, Symbols. Press F1 to get config help for this setting page.
You can verify this worked out by using Debug + Windows + Modules while debugging and checking the Symbol File column for mfc100xx.dll. Right-clicking the module and Symbol Load Information provides additional info, showing which directories were searched to find the .pdb
A further complication is that the .pdb that the debugger will download was created on a build server in Redmond which had the source code files installed in f:\dd\vctools\vc7libs\ship\atlmfc. Obviously not the directory where you have them installed. The IDE will prompt you for the actual source code directory. This prompt is often highly confuzzling so clicking Cancel on the dialog is a common thing to do. You now however bought the farm, the IDE remembers that you cancelled this dialog and won't prompt you again. You reset that by deleting the hidden .suo file in the solution directory.
When debugging with Visual Studio 2010, sometimes there aren't PDB files available for system libraries as I've not built them myself (i.e. they've not been built for debugging). This is OK as I don't need to access them. A sample warning might be something like:
'Plugin Host.exe': Loaded 'C:\Windows\SysWOW64\xmllite.dll', Cannot find or open the PDB file
However these warnings clog up the Output pane making it quite hard to debug sometimes. Is there a way to suppress these at all?
Thanks, Hemmer
These PDBs actually are available, enable the Microsoft Symbol Server support. But yes, you can suppress these messages. Right-click the Output window while debugging and untick "Module Load Messages". The value is preserved for future debug sessions. Note that it isn't actually a warning, just a diagnostic that tells you which DLLs are getting loaded.
(I just posted this in the NUnit discussion group on groups.google.com)
Under VS 2008, I would run my tests under NUnit, and, if I needed to
debug, I would attach the VS2008 debugger to the running Nunit process
(Debug -> Attach to Process), and set any breakpoints on code I wanted
to examine. When I hit the Run buttion in NUnit, it would hit the
breakpoint. (BTW, if it matters, this was running NUnit 2.5.2).
I just upgraded to NUnit 2.5.4 and VS 2010. When I set a breakpoint,
then attach to NUnit, I get a little warning symbol on the breakpoint
dot, and hovering over it gives the tooltip "Breakpoint will not be
hit. No symbols are currently loaded". Going to the Debug -> Windows -> Modules window shows a whole bunch of Windows and NUnit modules
loaded, with the Symbol Status of "Skipped loading symbols", and then
1 module with a funny name that changes each time (r1euhmh5 right
now), and Symbol Status of "No symbols loaded". (There is no trace of a module with a name remotely like my DLL under test).
Right clicking the funny filename (assuming that to be some mapping from my
DLL under test), and clicking Load Symbols From -> Symbol Path, and
navigating to the bin\debug folder, then clicking the pdb file of my
DLL under test, I get the message "A matching symbol was not found in
this folder". (The top of the Open dialog box has a line that says
"Original location: r1euhmh5.pdb")
So what's changed? And how do I go about debugging/breakpointing
under VS 2010/NUnit 2.5.4 (Or is it possible I screwed something up
when I decided to go through my VS2010 options and set some of them to
more advanced levels than I knew what I was doing?)
I appreciate any help.
I'm not sure I understand exactly why, but the answer is to attach the debugger to nunit-agent.exe instead of nunit.exe. See Charlie Poole's response here
There's information on this blog post about how to tell NUnit to use the correct .Net framework in the nunit.exe configuration file.
The benefit to fixing this in the configuration file is that it allows you to set up your unit test project so that you can launch NUnit as an external command when you select Debug -> Start New Instance.
I have a 'release with debug info' unmanaged c++ .exe (built with VS2005) deployed onto another PC, the .exe and .pdb are in the same folder.
When I try to attach to the process from VS2005, either locally or remotely from my dev PC, all my breakpoints become disabled. I don't get any warning/error popups which makes me think the PDB file is being found, but not seen as 'good'. Is that the right interpretation? I think if it couldn't see the PDB I'd get a "no debug information could be found" popup.
Has anyone got any ideas what can be wrong?
Check the output window - it should tell you if debug symbols are being found when the debugger attaches.
Are the breakpoints marked with a yellow exclamation mark triangle? This could be due to the PDB not corrresponding to the version of the source you're using. Right click on the breakpoint and select the option that allows the source code to be different (or rebuild your executable)
HTH
Seb
My best guess is that Visual Studio doesn't find the source code PDB files refer to. I am not able to look now, but I think you have the possibility to specify the location of the source code by hand in these cases (I don't have visual studio available at the moment).
The PDB was being generated, but another compiler setting meant nothing useful was being put inside it!
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.