VB6/Vista (or maybe Inno) problem Run-time error ‘339’

I have a VB6 application developed under Vista 32-bit. Compiled with the Inno set-up compiler, it installs and runs correctly as administrator. When I login as another user (without admin privileges), it loads and starts then crashes out with:

Run-time error ‘339’;
Component ‘Comdlg32.ocx’ or one of its dependencies not correctly registered: a file is missing or invalid.

Did I screw up the Inno setup?
Is there an Inno Flag that I should have set?
… or is it something else again? :rolleyes:

TIA
Dave

As the error message says, the file is not registered. The "normal" user has no privilege in System32 folder and can't search in there.
So, you should instruct Inno to register the comdlg32.ocx file, in order to update the registry and give the non-admin users the ability to load the file.

Thread Moved

Did you install it under All Users or Single User?

Is Comdlg32.ocx installed to the System32 directory or did you install it to your app.path or some other directory?

provide a manifest with your exe to run as invoker:
<ms_asmv2:requestedExecutionLevel
level="asInvoker"

Quote:

---

Originally Posted by RobDog888

Did you install it under All Users or Single User?

---

Whatever the Inno default is(?) ... I can’t see a way of specifying. I personally find the Inno documentation quite, er, difficult to navigate. :)

Quote:

---

Originally Posted by RobDog888

Is Comdlg32.ocx installed to the System32 directory or did you install it to your app.path or some other directory?

---

Definitely Sytem32

Quote:

---

Originally Posted by isnoend07

provide a manifest with your exe to run as invoker:
<ms_asmv2:requestedExecutionLevel
level="asInvoker"

---

Sorry, I’ve absolutely no idea what that means. :confused:

ATB
Dave

I use Inno Setup, too.

This is a line of one of my program's setup script:

Code:

---

Source: "C:\Windows\SysWOW64\COMDLG32.OCX"; DestDir: "{sys}"; CopyMode: alwaysskipifsameorolder; Flags: restartreplace sharedfile regserver

---

The highlighted word, regserver, instructs Inno Setup to call regsvr32.

Can you verify it in your script?

Quote:

---

Source: "C:\Windows\System32\Comdlg32.ocx"; DestDir: "{sys}"; Permissions: everyone-modify; Flags: sharedfile regserver

---

I have to add the “Permissions: everyone-modify;” bit to make it work for users without admin privileges; without the Permissions bit the app. throws an error. A similar thing with the “[Registry]” section to make that work – otherwise the app will read from but not write to the Registry.

To recap: If I install the setup on a spare PC then, if I have admin privileges, it runs correctly. If I login as (say) the Guest user then it throw errors. Liberally sprinkling the “Permissions: everyone-modify;” in the Inno setup allows the application to run correctly for the Guest account too.

I’m obviously missing something fairly fundamental here. People write applications for users without administrative privileges all the time, don’t they?

ATB
Dave

Quote:

---

Originally Posted by Harry's Lad

To recap: If I install the setup on a spare PC then, if I have admin privileges, it runs correctly. If I login as (say) the Guest user then it throw errors. Liberally sprinkling the “Permissions: everyone-modify;” in the Inno setup allows the application to run correctly for the Guest account too.

---

Yeah, I've noticed that using the P&D Wizard to create the setup package then install it on the guest account. One would think guests shouldn't allow to install software/mods on a system though.

Edit:

It does show the administrator password box when go to install under "guest" so that you have to enter an admin password before continuing to install the software. Although, I am surprised that it doesn't just show a message saying something like "You are a guest! Installation can not continue.".

I'm guessing that you got away with doing a lot of "fast and loose" things on pre-Vista operating systems. Either the users were always running under admin accounts or else directories such as System32 and Program Files were left with Full Access more or less for Everyone.

Lots of "funny" things may have been happening, such as components being registered in HKCU instead of HKLM when regsvr32 or the equivalent was being done.

Windows NT was never quite the same as Windows 9x, but beginning with Windows 2000 a few new wrinkles were added to program installation. That's when things such as per-user COM registration was introduced. Things probably don't work as you think they do if you have a Windows 9x background and then moved directly to Windows XP and have been letting it apply app compat remediations behind your back since then.

"If I Could Turn Back Time"

