I have a UWP cppwinrt app that is using directx12 to render a cube with a basic shader. I would like to use a graphics debugger to inspect the data being sent to this shader.
First I am trying to use the Nvidia Nsight debugger for visual studio 2017. The problem is that when I go to "Start Graphics Debugging" from the Nsight menu, the app immediately stop with an error saying: "Failed to launch UWP app (Could not terminate existing process)".
I am able to launch the Nsight debugger on a DirectX12 UWP app (C++/CX) created from the visual studio template though which is encouraging.
My cppWinRT app is rendering to a swapchain created using IDXGIFactory2::CreateSwapChainForComposition like so:
check_hresult(
m_factory->CreateSwapChainForComposition(
m_commandQueue.get(),
&swapChainDesc,
nullptr,
m_swapChain.put()
));
// associate DXGI swap chain with the XAML SwapChainPanel
check_hresult(
swapChainPanel().as<ISwapChainPanelNative>()->SetSwapChain(m_swapChain.get())
);
The swapChainPanel() is a winrt::Windows::UI::Xaml::Controls::SwapChainPanel xaml control.
Does anyone have an idea how this could be done?
UPDATE 8/13/2018:
I tried using Nsight with a different project from Microsoft that is very similar to mine, which you can find here: https://github.com/Microsoft/DirectX-Graphics-Samples/tree/feature_xaml_template/Templates/DirectX12XamlApp
It has the exact same problem as my project so it seems like the swapChainPanel XAML control is the problem.
I suspect that a possible workaround would be to present using a different swapchain when debugging, such as one created with IDXGIFactory2::CreateSwapChainForCoreWindow instead.
Related
I am trying to integrate WPF into a legacy MFC application. I am unable to include the /clr switch to mix managed and unmanaged due to the restrictions of other projects in the solution. I need the WPF window open up as a child window in the main MFC application. I have been investigating different ways for the past two weeks but have hit roadblock with every implementation try. If anyone has successfully integrated this type of implementation, I would appreciate some direction. I have been able to integrate with a Win32 app, but could not translate this to an MFC app. Thanks everyone.
I believe that WPF requires .NET, therefore what you need is to create a separate DLL or EXE for the WPF parts. hat new project could be the container for .NET code and your main MFC would launch this separate project.
You can write a WPF front end that launches C++ apps with the desired command like switches, similar to what Visual Studio 2010 is doing to compile your code and show the results in the output pane. In this way you can avoid having to hack message loop code to support both frameworks .
You may show your Dialog using a COM interface
Is there a way to debug Visual Studio or Blend so I can figure out where XAML designer load errors come from in my code?
The stack traces are often useless.
Thanks...
Use two VS2010 instances. Load one with your main app probject or a test harness application project and load the other with your controls project. Having built the controls project reference the debug dlls in your other project. Debugging from the VS2010 instance holding the controls project attach to the VS2010 instance holding the test application.
Place your break points as you like.
Now drive the test application instance of VS2010 as you would when building yout controls into an application, when your controls are load their code will execute and you can start stepping the code. You can do a similar thing when working with your controls in Blend just attach to the Blend instance.
In VS, first go to Debug->Exceptions and check the box for "Thrown" for CLR Exceptions. This will break into the debugger for exceptions caught by the Blend/VS app. Then do Debug->Attach To Process... and find the instance of Blend or devenv that has your solution open. Once the debugger starts up you can open the XAML file in the designer and debug against it.
Here are another two cents. Just make sure that the Options->Debugging->General->Enable Just My Code is unchecked in the instance you are using to attach to the designer's process.
I found both answers useful. Just adding my 2 cents - In the VS copy that you're using to attach to the designer, I needed to select the code type manually (Managed, v4.0 in my example) in the Attach To Process dialog to get the desired result. For some reason the default for devenv was Script, T-SQL. Looking at the date of the OP and original answers, it may be that an update to VS caused this change... just speculating.
I am trying to use WPFPerf to profile a WPF 4.0 application (I have the latest WPFPerf that should work on WPF 4.0 aps). I start the tool Visual Profiler from WPFPerf, I start my aplication, but after that nothing happens and the element tree from the Visual Profiler is empty. No other error message is shown. Can anyone tell me what am I not doint right?
As an additional information, when I try to analize my .exe assembly or any other assembly from my application, I get a BadFormatException saying that the assembly was build with a newer version of .NET. From the download page http://go.microsoft.com/fwlink/?LinkID=191420
I see that this version of WPFPerf should be ok for my app
TimeZone patch to WPF Performance Profiling Tools for WPF 4 is now available
http://blogs.msdn.com/b/jgoldb/archive/2010/08/24/timezone-patch-to-wpf-performance-profiling-tools-for-wpf-4-is-now-available.aspx
First check to see if its working even with a small blank WPF application. If it is not working with a blank WPF app, then it likely is the patch already mentioned: TimeZone patch to WPF Performance Profiling Tools for WPF 4 is now available
However, in my case that wasn't the issue. Visual Profiler has a bug that causes it not to display the Element tree if it doesn't like some of the characters in its main window title bar.
Through hours of trial and error, I was able to trace the root cause of why it would not work on our application even though it would on a blank WPF application. The reason is that our application has a special character in the title bar text (trademark). If we eliminate the special character from the main window title, the element tree shows fine when the visual profiler is attached. I was able to reproduce this issue in the simple blank WPF application too simply by putting the following property on the main window:
<Window ..... Title="Test Application™" >
Looks like a bug in Visual Profiler that somehow is triggered by special characters. I didn't test for other special characters, but likely it isn't just this one.
So the workaround is to remove the special character while you are profiling until they fix this.
I am compiling a Winforms app for use with Mono and using the .Net stuff built into Visual Studio 2008 for a Winforms app. Everything works fine, but I'd like to run without the terminal window opening.
Do I need to use gmcs to get this line to work:
-target:winexe
as seen here? Or can I do it with the built-in commands that Visual Studio uses for .Net?
In VS, make sure the project type is set to "Windows Application" and not "Console Application" on the project properties page.
If that doesn't fix it, try using monow.exe instead of mono.exe to run the application.
I used the shader templates given through Greg Schechter's blog: http://blogs.msdn.com/greg_schechter/archive/2008/08/11/a-visualstudio-buildtask-and-project-and-item-templates-for-writing-shadereffects.aspx
It was all simple to add the wpf shader templates and create the project. I'm also able to see that the shader is working through the visual studio 2008 designer when editing my xaml. But I get this error when I run my program:
Cannot find type 'ShaderEffectLibrary1.Effect1'. The assembly used when compiling might be different than that used when loading and the type is missing.
Make sure your top level project (for the GUI) also has a reference to the ShaderEffectLibrary. I ran across a similar problem today where I was referencing a third-party library from within my WPF user control library. It built fine, but then I would receive a similar exception at execution time. It turned out that adding a reference to the third-party library from the top level project resolved the exception.