7 replies to this topic

[bilandra]

Hey guys,

So this is a little tricky for me, as I am unable to replicate the problem, can't log, etc.

An IT guy at a school is trying to set up our program in a lab, and is running into an error that a dll is not registered properly. Our tech support helped him to install the program while logged in as an administrator, the DLL registers fine, and the program works fine. Logging in as a user, the program generates the error the DLL is not registered properly, and the program won't launch.

Our tech support tried to manually register the dll, with regsvr32.exe. He gets an error that the module was loaded, but the call to DllRegisterServer failed with error code 0x80020009.

Does all COM registration require admin privileges? Any reasons why the DLL would register fine for admin, and not all users?

Tips? Ideas on where to look?

Thank you!!!

[Stefan Krueger]

0x80020009 means exception error. Apaprently your DLL crashes while registering.

Registering a COM server means writing information to the registrey. Theoretically, there are two places where this data can be put:

• under HKEY_LOCAL_MACHINE, in this case the information is available to all users, but this requires admin privileges
• under HKEY_CURRENT_USER, this does not require admin privileges, but then the information exists only for the user who registered the DLL, so other users can't use it

So you probably want the first option, which means that instalaltion requires admin rights (which are also required to place files in the Program Files directory)

[andyguest13]

Hi,
I am using InstallShield 2008 Premier v14 and having similar problems.

What i am doing is bundling a whole Java Runtime with my app - JRE 1.6 actually. I need to allow end-user installation as non-admin and that works apart from trouble writing to the Registry.

IS detects various DLLs, EXEs in the 3rd party JRE and therefore tries to extract COM data at some point since i have COM extract at buildtime selected:

~~~~~~~~~~
New ProgId ieplugin.JQSIEStartDetectorImpl dynamically acquired for component jqs_plugin.dll
New ProgId ieplugin.JQSIEStartDetectorImpl.1 dynamically acquired for component jqs_plugin.dll
New ProgId JavaWebStart.isInstalled dynamically acquired for component wsdetect.dll
New ProgId JavaWebStart.isInstalled.1.6.0.0 dynamically acquired for component wsdetect.dll
New Class {E7E6F031-17CE-4C07-BC86-EABFE594F69C} dynamically acquired for component jqs_plugin.dll
New Class {5852F5ED-8BF4-11D4-A245-0080C6F74284} dynamically acquired for component wsdetect.dll
New AppId {E311BFF9-7280-40D3-AE0B-2D3651C37EC8} dynamically acquired for component jqs_plugin.dll
New Registry Entries (4) dynamically acquired for component deployJava1.dll
New Registry Entries (17) dynamically acquired for component jqs_plugin.dll
New Registry Entries (1) dynamically acquired for component npjpi160_32.dll
New Registry Entries (1) dynamically acquired for component npoji610.dll
New Registry Entries (14) dynamically acquired for component wsdetect.dll
~~~~~~~~~~~~~~~~


The errors running the install as USER, with COM extract at buildtime are:

~~~~~~~~~~
Error 1406.Could not write value to key \SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects\{E7E6F031-17CE-4C07-BC86-EABFE594F69C}. System error . Verify that you have sufficient access to that key, or contact your support personnel.
Error 1406.Could not write value NoExplorer to key \SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects\{E7E6F031-17CE-4C07-BC86-EABFE594F69C}. System error . Verify that you have sufficient access to that key, or contact your support personnel.
~~~~~~~~~~~

If i dynamically link the whoel JRE bundle, i can set SELF-REGISTER for all files. But that is even worse at runtime as Java itself launches and encounters policy problems.

What i want is simply to copy the JRE to the user's machine, and that's it. No writing to the Registry for any of the COM in the JRE. That's taken care of when java.exe is invoked later. So no COM extraction at build, and no Self-Registration - just treat all the exe and dlls as plain old files to be merely copied across.


thanks,
Andy

[Stefan Krueger]

Have you tried switching self registration off for those files?
Or include the java installer as a whole exe inntead of separate files?
Or don't include it as files to install, but run it as a prerequisite?

[andyguest13]

I have tried self-registration turned off, but as far as i can see even if it is off, IS will still extract COM info etc - either at build time, or at the time files are added. I can't see how, in the IS UI, to completely turn off COM extraction. IS either does it for you before installation, or MSIEXEC does it at runtime. Is that correct?

The app I am distributing for our company is a Java one consisting of a few .jars together with a .exe launcher program (on Windows, anyway). The launcher basically does a ShellExecute of java.exe with params set correctly to launch my app. We know that the app works correctly with only certain JRE versions hence why we wish to use a private one. The java app loads pretty quickly like this and doesn't overwrite/affect any other JRE the user might have installed.

I have considered bundling the install package for JRE as a .exe; however then that might affect the user's Java environment he already has and would incur the installation cost of a JRE even if only once. Ditto for a prerequisite i think?

I suppose i could dig into the direct editor and stop any unwanted registry behaviour for certain components but that is tedious and error prone

thanks
andy

[andyguest13]

PS. Java 6 runtime needs admin privileges for installation, so that's not an option for me.

I guess a kludge might be to physically rename all the JRE exe and Dll files in the source folder to say .exez and .dllz so that InstallShield doesn't regard them as files with COM data, and then have a CA at the backend of the install which renames them to the originals in the target folder. This might be alright as far as Oracle license agreement which says files should be unmodified? they are only modified while in the InstallShield CAB...

[Stefan Krueger]

When you go to Component view an select the compoent:

• Is "COM Extract at Build" set to "no"?
• Expand the "Advanced Settings" folder of the component. Select "COM Registration". There you can see and edit/delete the extracted data.

[andyguest13]

Thanks Stefan, this does the trick.

I found that also, to make life easier as i have many files to deal with, that if i go into the DirectEditor Component table, sort on the ISAttribute column, and replace all the ISAttribute values from 20 to 17, that more easily changes COM Extract at build to "no" and i can be certain i've captured them all.

andy

Edited by andyguest13, 06 March 2013 - 11:39.