none
In DCOMCnfg "Run application on this computer" is grayed out for my application on two Windows 7 machines, but it works fine on all other machines

    Question

  • We have a COM application that is installed on hundreds of machines around the country.  We have instructions included in our install doc of how to set up DCOMCnfg.  On one machine in the field and one machine in our lab (both happen to be Windows 7 machines) the checkbox "Run application on this computer" on the location tab in DCOMCnfg is grayed out and therefore we cannot access our engine remotely.

    I turned off UAC before installing  (we found that the install works much better than way)  and it is actually still off.  I do not get any DCOM errors in the Windows Event logs when I try to access via DCOM, I just get the standard -2147023174 Server Error.  I have added CallFailureLoggingLevel to HKLM\Software\Microsoft\OLE and set it to 1 to enable logging, but still no errors in the event logs.

    I pulled a DCOMTest utility off of the Microsoft site.  Initially it failed, but there were entries in the event logs indicating that it did not have the permissions it needed.  I opened up those permissions and now that test utility works fine.  So, DCOM is functioning between the two computers.

    This application is used with DCOM by hundreds of people, so I know the application should be working properly.  I have uninstalled and reinstalled to verify that everything is registered properly.  I have tried turning off the firewall and the anti-virus.  I am logged in as an administrator

    I am at a loss.  Any ideas?

    Thanks
    Thursday, February 11, 2010 1:28 AM

Answers

  •  

    Hi,

     

    This issue can occur if the current user profile does not have enough permission or related system file is corrupted. Please try the following steps to troubleshoot the issue.

     

    1. Assure the current user account has administrator permission. If not, please add it to Administrators Group and then test the issue again.

     

    2. Restart the machine in Safe Mode and logon to the machine with the account: administrator. Then, please check whether the option is grayed out.

     

    3. If the option is still grayed out, please try this step.

     

    a. Open C:\Windows\System32 folder and change the ownership of the ComUID.dll file from "trusted installer" to administrators group.

     

    b. Rename that file as ComUID.dll.org

     

    c. Copy the attached ComUID.dl_ file from the Windows 7 installation disk to C:\Windows\System32 folder and rename it to ComUID.dll

     

     

    Thanks,

    Novak

    • Marked as answer by Novak Wu Monday, February 22, 2010 1:28 AM
    Wednesday, February 17, 2010 1:58 AM

