none
Mixed dlls loading error using Remote Desktop RRS feed

  • Question

  • Hi,

    I have a problem with loading mixed dlls using Remote Desktop. My application is native C++ application with dependency to a dll (both x64) which were compiled with /clr compiler flag (VS Pro 2008). Within this dll .Net code is used. During installation of this application on a server (Windows Server 2003 SP2 x64) using Remote Desktop, I noticed that something went wrong, I got an MessageBox with the following error:

    ---------------------------
    .....exe - Application Error
    ---------------------------
    The application failed to initialize properly (0xc0000005). Click on OK to terminate the application.
    ---------------------------
    OK  
    ---------------------------

    The curios thing is that I can call my application on my machine (WinXp x64 SP2) without any problems. So I checked the application with the dependency walker, everything fine - no missing refrenced dll. It took me a while until I recognized that this error was related to the Remote Desktop session (mstsc /console), because as I tried to install the same application on my machine via Remote Desktop, I got the same error.

    So I tried to install the application using pcAnywhere and evertyhing is working fine. After a research google/bing about this behaviour, I saw that already some guys had the same problem but unfortuanetly they didn't receive any answer, e.g. <http://www.keyongtech.com/2881516-application-failed-to-initialize-properly>

    Additional I checked  the loaded modules with ProcessExplorer and I saw that using RDP leads to load a lot more dlls, e.g. Winsta.dll as described in the previous link.

    Consclusion:

    Status Quo: Application with mixed dlls

    Situation 1: Installation using RDP (mstsc /console) fails (reproducable) -> The application failed to initialize properly (0xc0000005). Click on OK to terminate the application

    Situation 2: Installation using pcAnywhere works without any problems

     

    Does anybody have a clue why is this happening? Could winsta.dll couse this behaviour, if yes how can I avoid it?

     

    I spent the last four days to figure out the reason for that, without any success.

    Any help is appreciated!

     

    Thanks

    Tuesday, June 15, 2010 2:34 PM

