none
[UWP][Desktop Bridge]LoadLibrary failed in nested DLL RRS feed

  • Question

  • A LoadLibrary call was found failed in a slightly complicated situation. It was called by a DLL loaded by an exe using LoadLibrary, the exe was lauchend using CreateProcess by our main application. So the process is like this:

    Main App -(CreateProcess)-> Another.exe -(LoadLibrary)-> AnotherImp.dll -(LoadLibrary Failed)-> failed.dll

    What is confusing is that the same piece of LoadLibrary code is also called directly by the main app and it had run successfully.

    And the LoadLibrary is also called elsewhere in this specific calling link so it's not the API's problem.

    So we are guessing maybe it's a problem concerning security or privilege that maybe an operation like LoadLibrary will have some kind of limitation if it is called in a nested way?

    It's a mere guess. We don't know what the problem is.

    Anyone has any ideas? Would really appreciate it.

    Wednesday, December 28, 2016 2:13 AM

Answers

  • Hi Stak,

    So the Main app is the converted app. Where is the Another.exe? Have you put the dlls into your package by adding the dlls into the project as Content? I also wonder whether you uses the SetDllDirectory or AddDllDirectory API.
    “Your app calls SetDllDirectory or AddDllDirectory. These functions are not currently supported for converted apps. We are working on adding support in a future release. As a workaround, you can copy any .dlls you were locating using these functions to your package root.”
    https://msdn.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-prepare 

    Best Regards,
    David

    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.



    • Edited by David_FF Friday, December 30, 2016 10:38 AM
    • Marked as answer by Stak1945 Wednesday, January 4, 2017 7:06 AM
    Friday, December 30, 2016 10:21 AM

All replies

  • Hi Stak,

    To make the problem clear, could you please tell us what’s the relationship between your issue and Desktop Bridge? 

    Best Regards,
    David

    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.

    Thursday, December 29, 2016 4:32 PM
  • Hi David,

    Sorry for the incomplete information.

    This nested process of calling a Loadlibrary is only failed after converted to a UWP Appx using DesktopAppConverter, it works fine when it is only a normal Win32 App.

    As we are quite confusing about what the problem might be and don't have any clues yet, description of the problem may not be that clear. Sorry:(

    Friday, December 30, 2016 1:38 AM
  • Hi Stak,

    So the Main app is the converted app. Where is the Another.exe? Have you put the dlls into your package by adding the dlls into the project as Content? I also wonder whether you uses the SetDllDirectory or AddDllDirectory API.
    “Your app calls SetDllDirectory or AddDllDirectory. These functions are not currently supported for converted apps. We are working on adding support in a future release. As a workaround, you can copy any .dlls you were locating using these functions to your package root.”
    https://msdn.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-prepare 

    Best Regards,
    David

    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.



    • Edited by David_FF Friday, December 30, 2016 10:38 AM
    • Marked as answer by Stak1945 Wednesday, January 4, 2017 7:06 AM
    Friday, December 30, 2016 10:21 AM
  • Hi David,

    Thanks for your reply.

    The Another.exe and the other dlls mentioned are all included in the package, they are part of the converted app. I can see they are located in the right place of the Appx's install folder. We just don't understand why the "Loadlibrary" would fail, especially as it was executed successfully once by the Main app.

    Tuesday, January 3, 2017 7:00 AM
  • Hi David,

    Seems that the problem has something to do with the registry. After we fix the registry issue, thanks to your reply on another thread, this problem vanished too.

    So the loadlibrary is fine. There is nothing wrong with it:P

    Thank you.

    Wednesday, January 4, 2017 7:09 AM
  • Hi All,

    I also wonder whether you uses the SetDllDirectory or AddDllDirectory API.
    “Your app calls SetDllDirectory or AddDllDirectory. These functions are not currently supported for converted apps. We are working on adding support in a future release. As a workaround, you can copy any .dlls you were locating using these functions to your package root.”
    https://msdn.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-prepare 

    Best Regards,
    David

    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.




    AddDllDirectory and SetDllDirectory functions are supported in the Project Centennial App after the RS2(1703 release).

    Thanks,
    Fang Peng


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    Thursday, November 30, 2017 6:40 AM
    Owner