locked
DCOM got error "2148007941" from the computer testwin7desktop when attempting to activate the server RRS feed

  • Question

  • Hello,
    I have a Windows 32-bit DCOM application that I am trying to test on Windows 7 64 bit. The application has client and server. It works fine when both are on single machine. Of the two windows 7 machines that I am using, one is Enterprise version and other is Professional version of Windows 7. The client from professional version can connect to the server on Enterprise version. But the client from Enterprise version cannot connect to the server on professional version. I get the error mentioned in the subject in the Event Viewer. Here is what I have tried or setup:
    1. I tested DCOM communication between the two windows 7 machine using this tool from Microsoft and it works fine in both directions (W7 Professional to W7 Enterprise and vice versa). That is in both directions, it can do a read and write operation.
    2. The DCOM server has the proper permissions granted for remote access and launch.
    3. On both machines, I am logged on using the same domain user which has the permission to remotely launch the server.
    4. Windows Firewall, defender, antivirus firewall are disabled on both machines.
    5. When connecting from the client on W7 Enterprise version to W7 Proff. version, I get the error mentioned on the subject on the W7 Enterprise machine. At the same time, W7 Professional machine gives the error "The server {} did not register with DCOM within the required timeout"
    6. I tried making the application run in XP SP3 mode. The client does not run in this mode on the W7 Proff. machine but works on W7 Enterprise machine. The client gives an error and closes.
    7. I ran "sfc" utility to check the integrity of systems files on both machines and it did not find any issues.
    Any help in this regard will be appreciated.
    Thanks!
    Monday, June 13, 2011 8:18 PM

All replies

  • Hi,

    Thanks for the post!

    What kind of this DCOM application you tested? Self-developped?

    Please heck your DCOM configuration in Component Services.

    Refer to this similar error about this DPM agent: http://blogs.technet.com/b/askcore/archive/2008/05/09/troubleshooting-agent-deployment-in-data-protection-manager-2007-dcom.aspx 

    Hope this will give you some hints.

    Regards,

    Miya  


    This posting is provided "AS IS" with no warranties, and confers no rights. | Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Thursday, June 16, 2011 8:12 AM
  • Hi Miya,

    Thanks for the response and the link. I checked the DCOM config on both Windows 7 machines and it is identical and correct as per the link. Also checked registry permissions as per the recommendations. Still have the issue. The client on Windows 7 Professional can connect to the server on Windows 7 Enterprise but not the other way around.

    The DCOM application I am testing was developed by our team around 2005 and has been working well on 32 bit windows. We are trying to see if it works on 64 bit OS and this is where I am having this issue.

    Since I have exhausted trying all I could find and know, I am getting Windows professional installed on the other machine. So then I will have two Windows 7 professional (64 bit) machines to test on. Just want to check if this is an issue between Windows 7 Prof. and Windows 7 Enterprise.

    Will keep you posted on how that goes.

    Thanks,

    ELN

    Monday, June 20, 2011 10:20 PM
  • Using Windows 7 Professional on both machines did not help.The communication did not work in either direction.(Note: It used to work from the Win 7 Prof to Win 7 Enterprise but not the other way). Since most of the clients use Windows 7 Professional, we are not testing with Win 7 Enterprise on both machines.

    Does anyone know of any issues with DCOM on Windows 7 Professional?

    Thanks,

    ELN

    Tuesday, June 28, 2011 5:03 PM