All replies

  • Hi, 

     

    Sorry for replying so late.

     

    It sounds to be not a CLR issue since the error dialog appears at installation period. I tried to reproduce this issue by creating a C++ application ( which include some /clr dlls), and creating a setup project to generate .msi package. but I succeed installing the application on another machine via window remote desktop.

     

    Anyway, General Windows Development Issues forum maybe a better place for this issue.


    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Friday, June 18, 2010 8:58 AM
  • Hi,

    we have the same/a similar issue. The scenario is like the one described above. Plain C app that uses functionality provided by a managed code dll (all 32 bit).

    We actually never tried to install our solution via RDP, but we used RDP to stop/start services that we installed previously. We noticed that when re-starting services the exes would not run if we connect to the remote box via mstsc /ADMIN or mstsc /CONSOLE. Via mstsc (without switch) it would work.
    The error message that we get when trying to run the exe from the command line is exactly the same as mentioned by Don Vittorio.
    When logging on locally/physically to the box, the error does not occur. Also one of our partners tried to connect to the remote box via VNC and everything was fine in this case too.

    Any hints are very welcome.

    Thanks and Regards,
    Michael

     

     

     

    Tuesday, June 22, 2010 7:31 AM
  • Hi,

     

    thanks for your answer. As Muchinger already described, I am also using a service which has an own installation function, see code snippet below. The application in this case a service, is not using msi packages for deployment. I also have the same problems as Muchinger to start and stop the service.

     

    ******BEGIN CODE SNIPPET****************

    schSCManager = OpenSCManager(
                            NULL,                   // machine (NULL == local)
                            NULL,                   // database (NULL == default)
                            SC_MANAGER_ALL_ACCESS   // access required
                            );

     

        char   *serviceDependencyTable[] = { "\0\0" };

    if ( schSCManager )
        {
            schService = CreateService(
                schSCManager,               // SCManager database
                service_name,                                // name of service
                service_name,                                // name to display
                SERVICE_ALL_ACCESS,         // desired access
                SERVICE_WIN32_OWN_PROCESS,  // service type
                SERVICE_DEMAND_START,       // start type
                SERVICE_ERROR_NORMAL,       // error control type
                szPath,                     // service's binary
                NULL,                       // no load ordering group
                NULL,                       // no tag identifier
                serviceDependencyTable[0],  // dependencies
                NULL,                       // LocalSystem account
                NULL);                      // no password

            if ( schService )
            {
                CloseServiceHandle(schService);
            }

            CloseServiceHandle(schSCManager)

    ******END CODE SNIPPET****************

     

    Does anybody have an idea why a native C++ service which has dependencies to managed dlls fails to register at the SCM and to start or stop the service afterwards using RDP? As a workaround I can install the service using "sc create" but afterwards I cannot start or stop the service using RDP.

     

    I can reproduce this behaviour on a Win XP SP2 x64 and on Windows Server 2003 x64 SP2 box.

     

    Every help is appreciated!

     

    Thanks

    Tuesday, June 22, 2010 8:53 AM
  • Hi,

     

    no idea? Does anybody have a clue why loading mixed dlls using RDP fails? Maybe someone has a similiar problem...

     

    Thanks

    Tuesday, June 29, 2010 6:24 AM
  • Hi Don,

    Could you please follow the article http://support.microsoft.com/default.aspx/kb/286350 to capture the dump file of the crashing application.

    After you get the dump, please let me know your email address by sending a mail to v-eryang@microsoft.com. Then I will create a file transfer workspace where you can upload your dump file. The dump will be kept confidential.


    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Wednesday, June 30, 2010 2:45 AM
  • Hi Eric,

    thanks for your reply. I will let you know as soon as I have created the dump file.

     

    Regards,

    Viktor

    Wednesday, June 30, 2010 1:12 PM
  • Don,

    we are using ADPlus for getting crash dumps already, but we attach ADPlus to running processes. However in our case the processes do not come up, so I would not know how to attach ADPlus. We introduced log statements at the very beginning of the startup code. None were written.

    So to me it seems that the processes do not come up at all - not even a "tiny bit" :)  Something must be there to prevent them from being run.

    Also it is not constantly reproducible. We have computers where this problem can be reproduced, others instead behave fine. How bizarre ...

    Regards,
    Michael

    Friday, July 2, 2010 11:57 AM
  • You may let adplus to attach a process automatically when the given process started, with command "adplus -crash -pmn MyProcessName -o d:\".
    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Monday, July 5, 2010 3:12 AM
  • Hi,

    How things going, did you get the crash dump?


    Sincerely,
    Eric
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Wednesday, July 7, 2010 8:41 AM
  • Hi all,

     

    sorry for the late reply. I didn't get the time to create the dump files. I hope I can get some time next week.

    @Eric, I will let you know as soon as I have the dump files, hopefully next week.

    @Michael, have you tried Erics suggestion to attach adplus automatically to a process?

     

    ok guys, I will keep you uptodate.

     

    Nice weekend.

     

    Viktor

    Friday, July 9, 2010 1:24 PM
  • Hi all,

    I was able to attach ADPlus to the process. I get 2 dumps both pointing into ntdll.dll. I specified the MS symbol server in VS and those are the call stacks that I get

    Dump with 1st chance exception
    ntdll.dll!_KiIntSystemCall@0()  + 0x6 bytes 
    ntdll.dll!_NtDelayExecution@8()  + 0xc bytes 
    ntdll.dll!__LdrpInitialize@12()  - 0x1b0b9 bytes 
    ntdll.dll!_KiUserApcDispatcher@16()  + 0x25 bytes

    Dump with 2nd chance exception
    ntdll.dll!__LdrpInitialize@12()  + 0x19b1f bytes
    ntdll.dll!_KiUserApcDispatcher@16()  + 0x25 bytes

    Hope this helps.

    Best,
    Michael

     

    Thursday, July 15, 2010 9:22 AM
  • I just finished wrestling with this myself - it appears to be a bug in the process of statically linking to a managed dll from unmanaged code.  One way of avoiding the problem would be to switch from static linking to dynamic linking - it worked for me.  Of course this might be inconvenient to implement if your DLL has a large number of functions and/or is used from a large number of places within the program.

    An alternate possible solution that I found online, but did not test, would be to put a managed wrapper around your WinMain, as described here: http://stackoverflow.com/questions/2364497/unmanaged-c-program-that-statically-links-to-a-managed-dll-load-failure.  I did not test this solution, but if switching to dynamic linking would be a widespread change this might be cleaner/easier if it works.

    Friday, July 16, 2010 8:49 PM