none
CoCreateInstace Fails on Windows 7 but works on Windows 10 RRS feed

  • Question

  • My program running on Windows 10 64 bit on a Virtual machine has the three COM programs that work perfectly together.

    The Exact same software, registered in the exact same directory structure fails in Windows 7 64 bit with an 'ERROR ELEVATION REQUIRED'.

    The user in both systems are type Administrator.

    The system also works perfectly under Windows XP.

    This just doesn't make sense.

    Any ideas would be appreciated.

    Friday, August 24, 2018 4:31 PM

All replies

  • Does the problem surface on other Win 7 systems?
    Friday, August 24, 2018 4:39 PM
  • Update:

    This issue has been verified on two developer machines that are nearly identical. 

    The Windows Pro 64  in the lab runs the software with no problems.

    The biggest difference is that the Lab computer is not on the internet and hasn't been updated since 2015.



    Friday, August 24, 2018 4:40 PM
  • The Windows Pro 64  in the lab runs the software with no problems.
    The biggest difference is that the Lab computer is not on the internet and hasn't been updated since 2015.

    Sounds like you'll need to try getting a clean system working, then letting it update to see if something breaks it. Use  a VM with
    checkpoints along the way so that you can fairly easily step back to prior working states - assuming it is an update that breaks it.

    Dave

    Friday, August 24, 2018 7:54 PM
  • The thing that I noticed about Windows 10 is that the latest versions of utilities like regsvr32 will automatically elevate if you have UAC set to default settings. This didn't happen on Windows 7.

    One thing you can try, on a new, cleanly installed Windows 10 VM, before you do anything, set UAC to maximum.

    This will not allow the automatic elevation of some things like regsvr32.

    Try setting UAC to maximum, and then try registering and running that application again on Windows 10.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Friday, August 24, 2018 9:56 PM
  • Do the application manifests specify "requireAdministrator" or "highestAvailable"?
    Saturday, August 25, 2018 12:05 AM
  • The issue is with the connection to COM, not the registration.

    ie It doesn't try to change anything on the machine, just accesses the COM object.

    Changing the User Account Control in windows 7 (lower), or windows 10 (higher)  made no difference to the COM connection activity.(win 10 worked, win 7 did not)..running my app as administrator on windows 7 let's it work fine but I can't force my customers to do that.

    Tuesday, August 28, 2018 10:05 AM
  • Where would I find a manifest for a C++ COM object?
    Tuesday, August 28, 2018 10:06 AM
  • Where would I find a manifest for a C++ COM object?

    I understood your earlier reference to "three separate COM programs" to mean that you had 3 out-of-process servers implemented in .EXEs. 

    If this understanding is correct, then the manifests (if present) would be embedded in the resources of each .EXE and can be seen by opening the executable in Visual Studio and then viewing the resource under the RT_MANIFEST node.

    Tuesday, August 28, 2018 10:50 AM
  • In a C++ project for an out-of-process server you can also check the project properties at Configuration Properties->Linker->Manifest Files->UAC Execution Level
    Tuesday, August 28, 2018 10:57 AM
  • While I was using regsvr32 as an example, it was an example to say that "Windows allows this application to silently auto elevate now".

    If you notice, my post was only about changing the UAC level on Windows 10 (and only Windows 10) to see if the new behaviour was causing it to succeed when it should be failing, nothing more.

    I do also remember a few things about how updates to Windows 7 was causing COM activations to fail. Is it possible to get a plain Windows 7 SP1 with only the minimum requirements for your application to be installed? Obviously not connected to the internet.

    This is to test if perhaps one of the updates for Windows 7 is causing this.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    Tuesday, August 28, 2018 1:34 PM
  • Yes, I understood your premise.

    I raised the win 10 machine to its highest level, the app still worked fine.

    I went into my windows 7 machine and lowered the setting to its lowest setting, the App still failed.

    >> Update:  I have dropped back to a 2009 version that has been distributed since 2009. It has its own installer that registers everything.

    There has been no change in the fact that my machine cannot access COM objects without admin permissions while others can.

    The registrations look exactly the same via the OLE/COM Object Viewer.

    I have a plain Windows 7 Pro virtual machine that runs the app perfectly.

    I updated to SP1, everything still runs fine.

    I am in the process of updating windows 7 VM to post SP1 updates...it may be tomorrow before that's done.

    Our other developer dropped back to the 2009 version and it worked fine for him. That leaves the only issue with my computer...that I know of.  His machine is fully updated so I suspect the Win 7 VM exercise to be be moot. (We'll have to deal with his other issues later.)

    The question is down to:

    What can cause one Windows 7 machine to require admin privileges for COM objects?

    I looked at the Security Tab on the COM exe file and it looks exactly like the one on the Windows 10 machine. 

    Tuesday, August 28, 2018 3:38 PM
  • To put it quite simply, if different machines can run this with identical settings okay, but yours is the only one that fails, then the issue is software on your system.

    The only three things that can get in the way of this are:

    1) anti-malware

    2) the application

    3) Windows

    Since you stated that you have verified all of the settings for the applications are identical with known working versions then, by process of elimination, this leaves anti-malware and Windows.

    It is more common than you think that a Windows update will break something. A sysadmin friend of mine is constantly complaining about it. I also know that one of the last updates to the .NET framework broke .NET based COM components (and since I don't think you ever mentioned what you were using for the servers, this can't be ruled out). So a bad Windows update is more likely than you think. Oh, and the bad .NET update didn't affect Windows 10, only Windows 7.

    There are some components in Windows that Windows doesn't force you to keep up to date, so if you have updated one of these then it could be possible that this is getting in the way.

    There is also the final annoying thing that if your developer machine is old, then something could have gotten corrupted, and maybe a reimage/reinstall is the best option.


    This is a signature. Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

    • Proposed as answer by Baron Bi Thursday, September 6, 2018 2:26 AM
    Wednesday, August 29, 2018 1:02 AM