The following forum(s) have migrated to Microsoft Q&A (Preview): Developing Universal Windows apps!
Visit Microsoft Q&A (Preview) to post new questions.

Learn More

 locked
WinRT component works in C#, but not in C++ RRS feed

  • Question

  • I have a C# WinRT Component that works when I call it from C#, but now that I'm trying to call it from C++, it crashes.

    Exception thrown at 0x00007FFE5717A839 in Samples.exe: Microsoft C++ exception: Platform::COMException ^ at memory location 0x000000A7E9FFECC0. HRESULT:0x80131040 The text associated with this error code could not be found.
    WinRT information: The text associated with this error code could not be found.

    All it does is create DirectX device and resources.

    Edit:

    Also related is an additional issue - I cannot debug the runtime component when running the C++ app. See below for my efforts to get it working. I cannot either step into library code at execution time, nor can I even do things like 'Go To Definition' of a library function, as though Visual Studio can't see the runtime component at all. I don't have these issues when using the library from a C# project.
    Thursday, September 5, 2019 7:51 AM

All replies

  • Hi,

    Could you please tell me what kind of project you are using? Is it uwp?

    Best Regards,

    Jeanine Zhang

    Thursday, September 5, 2019 9:35 AM
  • Yes, the DirectX 11 template project is the Universal Windows one.

    Any suggestions about getting debug output or stepping into the WinRT component would help too. I'm not very experienced with C++ so I might be missing strategies to get to the bottom of what's wrong. For instance, can I force symbols to be associated/loaded for the WinRT component so that i can breakpoints in there?

    Thursday, September 5, 2019 10:01 AM
  • Hi,

    Do you mean when your DirectX 11 template project calls C# WinRT Component, it crashes? How did you call it from C++? Since this error has no way to locate what caused it, so can you please provide a simple that can be reproduced? In addition, about loading Symbol, you can refer to this document.

    Best Regards,

    Fay


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, September 6, 2019 5:54 AM
  • "How did you call it from C++?" - I think you're asking - how did I call the C# WinRT component from C++ ? Could you pls clarify because I don't think I understand. The straight forward answer is .. I called it like this ..

    1. I  included the reference for the C# WinRT Component.
    2. I declared that I was using the namespace for the class in the component.
    3. I called the constructor on the class.
    m_bitmap = ref new BitmapRenderer(); // << this fails
    I tried building the library in both debug and release with the same result.

    In regards to the symbol loading. I read this .. 

    "When you debug a project in the Visual Studio IDE, the debugger automatically loads symbol files that are located in the project folder."

    and ..

    "By default, if you have built a DLL or an .exe file on your computer, the linker places the full path and filename of the associated .pdb file in the DLL or .exe file. The debugger checks to see if the symbol file exists in that location."

    So according to that page you linked, I shouldn't have to do anything. Both the application and the library projects are in the same solution. And other libraries debug correctly, this is the first time I've had one of my libraries not debug - is it because it's a Windows Runtime Component library?

    Edit: I can provide the solution, but It'll have to be tomorrow, It's getting really late now.

    Note: I'm not actually using any of the DirectX stuff in the template - i just use that template because it sets up CoreWindow the way I want, and saves me a bit of work.

    Saturday, September 7, 2019 3:13 PM
  • 1) I enabled 'Managed and Native' debugging - but then I can't even set a breakpoint in native code and I still get the exception. So that setting seems to do the very opposite of what it's meant to do.

    2) I also tried disabling just my code to no effect.

    3) I enabled Microsoft Symbol Server - upon stepping into the code, I end up here ..

    namespace __winRT
    {
    	long __stdcall __getActivationFactoryByPCWSTR(void* str, ::Platform::Guid& pGuid, void** ppActivationFactory)
    	{
    		return GetActivationFactoryByPCWSTR(str, pGuid, ppActivationFactory);
    	} // <<< HERE
    }
    With the following output ..

    Exception thrown at 0x00007FFE5717A839 (KernelBase.dll) in AppCppCx.exe: 0x04242420 (parameters: 0x0000000031415927, 0x00007FFDD2940000, 0x00000062035FD490).
    Exception thrown at 0x00007FFE5717A839 in AppCppCx.exe: Microsoft C++ exception: EEFileLoadException at memory location 0x00000062035F9828.
    Exception thrown at 0x00007FFE5717A839 in AppCppCx.exe: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000.
    Exception thrown at 0x00007FFE5717A839 in AppCppCx.exe: Microsoft C++ exception: EEFileLoadException at memory location 0x00000062035F9828.
    Exception thrown at 0x00007FFE5717A839 in AppCppCx.exe: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000.
    Exception thrown at 0x00007FFE5717A839 in AppCppCx.exe: Microsoft C++ exception: EEFileLoadException at memory location 0x00000062035F9828.
    Exception thrown at 0x00007FFE5717A839 in AppCppCx.exe: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000.
    Exception thrown at 0x00007FFE5717A839 in AppCppCx.exe: Microsoft C++ exception: EEFileLoadException at memory location 0x00000062035F9828.
    Exception thrown at 0x00007FFE5717A839 in AppCppCx.exe: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000.
    Exception thrown at 0x00007FFE5717A839 in AppCppCx.exe: Microsoft C++ exception: EEFileLoadException at memory location 0x00000062035F9828.
    Exception thrown at 0x00007FFE5717A839 in AppCppCx.exe: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000.
    Exception thrown at 0x00007FFE5717A839 in AppCppCx.exe: Microsoft C++ exception: EEFileLoadException at memory location 0x00000062035F9828.
    Exception thrown at 0x00007FFE5717A839 in AppCppCx.exe: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000.
    Exception thrown at 0x00007FFE5717A839 in AppCppCx.exe: Microsoft C++ exception: EEFileLoadException at memory location 0x00000062035F9828.
    Exception thrown at 0x00007FFE5717A839 in AppCppCx.exe: Microsoft C++ exception: [rethrow] at memory location 0x0000000000000000.
    Exception thrown at 0x00007FFE5717A839 in AppCppCx.exe: Microsoft C++ exception: EEFileLoadException at memory location 0x00000062035F9828.
    onecore\com\combase\objact\dllcache.cxx(4713)\combase.dll!00007FFE590FE9F2: (caller: 00007FFE5901819A) ReturnHr(1)
    
    tid(510) 80131040 


    Then the next F11 step I end up here ...

    VCCORLIB_API __declspec(noreturn) inline void __stdcall __abi_WinRTraiseCOMException(long hr)
    {
    throw ::Platform::Details::ReCreateException(hr); // << Exception
    }


    With the following Exception (the one that i see without symbols loaded by the looks of it.

    Exception thrown at 0x00007FFE5717A839 in AppCppCx.exe: Microsoft C++ exception: Platform::COMException ^ at memory location 0x00000062035FEDE0. HRESULT:0x80131040 The text associated with this error code could not be found.
    WinRT information: The text associated with this error code could not be found.

    4) I used Tools > Import & Export Settings > Reset all settings - to no effect.

    Sunday, September 8, 2019 1:30 AM
  • Hi Fay,

    Here's a OneDrive share to the zipped solution.

    Shared Sln

    It contains ..

    AppCppCx - A C++/CX UWP application that uses WinRTComponentCS

    AppCS - A C# UWP application that uses WinRTComponentCS

    WinRTComponentCS - A C# Windows Runtime Component that uses SharpDX to create DirectX device + swapchain and clears swapchain to XNA's classic cornflower blue.

    You can see that the C# app (AppCS) runs and works, I can also step into the library. This is probably expected as both library and application are C# in this case. But when the C++ app (AppCppCx) is started, it fails to create the bitmapRenderer class and cannot step into the library.

    Edit: In fact, I can't even 'go to definition' in source. Instead the object browser is brought up. So the C++ project can't even see the library at all.





    Sunday, September 8, 2019 4:39 AM
  • Hi,

    Sorry for my delay. I will ask other engineers for help.

    Best Regards,

    Fay


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, September 11, 2019 2:48 AM
  • Hi Gavin,

    Were you able to find a solution for this? I'm able to reproduce the issue using a very simple sample app. If this is still a problem for you let me know and I'll investigate further. 

    Thanks,

    James


    Windows SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/

    Tuesday, October 1, 2019 12:48 AM
  • Hi James, I haven't found a solution, if you can work out what's going on it would be helpful.

    Just some comments for context ..
    SharpDX has been essential for me as I use C# primarily and need DirectX. But as SharpDX is a stale project now, I've been exploring how the runtime components work and looking into these mixed language solutions. I probably wouldn't be using C#/SharpDX as the renderer like I do in this example for the final product. I would think that C++/CX + DirectX would be used. But sorting this issue out would let me prototype some API's using C# and start thinking about the viability of the effort. Look, it's not holding me up, but it would help with my preparations for transitioning away from SharpDX to another solution. So if you can look at it, that would be great, but it's not an urgent matter.
    Monday, October 7, 2019 1:52 PM
  • Hi Gavin,

    No worries. This should work out of the box but is not. I'll take a look at it over the next couple of weeks and let you know what I find. 

    I know that SharpDX has been popular but keep in mind that it's not something that is supported by Microsoft. Not sure what you are doing but if you can get your implementation into C++ or a 3rd party game engine like Unreal or Unity you will probably be in better shape. 

    That said, I would also recommend that you check out the DirectX Toolkit. This lightweight wrapper around DX was written by one of our senior DX devs to make interacting directly with DX easier. 

    DirectX Toolkit

    https://github.com/Microsoft/DirectXTK12

    -James


    Windows SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/

    Monday, October 7, 2019 11:29 PM
  • I don't really agree that games should all be written in C++. C# with a DX wrapper is technically capable of producing most games out there. And the C# experience is preferable to C++.

    And the fact that Microsoft doesn't support managed DX is a sore point with indie game developers, has been since they dumped XNA. Microsoft's choice to not support MDX goes against it's 'C# is a first class language' claim. And it demonstrates a lack of commitment to game development, particularly non-AAA development. Unity is now heading to 40% ownership of the Windows game development ecosystem - that's not actually a good thing. There are now several efforts to replace SharpDX, this should be Microsoft's job, but anyway, at least we have some community members working on a solution (even a couple from MS are looking into C# DX solutions in their spare time).

    I think C++ is interesting but honestly, after a week of using it, I'm reminded of why I prefer C#. C++ is just a horrible language platform, it's antiquated, it's messy and has design concepts from every generation piled on top of the last. It's style is chaotic with every naming convention used under the sun, including all the worst ones. There is little intellisense or commenting like we get in C#. It has a string class for every occasion and they aren't even directly compatible. It uses headers in 2019! I always run into weird issues in VS with C++ where I get false positives for errors, and base.h always has errors in it, etc, etc.

    C++ is just a mess and it should be replaced with a cleaner language and library set (WinRT would do), without the standard library, without headers, modelled after the C# and .Net platform features, but with native C++ capabilities. I know C++ dev's think it's the bees knees, but there is a reason C# overtook it for application development on Windows. It's too late for C++, it can't be fixed now by piling more stuff onto it. At some point you have to cut off a dead limb, and the C++ community won't let that happen, so it will stay a mess till the end of it's day.

    I have tried a few times to give C++ a chance, but every time, I become frustrated with it's design and sub-par experience. I just keep returning to the C# game dev approach, because it feels like a breath of fresh air after using C++. Believe me, I've really tried giving C++ a chance, I continue to spend a little bit of time with it in the hopes that it just clicks once I learn to navigate it's dungeon like design. But I'm just so frustrated and disappointed in it. I've even tried employing a mixed language approach, and I may yet see some success with using C++/CX. I've tried C++/WinRT and I've come up against some real barriers, my experience was that it was a completely unusable platform in it's current format and functionality. 

    And that kinda brings me to this issue. Where I have to work out how to do interop because it's the only way to enjoy programming, by containing the C++ work to the least number of lines necessary to make the games that I want to make, and for the rest of the work use C#.


    Tuesday, October 8, 2019 3:52 AM
  • Just a quick note to verify that this appears to be a defect in the latest VS 2019 implimentation. I'm still not sure if it's a compiler problem or a Core CLR issue. I'm going to work with the VS team to see what we can do to address this. Thanks much for reporting it!

    Windows SDK Technologies - Microsoft Developer Services - http://blogs.msdn.com/mediasdkstuff/

    Friday, November 1, 2019 12:35 AM