regsvr32 returned exit code 5 (and 4)

[Techie42]

Two of the files that I am attempting to self reg show up in the log with

wrn, error unregistering \filename1.dll - regsvr32 returned exit code 5
wrn, error unregistering \filename2.dll - regsvr32 returned exit code 4

I looked these up in WinError.h as

// The system cannot open the file.
#define ERROR_TOO_MANY_OPEN_FILES 4L

// Access is denied.
#define ERROR_ACCESS_DENIED 5L

However both of these files look fine in dependency walker and, they register and unregester fine with I run regsrv32 on them myself.

[Techie42]

Techie42 wrote:
Two of the files that I am attempting to self reg show up in the log with

wrn, error unregistering \filename1.dll - regsvr32 returned exit code 5
wrn, error unregistering \filename2.dll - regsvr32 returned exit code 4

I looked these up in WinError.h as

// The system cannot open the file.
#define ERROR_TOO_MANY_OPEN_FILES 4L

// Access is denied.
#define ERROR_ACCESS_DENIED 5L

However both of these files look fine in dependency walker and, they register and unregester fine with I run regsrv32 on them myself.

Hello? Anybody out there?

[RobertDickau]

As a test, does it work if you use an Execute Process action to run regsvr32 /s /u path-to-file.dll during uninstallation?

[xprt4a]

Try self-registering ole32.dll and oleaut32.dll manually (regsvr32 on these)

Then re-run the program. I will bet that you don't receive the error any more.

The reason why this happens is that the windows installer file location mangled name (you know, that thing that is incomprehensible) is in the InProcServer32 for ole32 functions is corrupted. manually self-registering the system32 version of this dll does two things:

1. Speeds up COM function related access.
2. eliminates the possibility that someone registered a version of OLE32 in their software package OUTSIDE of system32 (which would be a complete mess when they remove their package and their ole32.dll)

Let us know if this is what you're seeing after manually self-registering the ole*32.dll's

[Techie42]

RobertDickau wrote:
As a test, does it work if you use an Execute Process action to run regsvr32 /s /u path-to-file.dll during uninstallation?

Actually uninstall works fine with out generating error messages or any error log.

[Techie42]

xprt4a wrote:
Try self-registering ole32.dll and oleaut32.dll manually (regsvr32 on these)

Then re-run the program. I will bet that you don't receive the error any more.

The reason why this happens is that the windows installer file location mangled name (you know, that thing that is incomprehensible) is in the InProcServer32 for ole32 functions is corrupted. manually self-registering the system32 version of this dll does two things:

1. Speeds up COM function related access.
2. eliminates the possibility that someone registered a version of OLE32 in their software package OUTSIDE of system32 (which would be a complete mess when they remove their package and their ole32.dll)

Let us know if this is what you're seeing after manually self-registering the ole*32.dll's

Sorry, the same errors are still in the log

[RobertDickau]

Sorry, not sure why I had uninstallation in mind... For testing, perhaps try regsvr32.exe /s filename.dll in an Execute Process action during installation?

[Techie42]

RobertDickau wrote:
Sorry, not sure why I had uninstallation in mind... For testing, perhaps try regsvr32.exe /s filename.dll in an Execute Process action during installation?

Is there a way to tell the IS self reg process to ignore the return codes? Becuase the files actually seem register properly.

Bradley

[Techie42]

Techie42 wrote:
Is there a way to tell the IS self reg process to ignore the return codes? Becuase the files actually seem register properly.

Bradley

I know why you thought it was uninstall the error message in the log (during install) says

wrn, error unregistering \filename1.dll - regsvr32 returned exit code 5
wrn, error unregistering \filename2.dll - regsvr32 returned exit code 4


Which is a bit confusing. Any thoughts on that?

[Techie42]

Here is a thought:

If the I.S. regsvr32 function also incorperates the file copy functions then this is not just a register but also a file copy. If the file copy is a part of an earlier component and the file is read-only then would the second file copy fail and then cause an error message with the I.S. regsrv32 function?

Bradley

[Techie42]

RobertDickau wrote:
As a test, does it work if you use an Execute Process action to run regsvr32 /s /u path-to-file.dll during uninstallation?

Robert, I believe that these non-zero return codes are being returned by the dll's when they self register.

I will attempt to run a regsrv32 execicut to see what happens. Unless there is a way to ignor the return codes in the built in IS functions?

[Techie42]

Techie42 wrote:
Robert, I believe that these non-zero return codes are being returned by the dll's when they self register.

I will attempt to run a regsrv32 execicut to see what happens. Unless there is a way to ignor the return codes in the built in IS functions?

One of the files fails the regsrv32 exec with a missing component message. I tried moving the register exec to near abnd then after the finish dialogs but it still did not self register.

After the install is complete the file registers with regsvr32.exe with no problem.