The "legacy scripted installer" technologies like the PDW or this Inno thing only work by dint of several layers of crufty Application Compatibility introduced at various times: Vista, XP, 2000. These are really meant to help users get by with old Win9x software on the later operating systems.

Starting back in 1998 Microsoft began making the move away from the old setup API and scripted installs. Office 2000 was the first general-release Microsoft product to use the new installer technology, though Installer became available earlier than that for back-installing into NT 4.0, 95, and 98. Today it would be a rare system that doesn't have Installer in place, even a Windows 95 system.

Vista Tries

Vista takes this a step further. Programs are intended to normally be installed by a service known as TrustedInstaller, which has registry and filesystem rights that not even an admin user running elevated has.

If the user installs an Installer package (normally a .MSI file) the associated program MSIEXEC is run. MSIEXEC examines properties in its command line and the MSI file to determine whether a per-user or per-machine install has been requested. For a per-machine install MSIEXEC hands the installation over to TrustedInstaller after a successful UAC approval. If the user is an admin, he can simply allow the operation. If not, UAC prompts for "over the shoulder" admin user credentials before proceeding - i.e. the admin reaches around you and types in his user/pw.

Vista examines every attempt to run a program for possible legacy setups. The EXE file name is checked for key words like "setup" and "installer" and "update" and other things like the file's extended property values ("file description" and so on). There are EXE file "signatures" checked for well-known legacy installers like the PDW setup.exe (Inno is most likely not in this list).

If Vista determines that a program run request is for a legacy setup after this consulting of tea leaves and rolling the dice it requests elevation via UAC prompt and turns the requested process over to TrustedInstaller to run it. If the setup EXE fails the tests it gets run as a normal process. Since legacy installers have no real concept of a per-user install and indeed think they have the run of the system, there are good odds something won't be done correctly. At a minimum the program will probably be installed into a virtualized location instead of into Programs (the new name for Program Files). COM registration can get even weirder.

Trying To Fake Out Vista

I have seen posts that indicate either late Inno versions can insert an application manifest requesting elevation, or perhaps some users are using some hack to embed one into the EXE produced by Inno. I hesitate to think of the consequences, but it must more or less work often enough for them to keep doing this. The install will not be done by TrustedInstaller so the odds are there will be glitches, especially on a Vista64 system.

VB6 Installer Support

Back in late 1998 the PDW was replaced for VB6 users by Visual Studio Installer 1.0, and this was soon replaced by Visual Studio Installer 1.1 in 2000. Frankly this is what you ought to be using now. It has a basic VB6 Setup Wizard but to use VSI properly you need to know a bit more about it. There are excellent 3rd party packagers which expose more Installer functionality to the package author as well.

There is an old tutorial on this at Create installations with Visual Studio Installer.

You were supposed to stop using COM self-registration (regsvr32, et al.) for installs back when Windows 2000 came out. See SelfReg Table:

Quote:

---

Installation package authors are strongly advised against using self registration. Instead they should register modules by authoring one or more tables provided by the installer for this purpose. For more information, see Registry Tables Group. Many of the benefits of having a central installer service are lost with self registration because self-registration routines tend to hide critical configuration information.

---

Windows 7 and Per-User Installation

Windows 7 contains Installer 5.0, which enhances per-user installs. The intent is to make it even easier for users without admin rights or an admin over their shoulder to install applications on a single user (not global) basis. The new part is the ability to do this using a single MSI instead of having both a per-machine MSI and a per-user MSI to ship.

Per-user installs can also be done under earlier versions of Installer (before Windows 7) though there are a few possible glitches in the areas of COM registration and file location that will require care.

Of course this requires you use Installer packaging.

On Windows XP, Vista, and Windows 7 you can use registration-free COM to make more successful per-user installer packages for VB6 programs. You first create and embed the necessary manifest(s) and then package as a per-user MSI. You package using VSI 1.1, but it requires some post-build tweaking of the resulting MSI file. The process is much easier using some of the more advanced 3rd party packages from the big names, and some of those will even create your manifests.

InstallSite - Software and Support for Setup Developers is a good resource for these sorts of things. As far as I know it is independent of any vendor.

How Does This Help Me?

This is old information, I agree. Most of it was published back during the Vista Beta program in 2006.