All replies

  •  

    Hi,

     

    This issue can occur if the current user profile does not have enough permission or related system file is corrupted. Please try the following steps to troubleshoot the issue.

     

    1. Assure the current user account has administrator permission. If not, please add it to Administrators Group and then test the issue again.

     

    2. Restart the machine in Safe Mode and logon to the machine with the account: administrator. Then, please check whether the option is grayed out.

     

    3. If the option is still grayed out, please try this step.

     

    a. Open C:\Windows\System32 folder and change the ownership of the ComUID.dll file from "trusted installer" to administrators group.

     

    b. Rename that file as ComUID.dll.org

     

    c. Copy the attached ComUID.dl_ file from the Windows 7 installation disk to C:\Windows\System32 folder and rename it to ComUID.dll

     

     

    Thanks,

    Novak

    • Marked as answer by Novak Wu Monday, February 22, 2010 1:28 AM
    Wednesday, February 17, 2010 1:58 AM
  • Hi Novak,

    This happens on windows 7 and server 2008 r2 on new machines with fresh installs from my action pack subscription.

    Both systems are 64 bit editions.

    I have logged in as the administrator.

    I took ownership of comuid.dll and administrators has full control of it.

    Then I run dcomcnfg and the problem still occurs and the option remains grayed out.

    Have you reproduced this and verified your solution with an exe server?

    To reproduce this, please look at my 3rd post on:

    http://social.technet.microsoft.com/Forums/en/winservergen/thread/1f56775d-155d-4f6f-9827-3dc29e44a06e

    I have reproduced this with virtual servers and stand-alone installations, as domain member computers and as a workgroup stations.

    This seems to be more of a policy restriction.  I would appreciate your comments.

    Thanks,

    CRCR

     

     

     

     

    • Proposed as answer by CrCr Wednesday, June 09, 2010 1:58 PM
    Wednesday, June 09, 2010 11:08 AM
  • Sorry, accicentally hit propose as answer.  The answer is still pending from someone.

    Please provide a button to allow removing the "proposed answer" indicator.
    Wednesday, June 09, 2010 6:39 PM
  • Finally.... After installing windows 7 - 32 bit and seeing that DcomCnfg worked led me to believe that the problem was 64 bit related.  So I googled DcomCnfg 64 bit and found:

    http://msdn.microsoft.com/en-us/library/ms678426(VS.85).aspx

    "Dcomcnfg.exe and 64-bit Applications
    On x64 operating systems from Windows XP to Windows Server 2008, the 64-bit version of DCOMCNFG.EXE does not correctly configure 32-bit DCOM applications for remote activation. This behavior causes components that are meant to be activated remotely instead being activated locally. This behavior does not occur in Windows 7 and Windows Server 2008 R2 and higher versions.

    The workaround is to use the 32-bit version of DCOMCNFG. Run the 32-bit version of mmc.exe and load the 32-bit version of the Component Services snap-in by using the following command line.

    C:\WINDOWS\SysWOW64>mmc comexp.msc /32

    The 32-bit version of Component Services correctly registers 32-bit DCOM applications for remote activation."

    My suspicions were confirmed, although the article incorrectly has the sub-title: "Dcomcnfg.exe and 64-bit Applications"

    The 64 bit version of DCOMCNFG does NOT work!   The 32 bit version of DCOMCNFG does work.

    I immediately tested this on Windows 7 - 64 bit:   Start -> Run -> mmc comexp.msc /32

    Then going to my 32 bit ATL exe component under DCOM Config -> properties -> location tab.  All check boxes were available, none were grey.   Furthermore the previously greyed unchecked "Run application on this computer" was now checked and available!  Imagine that, previously shown unchecked and not editable, now shown correctly using the 32 bit version of DcomCnfg!

    It is disappointing that the article says "This behavior does not occur in Windows 7 and Windows Server 2008 R2 and higher versions."  Hello?   Does anybody test this stuff?  Clearly this statement in the article is false.

    Anyway.... the solution to bad DcomCnfg behavior under 64 - bit Windows OS's is to use the 32 bit version of DcomCnfg.

    Start -> Run -> mmc comexp.msc /32

    --------------------------------------------

    Now for the forum.... a person who proposes the "answer" should not be able to mark their own suggestion as "the" answer.  Mr. Wu marked his response as such and it was NOT the answer and it wasted my time and probably the time of many others.

     

     

    • Proposed as answer by CrCr Saturday, June 12, 2010 12:27 AM
    Friday, June 11, 2010 3:27 PM
  • Hi CrCr,

    I am going through a same issue. "Run application on this computer" is grayed out on one of my application dcom component's property. As mentioned by you, i tried opening up the dcomcnfg in 32 bit, but "run application on this computer was already enabled" for me in 32 bit dcomcnfg. But it is not reflecting in 64bit dcomcnfg. Could you please help me on this?

     

    Wednesday, August 11, 2010 9:05 PM
  • Hi Dhina,

    64 bit DcomCnfg does not work to configure 32 bit components.  You must use:

    Start -> Run -> mmc comexp.msc /32

    and then your components can be configured properly.

    Please dont waste your time trying to get the 64 bit version to work.

    All will run fine when configured using the 32 bit version.

     

    Wednesday, August 25, 2010 6:47 PM
  • Really thankful to you i ve been searching foor the solution on 64 bit windows 2008 R2 since long and your above answer resolve the issue

    thanks a lot

    • Proposed as answer by Devang Patel Tuesday, June 10, 2014 6:03 PM
    Tuesday, June 10, 2014 6:02 PM