I am using Visual Studio 2010 to debug an application mostly written in C. Normally, I can attach the debugger just fine, but I am running in to some problems when I link in a library written in C++ / CLI.
If I compile the library with the /clr flag (which I will eventually have to do for this as of yet unwritten library) then I lose all ability to debug the entire C application, even the parts that have nothing to do with the library calls. I get the empty circle with the yellow triangle and exclamation mark where a red break point circle ought to be. Hovering over it gives me only a tool tip that says "The breakpoint will not currently be hit. No executable code is associated with this line. Possible causes include: conditional compilation or compiler optimizations."
Then if I link with the exact same library compiled without the /clr flag, I am again able to debug my application.
I understand that visual studio will not likely be able to debug the library written in C++ / CLI, and that is OK. I just want to keep the ability to debug the rest of the application and at least see the results of my calls to the external library.
Another complicating factor is that this project is not being built by visual studio. It is compiled using an external make system that uses cl, so I can customize any commands that need to be issued to the compiler that way.
Does anyone know why I can't currently debug the libraries the way I want to? Any advice for how I can?
You have to select the kind of debugger when you attach. Note the "Attach to" label in the dialog. Press the Select button and tick "Native" to get support for debugging native code. The DLL also needs to be loaded before any of your breakpoints can hit. If you are not sure whether or not that was done then look in the Debug > Windows > Modules debugger window to see loaded DLLs. The breakpoint indicator turns from hollow to solid red as soon as the debugger saw the DLL load and armed the breakpoint.
Debugging C++/CLI is otherwise supported, you can tick both the "Managed" and "Native" checkboxes. And set breakpoints in either kind of code. The only thing not supported is single-stepping from managed to native code and back. A mode-switch is required to activate the correct debugging engine, that requires code to hit a breakpoint.
And consider the Debug options in your native project, you can specify an EXE to start. So that you can simply press F5 to start debugging and skip the attach hassle.
It might also have to do with the Debugger Type!
(but that depends on your specific building configuration about which I do not know enough)
If any of your projects is complied with Common Language Runtime Support (/clr) you should set the Debugger Type in your startup project to "Mixed", since the default setting "Auto" might fail!
Imagine, you have two projects:
1) A non-CLR C++ project, which is your startup project that generates some .exe file.
2) A C++ project, that generates mylibrary.dll, which is compiled with Common Language Runtime Support, because it uses some managed code. The .exe from the first project calls mylibrary.dll.
If you start the first project with Debugger Type set to its default value "Auto", you'll be able to debug into the first project, but not into the second one. The debugger selector does not realize that you will be calling a CLR-library.
So set Project Properties -> Configuration Properties -> Debugging -> Debugger Type to "Mixed"!
Related
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Debug vs. release in .NET
Debug/Release difference
What is the difference between Release and Debug modes in Visual Studio while building a project?
Debug and Release are just labels for different solution configurations. You can add others if you want. A project I once worked on had one called "Debug Internal" which was used to turn on the in-house editing features of the application. You can see this if you go to Configuration Manager... (it's on the Build menu). You can find more information on MSDN Library under Configuration Manager Dialog Box.
Each solution configuration then consists of a bunch of project configurations. Again, these are just labels, this time for a collection of settings for your project. For example, our C++ library projects have project configurations called "Debug", "Debug_Unicode", "Debug_MT", etc.
The available settings depend on what type of project you're building. For a .NET project, it's a fairly small set: #defines and a few other things. For a C++ project, you get a much bigger variety of things to tweak.
In general, though, you'll use "Debug" when you want your project to be built with the optimiser turned off, and when you want full debugging/symbol information included in your build (in the .PDB file, usually). You'll use "Release" when you want the optimiser turned on, and when you don't want full debugging information included.
Well, it depends on what language you are using, but in general they are 2 separate configurations, each with its own settings. By default, Debug includes debug information in the compiled files (allowing easy debugging) while Release usually has optimizations enabled.
As far as conditional compilation goes, they each define different symbols that can be checked in your program, but they are language-specific macros.
The main difference is when compiled in debug mode, pdb files are also created which allow debugging (so you can step through the code when its running). This however means that the code isn't optimized as much.
I'm trying to debug my shaders in Directx 11 SDK application using graphics diagnostics tool in VS2012, however when I click Start Debugging on one of the shaders in Graphics Pixel History panel I'm getting Pixel Shader.pdb not loaded and I'm not able to find the pdb file anywhere.
I tried compiling shaders at runtime using D3DX11CompileFromFile with D3DCOMPILE_DEBUG flag as well as using the HLSL compiler with debugging information turned on (/Od /Zi) but none of these options is producing the pdb file I could use in graphics diagnostics tool.
How do I generate these files?
I think this "Pixel Shader.pdb not loaded" message is misleading. The is no any .pdb files generated by HLSL-compiler. All debug info are integrated into binary (either memory blob or .cso file).
Does your shader file named "Pixel Shader"? Maybe it says not about a shader, but some kind of Visual Studio's internal source files (shader debugger in VS2012 was somewhat unstable sometimes)
Some ideas that, probably, can help you to solve issue:
Make sure that your debug and release output binaries are not messed up. Check both debug and release configuration of project's properties and each shader's properties.
Make sure that you are loading right shader file. Check ten times all file paths.
Clean your project, eliminate all binaries by hand. Rebuild again.
IIRC, in graphics debugger you can only debug shaders, compiled offline (i.e. not by D3DX11CompileFromFile).
Try to compile using fxc.exe directly.
Use filenames that does not contains spaces and special characters.
Make sure your test shader is simple enough, so debugger will not crash. Thy to use default template.
If it's still doesn't works, write a minimal example project, check that it doesn't works, post it here so we can test it.
Try VS2013
Try your videocard vendor's debugging tool (such as NVIDIA nsight or AMD GPU PerfStudio), to see if it is problem with Microsoft tools or not.
Hope it helps somehow.
I am trying to debug some problems in a native C++ COM DLL I have created and would like to launch the Visual Studio (2008) debugger from this. This dll is called by another dll that I was given, so basically my code plugs into another application through this. Anyway, in the past I had used C# to create this dll and was able to use the System.Diagnostics.Debugger.Break() method. Is there anything similar to this that can be used? I saw a few posts about DebugBreak and __debugbreak but this did not seem to work, it just appeared to stop my code from executing beyond that statement.
EDT: I followed the advice of paulsm4 below and found that the breakpoints did not work, it would tell me: "The breakpoint will not currently be hit. No Symbols have been loaded for this document"
Ideally, you'll have the project source for your COM/ActiveX .dll.
If that's the case, just set a break point in your .dll code, run your program in the debugger ... and that's it.
Please note the distinction between "managed code" (e.g. a C#/.net .exe or .dll) and "native code" (like your COM/ActiveX .dll). To debug "native code" under MSVS2008, you'll need to specify "mixed mode":
http://msdn.microsoft.com/en-us/library/kbaht4dh%28v=vs.90%29.aspx
Has anyone seen this/knows how to get the values in debugger local/autos window?
The project is a c++ project in a c++ solution. The dynamic lib is build wity /clr.
Due to the nature of the dll i can only debug it by attaching to a third party native process that loads it.
One interesting thing is that prior to including clr in these type of dlls when i would attach, in the output window i would get a list of all dlls loaded into the process, those would be c++ runtime sdk dlls, the third party native proc dlls and my dlls. Now I get only clr related dlls in that window + mine. All the runtime native dlls no longer get listed in that window. Its almost like the debugger does not load them for reference.
Found the resolution. When creating mixed mode assemblies in the manner describe in the question, it does not matter what debugger one uses in vs2010. The ide will autoselect the right one. Further more if your attaching, you can use both at the same time .net+native selectable in a combo box list in the "attach to:" section of the Attach to process dialog.
What you absolutely have to make sure of is to link with these 3 options: /MAP /MAPINFO:EXPORTS /ASSEMBLYDEBUG located in the Linker/Debugging section in project properties.
Per MSDN forum post.
Disable the setting:
Properties -> Configuration Properites -> C/C++ -> Optimization -> Optimization: Disabled(/Od)
Enable the setting:
Properties -> Configuration Properites -> Linker-> Debugging-> Generate Map File:Yes(/MAP)
I'm trying to debug a C DLL that I'm using with a Delphi program. I built the DLL with Visual C++, with debug information enabled. I built the Delphi program with Delphi 2009, with debug information enabled. But apparently they use different formats, because when I try to attach the VC++ debugger to my program, it says "binary was not built with debug information" and won't even accept as valid the breakpoints I put in the C code, which was built with debug info in the format VC++ understands.
Does anyone know how I can get this to work?
When you say "won't accept as valid" the debug breakpoints in the C code what do you mean exactly? Does it not enable them? If so has the DLL been loaded yet when you set the breakpoints? I find it can simplify matters if I wait to set the breakpoints until after I'm sure the DLL in question has been loaded. If this is not what is happening, please elaborate on what you mean by "valid" breakpoints.
Other options are to set function breakpoints, or the compile the DLL with strategically placed DebugBreak() calls.
Are you sure it's the right DLL that's being loaded (i.e. the debug version)?. Again, even the right DLL is being loaded I'm not sure the error is necessarily applying to the DLL and not just the main executable. Or it could be having problems loading the symbol database as suggested by jdigital, assuming you extract them out for debug builds of your DLL. Even with no debugging symbols, debugging should still be feasible, especially since it's a DLL, you can work from the exported symbols.
This isn't a COM component is it? If it is, I'd double check that the debug version was the one registered before you start up your process.
Again I'd still be interested in hearing exactly what happens when you try to set a break point. If you go to the breakpoints window in VS it should clarify why the breakpoint couldn't be set, if that's what is happening.
Hmm. I don't have much experience with /Z7, do you still have the .obj file for the DLL? The docs seem to imply that's necessary for debugging. Alternatively I'd try building with /Zi instead and getting a .pdb for that sucker.
Not sure about Visual C++ (don't have it installed at all anymore), but maybe this will help...
If you were writing a DLL in Delphi and using it from C++, and you wanted to debug the DLL, you'd open the source for the DLL in Delphi and set a breakpoint. You'd then use Run|Parameters and set the C++ application as the host executable and hit run in the Delphi IDE. The IDE would then launch the C++ application and run it as usual until the breakpoint in the DLL was hit, and then would break as you'd expect.
Is something similar available in VC++? (You didn't say which version of VC++, or which version of Visual Studio or the earlier IDE you were using.)
If not, the only alternative I could think of is to do a quick VC++ app that uses the DLL and debug via that instead.
Debug formats are not standardised - basically you can't use Delphi to debug MS compiled code or vice versa.
You can debug Delphi DLLs in Delphi and you can use those DLLs with other apps not compiled with Delphi, provided you mark the Delphi functions for export. What you can't do is debug those DLLs symbolically in a 3rd party debugger, which would have to understand Object Pascal name mangling at the very least.
Have you pointed the debugger at the symbols for your DLL? If there's any doubt, try running with Filemon to see if the debugger is failing when it tries to load the symbols.
Insure that is opening the DLL in the Debug Folder, not another one in some other folder.
Ten years later and this is happening to me, while debugging a custom DLL used in Team Developer, setting debugging command to start the Team Developer IDE. The objective is to step through the 3rd party code to the point of invocation of an exported function from the DLL.
Starting the debugger launches the IDE without error, but running the TD project within the TD IDE causes an exception in VS on a DLL used by the TD IDE.
How do I ignore the exceptions from outside the project? Has anyone been able to get around this since '09?