DLL fails to load if unused ref class is removed RRS feed

  • Question

  • I'm running into a very strange problem trying to compile and use a windows runtime component within an UWP application (VS2017 community 15.9.13 with NetCore.UniversalWindowsPlatform 6.2.8, compiled without /clr but with /ZW).

    It is basically something like the GrayscaleTransform found in the UWP samples. The runtime component is actually working as expected, now I wanted to remove some unused code. However, as soon as I remove it from a particular file and recompile, it indeed compiles, links, but the DLL does not load any more.

    Here's some example code that I have to put in:

    ref class DummyU sealed {
      public:	DummyU() {}
    DummyU^ CreateDummyU() {	
      return ref new DummyU();

    The code just makes it work, although it is a) not referenced at all and b) does not do anything useful. 

    The result of removing it:

    Exception thrown at 0x0EFF322F (vccorlib140d_app.dll) in TestAppUWP.exe: 0xC0000005: Access violation reading location 0x00000000.


    STDAPI DllGetActivationFactory(_In_ HSTRING activatibleClassId, _Deref_out_ IActivationFactory** ppFactory) {
    	return Platform::Details::GetActivationFactory(Microsoft::WRL::Details::ModuleBase::module_, activatibleClassId, ppFactory);

    function in dllexports.cpp which is part of VS. The module_ becomes NULL.

    Does anyone have an idea if there are any known bugs with respect to the windows runtime not being initialized/used properly if there is no explicit instantiation of a ref class in a file?

    Monday, July 1, 2019 9:30 PM

All replies

  • Hi,
    Can you show more codes about how you call the component in the UWP application and implement the component(Before and after removing)?That will be better for us to understand the scenario.
    Best regards,
    Tuesday, July 2, 2019 6:17 AM
  • Here is the link to the full source. Just clone, restore nuget packages and compile. It should work, but once you remove lines 113ff in VizarioMediaStream.cpp, it breaks...

    Tuesday, July 2, 2019 6:58 AM
  • ...However, as soon as I remove it from a particular file and recompile, it indeed compiles, links, but the DLL does not load any more.
    ...The code just makes it work, although it is a) not referenced at all and b) does not do anything useful. 

    Can you reproduce this issue with a minimal example solution using the latest VS preview?

    If you don't get any reply here that answers your question in the next day or so, I'd recommend that you use that example and report
    it to MS using the VS Report a Problem facility to see what they say about it.


    Tuesday, July 2, 2019 8:35 AM
  • well the problem is that this is already kind of a minimal example. It is basically a source and a sink mostly taken from UWP samples, and there is not much that can be stripped from that...

    BTW, it is the same with Visual Studio 2019 latest...

    PS: ok, I stripped the Sink completely, just having source and the test app and that reproduces the problem...

    Tuesday, July 2, 2019 9:04 AM
  • Hi,

    According to the document,it says a public ref class or ref struct is emitted in metadata, but to be usable from other Universal Windows Platform apps and Windows Runtime components it must have at least one public or protected constructor. A public ref class that has a public constructor must also be declared as sealed to prevent further derivation through the application binary interface (ABI).So it seems you can't remove the related code.

    Best regards,


    Tuesday, July 2, 2019 10:01 AM
  • Yes I know all of that, but you missed the point - this part of the code is not related to anything at all.

    I don't need this class, nor do I use this class, nor do I want to access it. There is no reason for its existence at all. However, some arbitrary ref class has to exist in this file for some unknown reason to make the runtime component work. This does not make any sense to me... you can try to rename it to some other name, add functionality, whatever... all of that is possible although having no influence or meaning whatsoever, as long as you don't remove it - then it breaks.

    The only reason I could make up (and that is a bug) is that when the compiler looks at the file it infers some properties/flags for compilation automatically that are different if a ref class is found or not (enabling some special CLI compilation or disabling it???). However, to me this is at the same level as adding a "for(int i = 1; i < 100; i++) printf("hello");" just to add some code that does not make any sense... btw, adding a for loop does not help ;-) 


    someone on stackoverflow suggested to replace the ref class with

    struct ModuleStaticInitialize
    static ModuleStaticInitialize s_moduleInit;

    and this indeed works, however, it still seems to be a bug in the compiler or the windows runtime after all...

    Tuesday, July 2, 2019 12:38 PM
  • Hi,

    If you want to make your component usable by UWP,you should declare your own ref class.If you still want to remove the DummyU class,you can try to change one class has existed in Vizario.MediaSource project to ref class and initialize it.

    Best regards,


    Wednesday, July 3, 2019 7:10 AM
  • Hi,

    Does @fay's reply make sense?

    Best regards,


    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

    Friday, July 12, 2019 6:13 AM