The key point is that there are limitations when using legacy setups. The most common one is running afoul of registry or filesystem virtualization. In this case it almost sounds as if your setup is blindly doing a self-reg on Comdlg32.ocx, and ending up registering it in your admin user's virtualized copy of HKLM. So not only isn't the library registered per-machine, it isn't even registered per-user for this admn user.

It's been registered in the "let's jolly this old boy along" part of your admin user's HKCU hive instead.

Using an "asInvoker" manifest will tell Vista "don't play with me, I understand the rules of the road." Well if you do this you'd better be sure you do! It may well work but it is far from the correct thing to be doing. It also won't work properly if a non-admin user runs your setup. I hate to think of the chaos if a non-admin user runs it on a Vista64 system, but even then WOW64 virtualization might still apply and things could work out.

Hi Dilettante,
Thanks for your detailed explanation and the links. Unfortunately, it raises many more questions …
1) Is Visual Studio Installer 1.1 really what I should be using … even with Vista? I’ve had bad experiences in the past with PDW - developing on 98se and subsequently damaging XP systems.
2) Having downloaded and installed VSI 1.1 from MSDN … what is the executable called and where did the installer put it? (Why do MS do that? If I can’t find it then I can’t use it.)
3) Would a later version be more appropriate? … bearing in mind that I want to make per-machine installs. If so, where can I get it.
4) Is there anything wrong with using HKCU (rather than HKLM) for data storage? I’ve traditionally used HKLM but, after realising that VB6’s GetSetting, etc., uses HKCU I use that instead. Could you point me at some learned source that can educate me in such matters?

I’ve just installed my bodged (resorting to the "Permissions: everyone-modify" mechanism) Inno-generated setup on my wife’s Vista 64-Bit PC with no apparent problems at all – the app executes correctly under both Admin and Guest accounts – but I’d really like to sort this out.

ATB
Dave

I think the setup should be run with administrator privileges (right-click -> run as admin).
Mine does it by default. My setup's manifest contains the instruction level=asInvoker and asks for the administrator's permission to run it (windows shows the "protection shield" on the icon, too).
I've never had a problem running my programs, even under a non-admin user on XP.

Quote:

---

Originally Posted by Cube8

I think the setup should be run with administrator privileges (right-click -> run as admin).
Mine does it by default. My setup's manifest contains the instruction level=asInvoker and asks for the administrator's permission to run it (windows shows the "protection shield" on the icon, too).
I've never had a problem running my programs, even under a non-admin user on XP.

---

Hi Cube8,
I’m confused (doesn’t take much :) ). Does your post relate to the Inno setup compiler? Tell me more about manifests – I seem to have a gaping chasm in my knowledge here …

TIA
Dave

Inno setup automatically adds the manifest to the compiled setup.exe. Normally, there is nothing to configure.

Do you have the latest version?

Quote:

---

Originally Posted by Cube8

Inno setup automatically adds the manifest to the compiled setup.exe. Normally, there is nothing to configure.

---

Where is this manifest though; is it something I need to create? Is it a text file? What’s in it? Can you show me an example?
See, manifests really are unknown entity to me … sorry to be so obtuse. :o

Quote:

---

Originally Posted by Cube8

Do you have the latest version?

---

My Inno Set Compiler is version 5.3.5.

ATB
Dave

I have 5.2.3.
I just noticed another config-line in inno setup script:

Quote:

---

PrivilegesRequired=admin

---

There is no option to configure the manifest. Inno compiler does it.

If a program under Windows XP or later has a manifest a number of things can be specified there. Manifests were meant to replace the my.exe.local files that Windows 2000 and Me tried to use to specify DLL/COM Redirection, which never did work out well and was not meant to be used with VB6 programs and never VB6-created DLLs or OCXs.

Quote:

---

Note In Visual Basic there is currently no easy way for developers to write inherently side-by-side ActiveX controls. This is because the registration of Visual Basic-authored ActiveX controls writes the fully qualified path to the OCX file into the registry when the control is registered.

---

There are three kinds of manifests: Application Manifests, Assembly Manifests, and ClickOnce Deployment Manifests. All of these are XML documents, and the last one really only applies to .Net programs for the most part.

One of the things an Application Manifest can specify is which version of the Windows Common Controls to use. This is the typical way programs try to get the "XP Styles" look for many controls.

Manifest fragment:

Code:

---

<description>Your app description here</description>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            processorArchitecture="X86"
            publicKeyToken="6595b64144ccf1df"
            language="*"
        />
    </dependentAssembly>
