cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
DemonPiggies
Level 7

Vista only issue after upgrade to 2010...

I am receiving three (3) errors on a Vista system...

1. During Installation:
The following error occurred on the file 'C:\...\CTL3D32.DLL'.


2. After installation:

The Following files did not self-register or unregister:
1. C:\Windows\system32\Oleaut32.dll
Access is denied.

2. C:\Program Files\Common Files\Microsoft Shared\Dao\DAO350.DLL
Error accessing the OLE registry.


So it all boils down to a few specific questions:
[LIST=1]
  • Has anyone had any issues converting from an older version of InstallShield to 2010 and recieved similar errors?

  • After researching (for the past few hours) I keep reading about how there are different versions of CTL3D32.DLL for Windows 95 and NT (NT needing a different version). Is this true for Vista too, does Vista need it's own version?


    The installation (using this installshield version, 2010) works fine on Windows XP but throws the above errors whenever someone installs on Vista. The last version of InstallShield that was used was able to create a Vista installer but since converting we are unable to get past this error. I keep reading about how there are different versions that are OS specific so I am at a loss here on this. Also I am unsure if this issue is caused by the DLL versions...

    The only change I have made since the conversion is to add a string to the 'product version' area under the 'General' section.

    Any help is greatly appreciated! And please realize that I have inherited (was hired to replace someone) and am fairly new to this process/position so please bear with me... Thank you...
  • Labels (1)
    0 Kudos
    (6) Replies
    DemonPiggies
    Level 7

    So if anyway for prosperity I figured I would share me find with the world:

    After some more digging I found that there are certain files that in Vista are completely locked (meaning that they are cannot be overwritten). The product I work on included these DLLs because it used to support older versions of Windows. In the case of 3D control "CTL3D32.DLL" you CANNOT overwrite this file even in administrator mode. There are perhaps ways of getting around this but this is unnecessary since these DLLs have not changed since 98se (the versions shown in the properties menu remain the same).

    I came upon a very good explanation Here.

    So now I'm stuck at how to NOT install these files for a Vista (or Windows 7) box but allow them to be registered for older windows. Is there an easy solution that I may have overlooked?
    0 Kudos
    DemonPiggies
    Level 7

    Though at this point there is no reason for me to do this but:

    I moved the XP only DLLs to their own component and used the options on the features to only install on certain OSs...

    Thought the issue was more the "Why suddenly is this happening on 2010 and not IS6?"
    0 Kudos
    joshstechnij
    Level 10 Flexeran
    Level 10 Flexeran

    You're probably only seeing this issue with newer versions of InstallShield because all built setup.exe's contain an application manifest, which turns off a number of application compatibility shims in the OS (the manifest indicates to the OS that the EXE being launched is more or less compatible with the OS). Since the setup.exe's built with IS Pro 6 didn't contain an application manifest, Windows would have turned on a number of app compat shims that would have made it look like the registration of these files succeeded, when in fact, the registration was silently blocked and a success status was returned by the OS.

    Moving these files to components that only install on older operating systems would be the best practice for resolving this issue.
    0 Kudos
    DemonPiggies
    Level 7

    Then how would we update system components that need updating? Wait for Microsoft to patch it? I'm just wondering because of the DLLs and OCX's we need are version specific.
    0 Kudos
    joshstechnij
    Level 10 Flexeran
    Level 10 Flexeran

    The file replacement mechanisms are documented in the following MSDN article:
    Supported Resource Replacement Mechanisms

    Basically, only operating system mechanisms are privileged enough to update protected resources. This functionality was added to prevent applications from overwriting system files with incompatible versions of these files.
    0 Kudos
    DemonPiggies
    Level 7

    Thank you, I appreciate the response. Now I can tell my boss that this wasn't something I did!
    0 Kudos