2

I used to have the ability to inspect shaders in Visual Studio 2012, but now I've lost it. The UI doesn't actually crash, but the modeless popup message saying "This may take a few minutes" never bears fruit. I found a post at another site claiming that installing VS2012 Update 3 fixed the problem, but that hasn't helped in my case.

Back when using Pix was an option, I found that rendering outside of a BeginPaint() / EndPaint() pair for speed would cause debugging issues, but again that hasn't been the issue this time.

More info: There is a warning message initially, "Debugging information for 'YourApp.exe' cannot be found or does not match. No native symbols in symbol file". This is as I'd expect, as the main app is managed, with the DirectX work being handled via an unmanaged engine DLL that loads slightly later (once I know what bit version to use).

tombola
  • 165
  • 12
  • Can you provide more details on what exactly you are doing to start debugging shader (what buttons/commands from starting an IDE), what you expect to see and what you see in real. Does your application works fine without debugger attached? (Launch executable directly) Do you use BeginPaint()/EndPaint() in current project? Why? It's not DirectX functions. – Ivan Aksamentov - Drop Jul 03 '13 at 10:54
  • The app itself is running fine with and without the debugger. The Begin/End Paint calls were essentially legacy code, as at one point the engine was GDI-based. I'm using Debug / Graphics / Start Diagnostics, and capturing via Print Screen. The debugger displays the render and event list normally, but any attempt to click on a shader, in the pipeline view, pixel history etc, just results in the wait message churning away forever, so the expected listing of a shader never appears. The rest of the UI isn't hung, just obscured by the message. – tombola Jul 03 '13 at 12:17
  • Hm, looks like you doing all things right. Try to comment all drawing code, make a fake Draw() call and click on it in event list. To check if it is your code or not issue, try debug any other (DirectX samples) or simply write your own test. Less plausible, but maybe helps: On device creation do you pass any flags other than `D3D11_CREATE_DEVICE_DEBUG`? Does your shaders compiled with debug info? Did you installed graphics drivers recently (try to rollback)? Do you receiving any warnings from D3D11 debug layer in Output window? – Ivan Aksamentov - Drop Jul 03 '13 at 12:41
  • I'm still investigating these ideas, but SDK samples ARE debuggable. There is one debug layer warning that comes up a few times, `D3D11 WARNING: ID3D11Buffer::SetPrivateData: Existing private data of same name with different size found! [ STATE_SETTING WARNING #55: SETPRIVATEDATA_CHANGINGPARAMS]`. This is caused by setting debug names for resources. – tombola Jul 03 '13 at 16:10
  • My own experience: SETPRIVATEDATA_CHANGINGPARAMS is not dangerous itself, but it can point to serious hidden design mistake or code flow bug: you naming resource multiple times, but most times you want do this only once, after creation. So, where is it happening second time? And does creation happens second time too? And something else? Maybe its a key. I think you must dig into functions call graph to see if code flows in a way you not expected. – Ivan Aksamentov - Drop Jul 03 '13 at 17:07
  • The renaming turned out to be benign (and is now gone!), but selective commenting out has narrowed the problem down to a small and inoffensive enough lump of code to give Microsoft some debug logs to analyze, so we'll see where that goes... – tombola Jul 04 '13 at 14:30

3 Answers3

1

Tombola, I'm a developer on the Graphics Debugger in Visual Studio. As you've seen 2013 preview added some big stability and scaling improvements to the Graphics Debugger. What you were probably seeing before was a playback engine crash while attempting to start shader debugging. The Graphics Debugger tool shipped with some stability issues in VS 2012, but since then Update 2 and now VS2013 (RTM should also improve quite a bit over preview) have helped this issues greatly.

Ian Huff
  • 2,699
  • 1
  • 17
  • 17
0

Have you tried debugging the first draw call in the frame?

The further down the frame, the more DirectX calls that are made before the shader executes, the longer the debugger takes to start; it can take a really long time for a complex scene.

If even the first draw call fails to start debugging, perhaps try commenting out code to reduce the number of API calls and see if there is a particular operation which causes the problem.

gareththegeek
  • 2,362
  • 22
  • 34
  • The first draw won't debug. For that matter, It won't even drill into calls near the top of the event list like CreateVertexShader(). Those bring up a similar a "Collecting object data. This may take a few minutes" message that goes nowhere. – tombola Jul 03 '13 at 11:57
0

It turns out that VS2013 preview can debug all the shaders in VS2012 .vsglog files without difficulty (nb. express build lacks auto and watch windows for shaders). This requires Windows 8.1 preview of course. Setting these two up inside a dedicated virtual machine for safety costs about 8 gig (32 bit, VirtualBox).

tombola
  • 165
  • 12