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!
Related
I've a solution which is ported from VS (Visual Studio) 2010 to VS2017 from one machine to another. I could debug while I can't. I need to know what's the problem. When running, I see the breakpoint marks get changed to include a warning, but I can't find what can be wrong. It seems that everything is ok.
1) Try to rebuild the application. Make sure that it's in the "Debug" mode.
2) If it works fine in VS2010 but failed in VS2017, I wonder if Visual Studio gets confused the configuration of the correct code type, if so you may need manually selected the .NET version. If you are using Framework 3.5 in VS2010, but on Visual Studio 2017 you are using such as Framework 4.6, by default automatically determines the code types to debug (v4.6, v4.5, v4.0). In this case you need to click in "Select..." button on "Attach to process" window and select Managed (v3.5, v3.0, v2.0).
3) Try to clear/delete all breakpoints from the Debug menu, choose Delete All Breakpoints. The reason is that it refreshes your Visual Studio setting file of your project.
4) Potential Workaround: Uncheck "Require source files to match original versions ..." in Options, Debugging.
In my case, changing from "Release" Mode to the "Debug" mode works!
When you launch the process, if the breakpoint icon turns hollow with the warning symbol, then the debugger cannot figure out what part of the program corresponds to that line of the source code. This is typically because the build is out-of-date with the executable, DLL, or PDB file.
A common way to get into the this situation is to not notice that the build failed and then let the debugger try to run the old executable which doesn't correspond to the current sources. It can also happen if Visual Studio gets confused about some of the dependencies and doesn't rebuild everything that needs to be rebuilt (which can happen after significant changes to the solution and/or project file(s), e.g., after an upgrade).
In these cases, clean out the build directory and force Visual Studio to rebuild everything. This will usually get you back in sync.
When you set a breakpoint in DLL code, that breakpoint will appear in the hollow warning state until the DLL is loaded. If your program uses delay-loading or if it manually loads the DLL (e.g., via a LoadLibrary call), you will commonly see this. Once the DLL is loaded, any breakpoint icons in the DLL should return to the normal red-ball state. If it doesn't yet you think the DLL should have been loaded. Check the Output window in the debugger to see if it really was loaded and whether there were any warnings or errors about loading the corresponding symbols from that DLL.
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"
A strange error:
error MSB8011: Failed to register output. Please try enabling Per-user
Redirection or register the component from a command prompt with
elevated permissions. C:\Program
Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets 744
I got this error when trying to use OpenSceneGraph (OSG) in an ActiveX control. A Google search showed all kinds of solutions which didn't really solve the problem or locate the exact cause of the error, so I'd like to put the solution in one place: Here.
I found the solution to it, and will be answering my own question soon, so that people can find their solution if they encounter the same problem.
This error happens when Visual Studio (2010) can't find the dependent dll files that are required by the program for creating the OCX. The OCX is created in the Debug directory of the project (for Debug builds), and specifying the "Working directory" (in project settings) as the folder where the dependent DLL's are, won't help Visual Studio in locating the DLL's.
Now the catch is (this is what makes it a headache to solve the problem) that sometimes, without Visual Studio being able to create the OCX, you won't be able to run Dependency Walker on the OCX. So you'll never figure out that the missing DLL's are the problem.
If you know which DLL's need to be placed in the Debug folder, just place them there, and the error will disappear.
If you don't know, and if your OCX didn't get created, then go to project settings > Linker > General > Register Output
and set the value to "No". This will create your OCX for you, but won't go through the process of registering it, which is when it needs the dependent DLL's.
Once you double-click the OCX and Dependency Walker shows you the missing DLL's with yellow circle icons, just place those DLL's in the same folder as the OCX, and your program will work fine. It's that simple.
The issue could be that your project tries to register a COM object, but there are not enough privileges to do that. On Windows 7 and 8 regsvr32 requires administrative permissions.
What you can do is the following. Create a shortcut on your desktop to C:\Windows\SysWOW64\cmd.exe (the 32-bit console). Right click, Properties -> Advanced -> check Run as administrator. Launch the shortcut, and make sure User Access Control pops up, and click Yes. Start building from this special console window.
I tried using run as "Administrator" VS 2015, it's able to solved the problem
MSB8011 seems to be a generic error raised whenever regsvr32 encounters a problem. In my case, regsvr32 exited with code 4 when Per-User Registration was set to "Yes", but the DLL I was building did not define a DllInstall entry point.
You can also do this via VS 2013 IDE by launching this IDE from program files shortcut, Select Visual Studio 2010/2013 and then right click and select run as administrator, after IDE launched, then open your solution file and build it, you will never get such errors because of regsrv32 DLL/COM registration
On the Property page go to
Configuration Properties->Build Events->Post-Build Event
you might be referring to it as a /Service. Modifying options as shown below could help.
Before modification:
After modification:
I fixed this in Visual Studio 2019 by going to "Properties -> Linker -> General -> Per-User Redirection" and setting it to True.
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.