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.
Related
I'd like to build a keyboard layout that runs on Win7 and later without using MSKLC.
I downloaded the Keyboard Layout Samples, and although it says it requires VS2013 Preview and WDK8.1 Preview, it builds using VS2012 and WDK8 after changing the "Platform Toolset" property from "WindowsApplicationForDrivers8.1" to "WindowsApplicationForDrivers8.0".
But: Checking the kbdus.dll built with Dependency Viewer reveals that it imports quite a lot of stuff from kernel32.dlland from msvcr110.dll. This is in contrast to kbdus.dll from the Windows\system32 directory, which, as one might expect, does not import anything and exports one single function.
My first question: Is it an issues that the dll built imports from msvcr110.dll?
I guess it is, as Win7 does not include this dll. (Honestly, I'm wondering how this can be, because these are official Microsoft samples.)
Tweaking around with compiler and linker settings, I managed to get rid of imports from msvcr110.dll, but the dll built still imports a lot of stuff and is quite large (> 70kB), compared to the original kbdus.dll (7kB). It's the same with x86 and x64, Debug and Release builds. I'm looking for the /compileandlinkanddonothingfancy switch.
My second question: How can these dlls be built correctly?
(Note: I found this question, but it is about WDK7. That will be what I try next, if I don't get it with WDK8.0)
I think one should pass /noentry to the linker.
I have much trouble compiling OpenCV 245 with GPU support. With some effort I managed to have cuda support up and running, but now I am stuck on opencl, here is the problem:
At some point during the compilation, the file kernels.cpp is generated, containing all kernel functions as strings. For what I understand, they are converted automatically from the .cl files with the cl2cpp.cmake script.
What I don't understand is that one file is excluded from the build: nonfree_surf.cl (which is on my disk, alongside all other .cl files) is not included, either in the visual studio project, or in the kernels.cpp that is automatically generated. This leads to an undefined error at link time.
I have tried manually adding the nonfree_surf.cl to the visual studio project. This does not change anything. In the CMakeLists.txt for ocl module, all the cl files seem to be automatically added with the line:
file(GLOB CL_FILES "${CMAKE_CURRENT_SOURCE_DIR}/src/kernels/*.cl")
I have tried manually adding nonfree_surf to CL_FILES, with no effect.
I have very little knowledge of CMake, hence I don't understand well what is going on. Can somebody give me a clue how I could find the reason of this behavior, namely:
Why are all .cl files added to my VS project, except nonfree_surf.cl ?
How can I correct this ?
Maybe I can execute cl2cpp.cmake script manually ? If so, how ?
Managed it by manually running the script:
cmake -DOUTPUT_PATH=c:/opencv/kernels2.cpp -DCL_DIR:PATH=c:/opencv/modules/ocl/src/kernels -P "c:\opencv\modules\ocl\cl2cpp.cmake"
For some reason (probably the same that makes nonfree_surf not be processed), not every necessary function are processed this way, so I juste copy-pasted the nonfree_surf string into kernels.cpp, and proceeded with the build.
If anyone needs the binaries, since they are a pain to compile, here they are:
Opencv 2.4.5 binaries compiled with VS2010 x86 (WIN32) including ocl and gpu library.
I don't know if many of you tried the new excellent feature of Visual Studio 2012 to debug Direct3D based apps.
I successfully capture a frame of my app, then I want to debug the execution of a Vertex Shader:
I click on the green triangle to debug a given vertex, but I got a "No Symbol Found" message which prevent me to debug it.
Someone knows what to do for Visual Studio to find the symbols?
Thanks.
You need to compile your shaders with debug information. And in order to reliably debug, you likely will want to disable optimizations as well. Depending on how you compile your shaders, this will be one of two ways:
D3DCompile / D3DCompileFromFile: Pass the D3DCOMPILE_DEBUG and D3DCOMPILE_SKIP_OPTIMIZATION flags to D3DCompile. Note that depending on D3D version and whether you are using D3DX, these flags might have different prefixes.
fxc.exe: The compile flags have switch equivalents. For D3DCOMPILE_DEBUG, pass /Zi to fxc. For D3DCOMPILE_SKIP_OPTIMIZATION, pass /Od.
Visual Studio 2012 is fairly smart about finding the source for your shaders based on the embedded debug information, but should it fail to do this, it will prompt you to point to the appropriate file.
From msdn:
It's not possible to debug an app and its shader code at the same time. However, you can alternate between them
It's possible that you are debugging the application and trying to debug shader at the same time.
When using SlimDX you can pass ShaderFlags to the shader compiler. Passing ShaderFlags.Debug causes debug symbols to be included.
var bytecode = ShaderBytecode.CompileFromFile("shader.fx", "VShader", "vs_4_0", ShaderFlags.Debug, EffectFlags.None)
Hopefully it is something similar in native Direct3D.
I was able to debug shaders in VS2012.
I used this command line:
fxc /TTargetProfile /EShaderMainFunctionName /Od /Zi /FdMyShader.pdb MyShaderFile
In code, I used:
D3DX11CompileFromFile(filename, NULL, NULL, "ShaderMainFunctionName, "TargetProfile", D3D10_SHADER_DEBUG | D3D10_SHADER_SKIP_OPTIMIZATION, ...);
TargetProfile is something like vs_5_0 or ps_5_0.
I'm pretty sure it would work with D3DCompile.
When I forgot to put D3D10_SHADER_DEBUG | D3D10_SHADER_SKIP_OPTIMIZATION, and I tried to load the pdb file manually, it said the symbols didn't match.
When I got it right, the Pixel Shader in the Pixel History view was a blue link. When I clicked it, it automatically loaded the correct file and I could start debugging it.
I couldn't find an in-code equivalend to /Fd that generated the pdb file, which is why I had to go through command line.
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"!
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?