View Full Version : Error 1406 during installation depending on which user built the installer

11-21-2018, 05:06 PM
I am looking for help in finding and clearing the source of this error.

I am seeing a strange error in the installations that I build. The error pops up on screen requiring the user to select Abort, Retry, or Cancel. The installation log file (%tmp%\MSIa02fe.log) has a more complete message:

Error 1406. Could not write value to key \S-1-5-21-728373296-843090993-1193339574-1003_Classes\Wow6432Node\CLSID\{8569D715-FF88-44BA-8D1D-AD3E59543DDE}. System error . Verify that you have sufficient access to that key, or contact your support personnel.
Error 1406. Could not write value to key \S-1-5-21-728373296-843090993-1193339574-1003_Classes\Wow6432Node\CLSID\{8569D715-FF88-44BA-8D1D-AD3E59543DDE}\Control. System error . Verify that you have sufficient access to that key, or contact your support personnel.
=== Logging stopped: 11/21/2018 10:33:30 ===

I say that this is a strange error because it occurs only when *I* build the installer. When my colleague builds the installer this error does not occur when the installer is run.

A clue here is that 728373296-843090993-1193339574 is the machine id for the machine that runs InstallShield Express 2016. The full SID S-1-5-21-728373296-843090993-1193339574-1003 is my local login SID on the same machine. {8569D715-FF88-44BA-8D1D-AD3E59543DDE} is the CLSID of one of the .DLLs that we ship with the project.

What I am looking for is help in finding and clearing the source of this error. If the error is a permissions error on the source files, then what permission needs to be reset? How do I fix this?

12-17-2018, 07:38 PM
With the assistance of a Flexera/InstallShield support engineer we have a work around for this issue in my installer, though the underlying issue has not been addressed.

We were able to identify the .OCX file that was associated with the bad registry keys then run the InstallShield RegSpyUI.exe utility to verify that it was extracting the un-wanted keys. The work-around proposed was to have that particular .OCX file do a Self-Registration rather than let InstallShield automatically extract the keys. For our case this work-around produced a valid installer with a working application after installation.

I will continue to update this post if we learn more about this issue, but having achieved a work-around, this may be the last update.

Edit 2019-01-07 doing a regsvr32 /u on the offending .OCX followed by a regsvr32 on it removed a few spare registry entries and everything works. No word on what went wrong, nor why InstallShield picked up the bad entries. So fixed, but no real understanding of what went wrong.

02-12-2019, 07:21 AM
Hey there,,did you find a solution to your problem above..i had a similar issue a while ago..tried to find solutions to no avail
thats why i joined the forum.

02-12-2019, 11:31 AM

Here is the final message that I sent to Flexera to close this support issue. Note the links in the text to a very useful white paper and other instructions for mitigation and debugging.


TLDR: bug now hiding.

> To clarify, are your test results from building the test project that you sent me? The project with only ARVIEW2.OCX? Or is this from building your full project?

The COM error results are when testing a build of my full application to the point where it invokes interfaces in ARVIEW2.

> If you manually register your OCX file using regsvr32.exe as tgoodman, are the extra, problematic Windows Registry entries created?

So here is what I did to track the registry tree of Computer\HKEY_USERS\S-1-5-21-728373296-843090993-1193339574-1003_Classes\Wow6432Node\CLSID\{8569D715-FF88-44BA-8D1D-AD3E59543DDE}

* Login as tgoodman, regedit shows that the key is currently present.
* $ find /cygdrive/c/ -iname ARVIEW.OCX # locate all instances of ARVIEW2.OCX
/cygdrive/c/Program Files (x86)/Common Files/Data Dynamics/ActiveReports 2/ARVIEW2.OCX
* $ find /cygdrive/c/ -iname ARVIEW2.OCX | while read F ; do W=$(cygpath -aw "$F"); regsvr32 /u "$W"; echo "$W"; done;
C:\Program Files (x86)\Common Files\Data Dynamics\ActiveReports 2\ARVIEW2.OCX
* Three dialog boxes appeared saying that the OCX was unregistered.
* regedit shows that the key is *NOT* currently present.
* $ regsvr32 "C:\fbe\code\manhole\MHPro\ThirdParty\ActiveReports\ARVIEW2.OCX"
* One dialog box appeared saying DllRegisterServer Succeeded.
* regedit shows that the key is *NOT* currently present.
* Build an MH Pro installer using InstallShield 2018
* 3-A Link to *no file* in ORGANIZE YOUR SETUP > Features > Features > Always Install > ActiveReports > REG File To Merge At Build
* 3-B Turn on COM Extract by selecting SPECIFY APPLICATION DATA > Files > View Filter > Active Reports > [CommonFilesFolder] > Data Dynamics > ActiveReports 2 > ARVIEW2.OCX (Right Click) > Properties > COM & .NET Settings > Registration Type > Extract COM information and .NET Properties > Scan at Build: > Dependencies and Properties
* 3-C CONFIGURE THE TARGET SYSTEM > Registry > Destination computer's Registry View > Deleted all entries
* New Registry Entries (75) dynamically acquired for component ARVIEW2.OCX
* Installed and tested.
* Success!!

To mis-quote Forrest Gump: "And just like that, my reproducible issue was no longer reproducible"

> Here is a link to a white paper from one of our Senior Software Developers, Josh Stechnij:
> http://learn.flexerasoftware.com/content/IS-WP-Installation-Authors-COM-Extraction
> Specifying Exclusions for COM Extraction on page 3 and 4
> and:
> Troubleshooting COM Extraction Issues on page 4
> discuss troubleshooting steps you could try.
> Do either of those work for you?

Good paper with clear instructions for blocking these entries should they appear again. But now that *your* test request has thrown my perfectly good, repeatable bug into the realm of lousy, irreproducible bugs, (thank you for that) I'm not going to run the test.

> If you set a user environment variable and a system environment variable:
> OAPERUSERTLIBREG=1 does the issue of extra, problematic Windows Registry entries occur during build?
> And if you set that environment variable to: 0 does the issue occur during build?

Since I'm still blaming you (err ... thanking you?) for changing the reproducibility of this bug, I'm not going to run this test.

> Please let me know if you have any questions or concerns.

I think we have hit the end of the line for this bug. We don't really know where it came from, but it is currently hiding and inscrutable. Until and unless it rises up again, there is no point, no purpose in more testing and debugging. Thank you for your investigations, patience, and expertise. This frustrating and annoying bug can hardly be described as fun, but you have made its duration tolerable. Thank you.