</dependency>

---

When Vista came along the Application Manifest was extended to cover several additional things, most notably via the <requestedExecutionLevel> element. A valid <requestedExecutionLevel> can tell Windows whether your program runs with the invoking user's rights, with admin rights, or with the highest rights available to the invoking user himself.

It is also an implicit statement to Vista that your program is "Vista aware." This means that Vista should not try to apply appcompat shims to your program, which it will do if your program doesn't have a <requestedExecutionLevel> element in a manifest. These shims are plentiful, the most common being registry and filesystem virtualization. Another important one is legacy installer detection.

Sample elevation manifest from MSDN, don't try to use this as-is:

Code:

---

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity version="1.0.0.0"
    processorArchitecture="X86"
    name="IsUserAdmin"
    type="win32"/>
  <description>Description of your application</description>
  <!-- Identify the application security requirements. -->
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel
          level="requireAdministrator"
          uiAccess="false"/>
        </requestedPrivileges>
      </security>
  </trustInfo>
</assembly>

---

Windows 7 will be extending the manifest further, with new attributes.


A simple Application Manifest can either be an XML file named my.exe,manifest or a resource embedded in the EXE having Type=24 and Name=1. Resources with these sorts of binary Type/Name values can't be added using the VB6 IDE's Resource Editor as far as I know. People often use a resource hacking utility, or a special utility meant just for manifest embedding. Someone might have an IDE add-in for this as well, I don't know.


If Inno is indeed producing a setup EXE with an elevation manifest (an Application manifest where <requestedExecutionlevel level="requireAdministrator">) then users are in for a world of hurt.

This not only tells Vista to require admin credentials, it also says the setup EXE is Vista-aware... which it is not! You bypass legacy installer detection, so the setup EXE ends up running as a regular admin user instead of under TrustedInstaller. The consequences can be subtle, and perhaps frustrating. However if the Inno authors are persisting along this course it must mostly work much of the time (sort of, kind of). Er, except when it doesn't!

None of that does anything about providing your program itself with a manifest of any kind.


You're asking a lot of questions. Are you trying to go from Windows 95 development to Vista overnight? Ouch.

The PDW setups work fine, because they'll be detected as legacy installers and for the most part will do just what they need to. If you had problems in the past trashing systems with a PDW-generated setup... you were not using it correctly. A lot has changed in Windows since the 95/98 era. There are hundreds of MS KB articles on properly using the PDW in the modern era. Most of these address various "Don'ts" which mostly describe dependencies you are not supposed to be deploying.

The PDW has a file called VB6DEP.INI which contais a section named [Do Not Redistribute]. You are responsible for updating this over time with new exclusions, and you might find you need two or more different VB6DEP.INI files you have to swap out as you package for older or newer systems. You can get by with a single VB6DEP.INI for the most part as long as a few oddball DLLs and handled manually each time you package with the PDW: a few DLLs need to be deployed to Win9x systems, but cannot be deployed to WinNT systems (NT 4.0, 2000, XP, etc.).


Hkey_Current_User is for per-user settings. Since Windows 2000 it is possible to register COM libraries in HKCU as well. Anything in a user's HKCU will not be seen by other users.


There is no later version of VSI 6.0 than version 1.1, so you can't "use a later version." What you might do is look at 3rd party package authoring tools that respect Windows Installer. Inno is not one of these. There is an open-source set of tools collectively called WiX but I suspect they'll give you a heart attack.

VSI 1.1 is old, just slightly younger than VB6 itself. This means to stay competitive on later versions of Windows you can't just use these tools as blindly as you may have under Win9x.

After installing VSI 1.1 you should be able to find it in the Start Menu under:

Code:

---

Microsoft Visual Studio 6.0
    Microsoft Visual Studio 6.0 Enterprise Tools

---

It is really just part of the cost of doing business in VB6. Have you considered a later version of VB.Net sch as 2005 or 2008 instead? The Express editions are pretty much worthless in terms of deployment tools. Even Standard Edition should offer a newer version of Visual Studio Installer that has been tweaked to be "friendly" to C# and VB.Net programmers.

Not really all that much has changed over the elapsed time. In my case, searching for Installers via Dr Google never came close to a match on Dilettante's suggestion but a bump on this thread for relevance.